What aeria guarantees, one statement each.

Your secrets

• aeria stores no secret it can open. It keeps them encrypted (sealed); only your workspace’s egress, a Worker of its own, holds the key that opens them, and aeria keeps no copy of that key.
• A secret never passes through your MCP client. No tool takes a secret’s value and none answers one. You type it on app.aeria.dev, where your browser seals it before it is sent.
• A secret is never in a sandbox or in an app’s code. They hold a placeholder, aeria-secret:<NAME>. The egress puts the secret in its place on the way out, toward the hosts declared for it only, in a header, over https.
• A new host waits for you. When a promote adds a host a secret goes to, that secret is held until its owner allows the new host on app.aeria.dev; meanwhile the new host is refused host_refused.

Setting a secret

1. Your agent calls app_setting_ask {app, name} (or connection_ask for a connection).
2. aeria answers a link to app.aeria.dev, valid minutes; never a value.
3. You open it signed in and type the value; the page seals it to your workspace’s key and sends only the sealed value.
4. The app’s code gets the placeholder; the egress opens the value for one request at a time.

Sandboxes

• One sandbox per session: each open branch and each artifact runs in a microVM of its own.
• No Cloudflare key in a sandbox, ever. Only aeria’s controlplane holds it; every upload is aeria’s, never the sandbox’s.
• Git through aeria only: a sandbox reaches its repository with a placeholder, swapped for a token minted for that repository, minutes long. A branch can push to itself, never to main; main moves only by aeria’s own merge at a promote.
• Read-only elsewhere: the package registries (npm, PyPI…) for reading; nothing else.

Signing in and clients

• You sign in on app.aeria.dev with an email code (one use, minutes) or a passkey. There is no password.
• An MCP client connects by OAuth, with your consent for one workspace. Its access token lasts an hour, its refresh token is rotated, and both act in that workspace only. You revoke a grant on app.aeria.dev; its tokens end with it.
• Tokens and codes are stored hashed, never in clear.

Every call is an event

Every tool call, a refused one too, is an event of your workspace: who, which client, what was asked, the outcome. A secret param is masked and a secret answer field is null. Events are kept.

What your apps run on

• Apps run on aeria.run, never on aeria.dev: an app’s code can never set a cookie for aeria.
• One app cannot read another’s cookies. Only cookies named __Host-… count on aeria.run; every other cookie is dropped before an app runs, and a cookie set for the whole domain is stripped from its answer.
• A private app or artifact signs its visitor in for that one host: a member of the workspace (or the artifact’s maker, for self) is sent back with a one-use code, and the host gets its own cookie. A visitor who may not see it is refused before the app’s code runs.
• Each app is isolated in Cloudflare’s Workers for Platforms: every fetch() it makes passes aeria’s outbound Worker (but a Durable Object’s), and it opens no raw connection.
• Nothing is public until aeria.run is on the Public Suffix List: until then, making an app or an artifact public is refused public_suffix_pending.

Keys rotated, keys lost

When your workspace’s egress key is lost, a new one is made, and each secret sealed to the old one is refused unopened until you set it again; app_setting_search names them.

Erasure

When you ask to be erased, your email, name and passkeys are deleted, your sign-ins and grants ended; your events are kept under your id only, every email in them masked. A workspace you were the only owner of is archived.