Security

How the service protects published content — and an honest list of what is not in place yet.

Last updated 15 August 2026. Applies to oi.mrdk.io and every Site served from it.

The model in one paragraph

A publish is three steps, and each one is authorized separately. Creating a Site returns upload URLs that are individually signed, time-limited, and bound to one object key each. Uploading uses only those URLs — an unsigned or expired request to the storage origin is refused. Finalizing flips the live pointer. A Site's access setting is enforced by the serving tier on every request, before any file byte is read, so a password-protected or invite-only Site cannot be reached by guessing a path.

Credentials

• Anonymous Sites are controlled by a claim token that is shown exactly once, at create time. It cannot be recovered later; if it is lost, the Site simply expires.
• API keys are bearer credentials with an oik_ prefix. An account can hold up to 50 named keys, so each agent or tool gets its own and a leak is contained by revoking one key.
• Drive share tokens are scoped: read or write, optionally limited to a path prefix, optionally expiring.
• Sign-in is by one-time email code, so there is no password to reuse, phish, or breach.

Isolation between Sites

Every Site is served from its own hostname under {slug}.oi.mrdk.io, which puts each one in its own browser origin: separate storage, separate cookies, no ambient access from one Site's scripts to another's. The apex, the storage origin, and the Sites are distinct origins as well, and the storage origin answers nothing except signed uploads.

Published files are static. Nothing you upload executes on the server, so a Site cannot read another Site's files, reach the database, or make outbound requests except through the proxy routes you configure yourself.

Data handling

Public traffic is served over TLS. Uploaded bytes are stored content-addressed, so identical files are stored once and every file's integrity can be checked against its hash. The metadata database and the blob store live on the service's own infrastructure — no third-party CDN or object store holds a copy of your files.

Reporting a vulnerability

Email hi@oi.mrdk.io with the words "security report" in the subject. Include the URL or endpoint, the steps to reproduce, and what you were able to see or do. You will get a human acknowledgment within three working days and an assessment within ten.

Good-faith research is welcome and we will not pursue you for it, provided you stay within your own resources and accounts, use no more load than a proof of concept needs, never access, modify, or destroy another user's data, stop as soon as you have confirmed the issue, and give us a reasonable window before publishing. There is no bug bounty; there is credit on this page if you want it.

In and out of scope

In scope: the apex API and pages, the storage origin's signing and authorization, site serving and access control, and anything that lets one tenant reach another's data.

Out of scope: content published by users (report that through abuse instead), findings that require a compromised device, volumetric denial of service, missing hardening headers with no demonstrated impact, and reports produced entirely by an automated scanner with no verified consequence.

What is not in place yet

Stated plainly, because a security page that only lists strengths is not useful:

• No third-party audit and no compliance certification — do not assume one exists.
• No bug bounty program.
• Serving runs from a single origin, so an outage there takes Sites offline; see status.
• Anonymous publishing is deliberately open: anyone can create a Site, and the protections against misuse are rate limiting, the 24-hour expiry, and abuse handling after the fact.

Contact

Questions about this page go to hi@oi.mrdk.io. Abuse reports are handled faster through the abuse page.