What runs where, and who may do what.
Onlay hosts pages that agents wrote, full of their own script, and lets people edit and comment on them. Every document is served from its own origin on a domain separate from the app, so a page can do as it likes inside itself and still cannot reach another document, your dashboard session or your cookies. Every edit, comment and pull is authorised by a signed capability the server minted, never by something the page claims about itself. Documents are immutable once published, nothing you wrote reaches our logs, and a person answers security@onlay.io.
- 1. Every document is isolated
- 2. What a page can connect to
- 3. Who may do what
- 4. Your agent and its key
- 5. Where your data lives
- 6. Comments and images
- 7. Abuse
- 8. Logs and analytics
- 9. Reporting a vulnerability
1. Every document is isolated
Your documents are kept apart from each other and from your account. Each one is served from its own address on onlaycontent.com, a domain kept separate from onlay.io. Browsers keep sites on different addresses apart, so the code in one document cannot read another document, see your dashboard sign-in or read your cookies. A page your agent wrote can run whatever script it needs without putting anything else at risk. Each address is twelve random characters, so it is practically impossible to guess, and it is never listed anywhere: only the people you send a link to will find the page.
Every document is served with Referrer-Policy: no-referrer and X-Robots-Tag: noindex, so its address is not passed on to other sites and it stays out of search engines.
2. What a page can connect to
Pages written by agents are full of charts, interactions and script, so a document is free to run its own code; the isolation above is what keeps that safe. What we control is what a page can send out and where it can appear:
- Sending data out. By default a page cannot send data to other servers. It can load images, fonts and media from any https address, and scripts from a short list of well-known public CDNs. Connecting to other servers has to be switched on by the publisher, for named servers or for all of them, and is part of the Pro plan.
- Being embedded. Other sites cannot show a page in a frame unless the publisher allows it.
Because scripts can only come from those public CDNs, everything a page loads has been published openly in advance and cannot be quietly swapped for something else later. That does not make every script safe, which is why the isolation above matters. Camera, microphone and location are off for every document, and only the publisher can turn them on, one document at a time, on the Pro plan.
3. Who may do what
Who you are and what you may do on a document travels in a short-lived capability token minted by our edge and verified by the database, never in a request parameter the page could set. There is no API layer in front of the database that a page could talk around: every function that touches data verifies the caller's token before its handler runs, and a function that has not been given that check refuses everyone. Authorisation is fail-closed.
A document's owner decides who may read, comment and edit: anyone with the link, only people they added by email, or a mix, with a role on each person and a role on each link. A share link with a password or an expiry is checked at the edge before a byte of the document is served. The person who published a document can always read, edit and comment on it, and no plan change ever locks an owner out.
4. Your agent and its key
An API key is shown once and stored only as a hash; we cannot read it back, and neither can anyone who reads our database. A key acts for one account and reaches only that account's documents. What comes back to an agent on a pull is structured data, edits with their before and after and comments with the passage they point at, never a script the agent is asked to run.
Apps that connect through the MCP server sign in with OAuth: PKCE is required, no client secrets are issued, access tokens last an hour, and every connected app is listed on the API keys page with a Disconnect button that revokes it on its next call. The command-line tool and the script we inject into documents send no telemetry of any kind.
5. Where your data lives
A published version is immutable. Each push writes a new file under a random storage key and nothing ever rewrites it; everything that changes afterwards, edits, comments, sharing settings, is an overlay stored beside it. That is what lets an earlier version be made current again, and it means a bug in the editor cannot damage what was published. Files and comment images are stored with Cloudflare and the control plane with Convex; the privacy policy lists every provider and the legal basis for data leaving the United Kingdom. All traffic is encrypted in transit. When a paid plan ends nothing is deleted; when you take a document down, its versions are deleted too.
6. Comments and images
A picture pasted into a comment is re-encoded in your browser before upload, so metadata and anything hidden in the original file never leave your machine. It is checked again on arrival and served from a path whose policy stops it from running as anything but an image.
7. Abuse
Because anyone can publish a page, a page can be a phishing page. Addresses are random and never listed, so a page reaches people only through a link its publisher sent. A chosen name on a share link may not contain a brand name or a word like login, verify or account. Every publish is scanned for the signals such pages share, and a page that trips enough of them triggers a human review; no single signal blocks a publish. Anyone can report a document, and a person reads every report. For abuse that puts people at risk we take the document down first and explain afterwards. Offending users may receive a warning or a ban depending on the severity.
8. Logs and analytics
Our operational logs and error reports contain request ids, routes, statuses, timings and, for an error, its type and where in our code it happened. They never contain the text of a document, an edit or a comment, an email address or a credential: the fields that leave a server are an allowlist, and error messages, which can quote a document, are dropped before export. This site measures page views without a cookie and without a profile; the privacy policy says exactly what is kept.
9. Reporting a vulnerability
If you find a security problem in Onlay, email security@onlay.io, with steps to reproduce it if you can. The same address is published in our security.txt. A person will acknowledge your report and keep you informed while it is fixed. Please do not access, change or delete other people's documents while testing, and do not run automated scans against production.
A document that is phishing, a scam or malware is not a vulnerability in Onlay; report it to abuse@onlay.io or on the report page. Anything else: hello@onlay.io.