Threat model

Mirrored from docs/threat-model.md in the EveryApp repository, where it is edited.

This is the model behind docs/security-model.md. That document describes the mechanisms, one by one; this one says what they are for: what is being protected, from whom, across which boundaries, under which invariants, and where each invariant is enforced and tested. It is written for someone who wants to find a hole: pick an invariant, read the code it points at, and try to make the test's negative case pass.

EveryApp is alpha software, moving fast, and the operator is root (see "Actors"). Read the known gaps at the end before relying on anything.

The self-hosted shape is what launches, and is described first. The hosted shape (our own install of the same code) comes second: its extra boundaries are built, mostly unverified against a live Workers for Platforms namespace, and switched off by default.

Verified against the code at commit c0f916ad (main on 2026-10-23, after #379); the register's line numbers refer to that commit, except the public-surface rows (an app host's /mcp opt-in, the gateway's /health, the Access sign-in methods and bypass list), re-read on 2026-10-25 against c2d04d85 (main after #606, #612 and #622), and the B9 rows (the event bus, outbound webhooks, the email sink, the app emit route), read on 2026-10-25 against 2083a662 (main after #628), with the CLI's side and the SDK's packages/sdk/src/internal/events.ts (#644, which added the private-name list and moved that file's lines) read against bb644c05 (main after #644); the B10 rows (the sign-in providers) were written with the code on 2026-10-25 on the branch that added them, from main at 9b0e0fdc (after #661).

How to use this document

• Each invariant has a stable id (perimeter.csrf-private-fail-closed), one testable sentence, the code that enforces it (path:line) and the test that pins it (file :: test name). Line numbers drift; the symbol names drift less; the ids don't. Each boundary below quotes the ones to try first; the complete register of 350 is docs/threat-model-invariants.md.
• "Pinned" means a test fails if the invariant breaks. "Partial" means a test covers some cases. "Unpinned" means the code does it and nothing tests it. "Not enforced" means the docs say it and the code doesn't.
• The tests run per package: pnpm -C apps/every-app-gateway exec vitest run --silent=true <file>, pnpm -C packages/perimeter exec vitest run <file>, and the same for packages/sdk, packages/toolbus and packages/cli. docs/TESTING.md describes the suites.
• Found something? See "Reporting a problem" at the end.

The system in one picture

                 ┌───────────────────────── your Cloudflare account ─────────────────────────┐
                 │                                                                           │
 browser ──────┐ │  ┌─ Cloudflare Access (optional outer ring) ─┐                           │
 AI client ────┼─┼─►│  bypasses: /health, /mcp, /oauth/token,   │                           │
 webhook/API ──┘ │  │  /oauth/register, /.well-known/*, public   │                           │
                 │  │  routes, and /mcp on opted-in app hosts   │                           │
                 │  └──────────────────┬────────────────────────┘                           │
                 │                     ▼                                                     │
                 │     ┌────────── Gateway Worker (the only public Worker) ──────────┐       │
                 │     │ control plane: sign-in, sessions, organizations, admin,     │       │
                 │     │   setup claim, invitations, /mcp, the OAuth server           │       │
                 │     │ perimeter: per app host, classifies the route, strips       │       │
                 │     │   Cookie / Authorization / x-everyapp-* / cf-access-*,      │       │
                 │     │   checks session + organization + app access + CSRF,        │       │
                 │     │   mints a 2-minute RS256 identity JWT (aud = Worker name)   │       │
                 │     │ D1: users, sessions, organizations, apps registry, tokens,  │       │
                 │     │   connections, audit rows      KV: OAuth server state       │       │
                 │     └──────┬───────────────────────────────────▲──────────────────┘       │
                 │  service binding (private)            AppGateway binding (RPC):           │
                 │  x-everyapp-identity, or               AI proxy, capabilities, email,      │
                 │  x-everyapp-public marker              members, tool catalog              │
                 │            ▼                                   │                           │
                 │     ┌─────────────────────────────────────────┴──────────────────┐       │
                 │     │ app Worker  every-<orgKey>-<appId>   (no routes, no        │       │
                 │     │   workers.dev, no preview URLs; the SDK verifies the JWT)  │       │
                 │     │   its own D1 / KV / R2 / Durable Objects / Workflows /     │       │
                 │     │   Hyperdrive; helper Workers  <worker>--<name>             │       │
                 │     └────────────────────────────────────────────────────────────┘       │
                 │                                                                           │
                 │  operator's laptop or CI ── cf CLI with the Cloudflare login ──► Workers,  │
                 │  (everyapp deploy / setup)                                      D1 writes  │
                 └───────────────────────────────────────────────────────────────────────────┘
                                             │ provider keys stay on the Gateway
                                             ▼
                        OpenAI / OpenRouter / Workers AI / DataForSEO / Context.dev /
                        social networks' token endpoints / Email Sending

                 Gateway Worker ──► subscriber URLs (B9): one signed POST per event
                   (HMAC-SHA256 over t.body, https to a public host, never itself,
                   no redirects, retried ~35 h) and event mail to the organization's
                   owners and admins; never a secret, a tool's arguments or result

The one rule everything else hangs on: a person's credential stops at the Gateway. Apps never see a cookie or a bearer token. They see a short-lived signed statement of who the person is, minted for that app's Worker alone, or a signed marker saying "nobody". Everything an app wants from the outside world that needs a credential the operator holds goes back through the Gateway, attributed to an organization.

Deployment shapes

Anything but self_hosted or hosted in GATEWAY_DEPLOYMENT_MODE (unset included) is invalid and turns every capability off: no setup claim, no Access sign-in, no app activation, no dynamic client registration, no account actions, no outbound mail (apps/every-app-gateway/src/server/platform-policy.ts).

Assets

What an attacker would want, roughly in the order it would hurt.

Actors

Two actors deserve a sentence each. The operator is root by design: ADR-0003 chose one credential (the Cloudflare login) over a second Gateway token that could only have confirmed what the login already had. Everything below assumes the operator is honest and their Cloudflare credential is safe; losing it is losing everything in the account, Gateway included. An app's code is the actor the perimeter is mostly built around: EveryApp exists so that people can run code they or an AI wrote without that code being able to hurt anyone but its own organization. On a self-hosted Gateway with one organization that means a buggy app can hurt only the data it was given, and never the Gateway's accounts, the operator's provider keys, or the Cloudflare account.

What Cloudflare Access adds, and what it doesn't

Putting Cloudflare Access in front of the Gateway and the apps' hostnames (the outer ring, docs/runbooks/cloudflare-access.md) is strongly recommended at launch. It is a second, independent sign-in from a company that does nothing else, in front of alpha software. Concretely, with the outer ring configured (CLOUDFLARE_ACCESS_TEAM_DOMAIN, CLOUDFLARE_ACCESS_AUD, CLOUDFLARE_ACCESS_APPS_AUD):

• A visitor never reaches the Gateway's pages or an app's private routes. Password brute force, the sign-up and reset pages, the setup page, the consent page, every server function and every app page are behind Access's login before the Gateway sees them. A bug in any of them needs an Access-admitted person to reach.
• A stolen session cookie is not enough. Behind the outer ring the Gateway honours a session only when the same request carries a verified Access assertion for the same person (CLOUDFLARE_ACCESS_AUD on the gateway's host; the apps' AUD vouches for sessions on app hosts). A cookie copied to another browser gets nothing without that browser also passing Access as that person.
• Taking someone out of the Access policy ends their browser access when their Access session ends (24 hours by default), whatever Gateway session they still hold.
• With Managed OAuth, AI apps pass Access too: nothing on the gateway's host but /health is bypassed, and a person taken out of the policy loses MCP within the access token's lifetime (15 minutes by default).

What Access does not cover, by design, so the Gateway's own checks remain the only thing between these and the data:

• Personal access tokens and OAuth tokens never pass through Access (the bypassed /mcp*, /oauth/token and /oauth/register). A stolen epat_… or access token works until it expires or is revoked; removing the person from Access changes nothing. Offboarding is Deactivate in Admin → Users, which revokes tokens and connections at once.
• Apps' public routes are bypassed per route, so whatever an app declares public is reachable by anyone on the internet, with their Authorization header forwarded for the app's own checks.
• Deploy authority. The CLI never calls the Gateway; it talks to Cloudflare's API with the operator's login. Access in front of the Gateway says nothing about who can deploy, change a row, or redeploy the Gateway. That is the Cloudflare account's membership.
• The Access session itself. Its cookie is Cloudflare's: keep HttpOnly and the binding cookie on (the runbook's defaults), and enable only identity providers that verify email addresses, since the Gateway treats Access's email as verified. everyapp access on allows on the two EveryApp applications only the providers it vouches for: the one-time PIN, and Sign in with Cloudflare (type cloudflare) with Restrict to account members on, which it creates that way. A cloudflare provider with the restriction off, a generic oidc or saml one, and any other provider of the team are left off and named (ACCESS_IDP_ANY_CLOUDFLARE_ACCOUNT, ACCESS_IDP_UNVERIFIED_EMAILS); the Zero Trust team is account-wide, so a provider on it says nothing about who may sign in here. Nothing access on does takes a provider off an application (the register's access.cli.allowed-idps).
• One application for everything (one AUD for the gateway's host and the apps' hosts) makes every app host's Access cookie a gateway login too. The runbook asks for two applications; the single-AUD setup is accepted with that caveat.

With OIDC sign-in only (no outer ring), Access replaces passwords and adds nothing in front of the pages: the Gateway's own perimeter is the whole story, as without Access.

Explicitly out of scope

Things this model does not try to stop. Some are decisions, some are Cloudflare's job, some are simply not built.

• A compromised Cloudflare account or credential. Whoever holds it is the operator (ADR-0003). Every app's CI token with D1 write is too. There is no second factor inside EveryApp for deploys, and revocation is Cloudflare's.
• Cloudflare itself: the runtime, D1, KV, the edge, Access, Email Sending, their staff and their bugs. Workers isolation between accounts and the dispatch namespace's isolation are taken as given.
• An honest operator's mistakes with secrets outside the CLI: a .dev.vars committed to a public repository, a provider key pasted into chat, a .everyapp/secrets.env left world-readable. The CLI keeps secrets off argv and out of its output; the file system is the operator's.
• Denial of service and cost. Nothing meters an organization's provider spend; the daily mail and registration budgets exist to protect a gateway's standing, not to stop a determined flood. Cloudflare's own limits and the Workers Paid bill are the backstop.
• Timing side channels, except where a comparison guards a secret (token hashes are compared as hashes; the code doesn't try to be constant-time everywhere).
• Which build serves. The Gateway's build stamp (short commit and build time, with a * when the tree was dirty; apps/every-app-gateway/vite.config.ts, rendered by the browser under the sidebar's account row and, on the pages without a sidebar such as sign-in and the 404, in the bottom-right corner) is on every control-plane screen for anyone who can load one. That is ordinary version disclosure and is accepted: a self-host builds from the public repository, so its commit is public anyway, and the stamp lets an operator match a screen to a commit.
• Supply chain beyond the floors. pnpm-workspace.yaml pins known-bad transitive versions (jose, seroval, tinypool) and CI fails on critical advisories in the lockfile; nothing verifies package provenance or reviews each dependency's code.
• The browser. Extensions, a malware-ridden machine, a shared computer left signed in. HttpOnly, Secure, SameSite and the two-minute identity token limit what a page can do, not what the machine can.
• Social engineering of the operator (a fake invitation, a phished Cloudflare login) and physical access.
• An app's own logic bugs within its organization: an app that shows one member another member's todo is the app's bug. The Gateway gives it the identity; scoping the query is the app's job (the skill and AGENTS.md say so; the local security review checks for it).
• The local development gateway (everyapp dev): it enforces the same perimeter shape with a public dev key, for one seeded user, on localhost. It is not a deployment.
• Postiz is not part of the launch; its port's findings are in TODO.md where they show a platform-level issue.

Trust boundaries

Nine boundaries, each with what crosses it, the attacks it is there to stop, the invariants to try first (the complete register, 351 invariants with every code pointer and test, is docs/threat-model-invariants.md), what is not that boundary's job, and the gaps found in this pass. B1 to B7 are the self-hosted shape; B8 is the hosted tier; B9 (added 2026-10-25) is the Gateway as a caller, in both shapes.

B1. Browser → app host: the perimeter

What crosses. Every request to <app>.<APP_BASE_DOMAIN>: a member's browser carrying the Better Auth cookie, a script with a personal access token, a visitor, a webhook. On the other side, the app's private Worker. The code is handleGatewayRequest in packages/perimeter/src/gateway.ts, wired by apps/every-app-gateway/src/server.ts, with the authenticators in apps/every-app-gateway/src/perimeter/.

What it stops. A visitor reaching anything the manifest didn't declare public. A cross-site page riding a member's cookie into an identity (CSRF on private routes; forced-anonymous on public ones). A client forging x-everyapp-identity, x-everyapp-org or an Access header. An app seeing a cookie or a bearer. A token minted for one Worker being replayed at another. A sibling subdomain planting a session cookie. A personal token meant for MCP being used on app pages. The control plane being served on an app origin. A switched-off, half-deployed, deleted or hand-edited registry row being routed.

Invariants. The full register has 34; these are the ones to try first.

Public routes. A route listed under public in everyapp.config.ts is open to the internet: the Gateway forwards the visitor's Authorization header untouched, mints a signed public marker instead of an identity, and whatever authentication the route needs is the app's own (a webhook signature, a bearer the app verifies). A signed-in member with access still gets an identity there. The route grammar (methods, patterns, what can't be public) is on the agent docs' manifest page, https://everyapp.com/docs/agent/manifest; the invariants are perimeter.public-default-private, perimeter.authorization-forwarding and perimeter.public-auth-optional.

Not this boundary's job. What the app does with a verified identity (scoping its queries), what a public route does with the Authorization it is handed, egress from a service-binding app (it can fetch anywhere), and anything on the gateway's own host (B2).

Gaps.

• First-party WebSocket handshakes pass through untouched (medium, small fix). A 101 on a first-party host keeps its Set-Cookie Domain= and Access-Control-Allow-Credentials, and gets no security headers, because a 101 can't be rewrapped (packages/perimeter/src/gateway.ts:550-552; the third-party path rebuilds the handshake and strips them). An app that sets a parent-domain cookie on its handshake can plant a second session cookie for the whole gateway, which the duplicate-cookie rule then turns into a lockout of every member. perimeter.first-party-101-cookie-domain is not enforced. TODO: "Strip session-named Set-Cookie headers from app responses" (Build).
• An app can set a cookie named like the session cookie on its own host (low, known; same TODO line). The browser then sends two copies and the member is locked out of that app until they clear cookies.
• The duplicate-cookie refusal is a lockout primitive (low, known). Any script on the base domain can write a parent-domain cookie with the session cookie's name; from then on every host answers 401 until cookies are cleared. The refusal is right; the 401 could expire the gateway's own variants to help the browser recover (TODO, Build).
• Proxy-forwarding headers pass through (low, small fix). X-Forwarded-For, X-Real-IP, Forwarded, X-Forwarded-Host/Proto reach the app as the client sent them; Cloudflare's cf-connecting-ip is the authoritative address. A ported app that trusts X-Forwarded-For for rate limiting or audit logs can be fed values.
• The third-party authenticator has no unit tests (low, hosted only). Its three decisions (a non-epat_ bearer authenticates nobody, the host cookie must name this host and app row, another organization's row is refused) are pinned only through the sqlite suite's happy paths.
• Revocation latency is 30 seconds per isolate for a disabled app, a changed manifest, a removed browser-session member and a suspended organization. Documented, not a finding; stated here so nobody expects less.

Merged this week (the secrets model: #383 the manifest needs, apps.secret_names and the evaluator apps/every-app-gateway/src/server/app-setup.ts; #396 the gate, merged f43859cc): a perimeter hook needsSetup({ app, request, publicRoute }) runs after the status checks and before authentication; an app whose required settings are unset answers 503 app_needs_setup naming only the app id (or, for a private HTML navigation, a 302 to the gateway's home with ?setup=<app>), public routes included. The invariant, pinned (perimeter.needs-setup-names-no-setting in the register): no setting name or value leaves the perimeter in those responses (apps/every-app-gateway/src/server/app-needs-setup.ts; app-needs-setup.test.ts :: answers a public route with a 503 that names no setting, and the perimeter's gateway.test.ts :: the setup gate). The apps.secret_names column (#383) holds the names of an app's own secrets, never values, written by the CLI and shown to members who can see the app; the gateway's /mcp leaves a not-ready app's tools out and names the missing setting in its instructions. One thing to know, not a gap: because the hook runs before authentication, a visitor learns that an app exists and is unconfigured where they used to get the sign-in redirect; app ids are hostnames, so nothing new is disclosed, and Access in front hides it.

Merged this week (the teams slice, docs/design/2026-10-teams.md; #384 and #385): effective app access is user_app_access ∪ (group_members ⋈ group_app_access), one union in apps/every-app-gateway/src/server/repositories/effective-access.ts read at every site (this authenticator, the launcher, the members capability, the MCP catalogs, the consent page). The invariant, pinned (appaccess.groups-same-rule-everywhere in the register): a group never holds another organization's user or app, nor a shared app, and removing a member deletes their group rows in the same batch (groups.sqlite.test.ts :: keeps organizations apart: neither their apps, their people nor their groups cross).

B2. Browser → the Gateway's own host: the control plane

What crosses. Sign-in, sign-up, password reset and email verification; the one-time setup claim; invitations; every admin action (members, roles, app access, app rows, tokens); the organization switcher; the OAuth consent pages and /mcp (B5). On the other side, the Gateway's D1 with every account and every organization. The code is Better Auth as configured in apps/every-app-gateway/src/auth/config.ts, the request guard in src/server/control-plane-guard.ts, the server functions under src/serverFunctions/ with their middleware in src/middleware/auth.ts, and platformPolicy() in src/server/platform-policy.ts.

What it stops. Anyone signing up without an invitation (or before the owner exists). A cross-site page making a signed-in browser change state. A member reading invitations, creating organizations, or reaching Better Auth's admin endpoints over HTTP. A guessed invitation id or setup link claiming anything. An admin acting outside their organization, on an owner, or on an account that belongs to another organization too. A sign-in page redirecting off-site. Error bodies leaking internals. A misconfigured deployment mode turning anything on.

Invariants. The register has 46; the ones to try first:

Not this boundary's job. Who may deploy (B7), what Access adds in front of these pages (B6), the MCP and OAuth endpoints (B5), the strength of a person's password beyond the 8-character minimum, and the browser the session lives in.

Gaps.

• No owner recovery for a sole owner (medium, known). Ownership transfer exists: an owner makes another member an owner, and another owner can then demote, deactivate or delete a compromised owner (the last owner is kept, so the organization is never without one). A sole owner who is compromised or locked out still needs the operator: everyapp workspace role <email> owner under the Cloudflare login makes a second owner, and the recovery kind in owner_setup_tokens is unused. TODO: "Setup link expiring mid-wait" is adjacent; this needs its own entry.
• A stolen admin session can take over any single-organization member (medium, medium fix). An admin can mint a one-hour reset link for any member who belongs to no other organization and set their password, invite admins and promote members to admin, with no fresh-session or re-authentication requirement. Behind Access, the admin's browser must also pass Access as that person, which is the mitigation at launch.
• Session lifetime is Better Auth's default and nothing pins it (low). 7 days, extended by a day on use, no absolute cap; cookieCache: false, which every revocation invariant depends on, has no test.
• Credential rate limiting is silently absent when the Rate Limiting bindings are missing (low, known). A gateway uploaded without the AUTH_RATE_LIMIT_* bindings has only Better Auth's per-isolate counters and nothing logs the absence.
• Role changes and suspension take up to 30 seconds to reach other isolates (low). Deactivation is immediate.
• Before GATEWAY_URL is set, the control plane and setup claim are served on any host (low). The link is still the credential; the sign-in UI and cookie can appear on a workers.dev host during that window.
• Hosted open sign-up has no bot control beyond mail budgets (medium, known, hosted only; the preview stays invite-only for this reason).

Docs to fix. docs/security-model.md says a fresh gateway "accepts no sign-ups" until claimed: a sign-up carrying a live invitation token is accepted whether or not an owner exists (no invitation can exist before the claim in practice). The inline comment in auth/config.ts about Better Auth's default per-IP rules describes per-isolate counters; the effective limits are the Workers Rate Limiting bindings.

B3. Gateway → app Worker: the identity contract

What crosses. One request per proxied call over the app's service binding, carrying either x-everyapp-identity (a fresh RS256 JWT for this Worker) or x-everyapp-public (a signed marker); the tool-call and catalog requests on /__everyapp/tools/*; and, from everyapp dev only, tokens signed by the public dev key. On the other side, the app's code behind everyApp() in packages/sdk. The verifier is packages/sdk/src/internal/identity.ts; the claims are packages/sdk/src/internal/protocol.ts; the tool endpoints are packages/sdk/src/server/toolsEndpoint.ts; the ToolBus that mints per-call identities is packages/toolbus/.

What it stops. A request that didn't come through the Gateway being served (no token, a forged one, alg: none, HS256 with the public key, an unknown key, an expired token). A token minted for another Worker, or for another organization's copy of the same app, being accepted. A public marker standing in for an identity, or an identity for a system token. The dev key being accepted by a deployed Worker. A tool running without a call-bound MCP identity with the exact scope its risk needs. A destructive tool ever running. An app minting identities, or attributing its gateway calls to a user or organization it chose.

Invariants. The register has 39; 38 are pinned.

Not this boundary's job. Whether the app calls everyApp() at all (nothing at deploy time proves it; the template does, and pnpm dev runs behind the same perimeter so an app that doesn't breaks visibly), and what the app does with a verified user.

Gaps.

• The AppGateway binding's props are self-asserted by the app build and not pinned by the deploy policy (high, known, medium fix). The entrypoint trusts the binding's {organizationId, appId, workerName} and checks only that a matching registry row exists. The CLI's policy checks the binding by name and target only (packages/cli/src/lib/app/policy.ts), so a hand-written cloudflare.config.ts (the deploy warns NONSTANDARD_CLOUDFLARE_CONFIG and proceeds) can set another organization's ids and have its calls attributed there. On a self-hosted gateway with one organization the operator deploys everything anyway, so this is the operator misattributing to themself; on hosted it is the "props pinned on every upload" launch-gate item (built for dispatch uploads, a follow-up for CLI deploys: TODO "Redesign stack 2, identity").
• No volume limit on provider calls through the binding (medium, known; the same gap as B4's).
• A shared app's Worker may attribute background work to any active organization (medium, known, hosted only): the design trusts first-party code; TODO records it.
• Public markers verify without an issuer check when EVERYAPP_IDENTITY_ISSUER is unset (low, small fix). Identities and system tokens require the issuer; markers don't, so a Worker deployed without the issuer variable would accept a marker from any gateway holding a key in its set. The deploy always sets the issuer; a one-line change makes the verifier demand it.
• The production 404 of /api/dev/identity is pinned only by import.meta.env.DEV (low). Both tests run under vitest where DEV is truthy.
• A missing scopes or chan claim decodes to full access (low). Only the gateway signs and always writes both; a defensive decode would default to nothing.
• The AppGateway verifies forwarded identities with the single JWT_PUBLIC_KEY while apps accept current and next (info): a token signed just before a key rotation is refused at the gateway.
• The identity TTL extends suspension and removal lag beyond the 30 s caches by up to 120 s (low, known): nothing re-checks membership on a verified identity.
• Browser-session and Access-authenticated MCP callers are always write principals (info, known): only tokens and OAuth connections can be read-only; roles never narrow tool access.

Docs to fix. ADR-0002 and RFC-0001 (both deleted 2026-10-24) said the SDK verifies that the token's organization matches the deployed Worker's organization; it doesn't compare org_id with EVERY_APP_ORG_ID. The guarantee comes from the audience: each organization's copy has its own Worker name, and the gateway mints aud from the registry row.

B4. App Worker → the Gateway: the AppGateway binding, AI and capabilities

What crosses. Calls an app's Worker makes back to the Gateway over its EVERY_APP_GATEWAY service binding: the AI proxy (/api/ai/<provider>/…), the capability proxy (/api/integrations/<id>/…: DataForSEO, Context.dev, the social networks' and Google's and Microsoft's OAuth clients, the held-token branch of every OAuth provider the Gateway runs the flow for, email, members), and the tool-catalog fetch. The binding carries the app's upload-time props (organizationId, appId, workerName) and the app forwards the identity of the request it is serving, or names an organization for background work. On the other side, the operator's provider keys and client secrets, and the organization's attribution. The code is apps/every-app-gateway/src/server/app-gateway-entrypoint.ts, ai-proxy.ts, integration-proxy.ts, capabilities/ and email/, with the SDK's createGatewayFetch and integrationFetch on the app side. Since 2026-10-25 the gateway also holds the credentials of remote MCP servers an operator registered by URL (everyapp mcp add; Gateway settings in the _MCP_TOKEN family, each pinned to one origin) and sends them itself when a member's AI client calls such a server's tool through /mcp (B5); no app's Worker ever sees one. The code is apps/every-app-gateway/src/server/remote-mcp/{index.ts,bind.ts,relist.ts} and packages/toolbus/src/remote/{client.ts,normalize.ts} (#627); the design is docs/design/2026-10-mcp-by-url.md. Since 2026-10-25 the gateway also holds people's OAuth tokens: an OAuth provider (a catalog client with a flow, or a row or preset with auth.kind: "oauth2-user") is connected at /connect/<id> with PKCE and a one-use state, the tokens are sealed in provider_connections, and an app's call to the provider's API hosts crosses this boundary with no token of its own: the gateway refreshes under a lease, puts the bearer on, and holds the call to the app's declared scope sets, so the route allowlist of the scopes slice is now a live boundary. The code is apps/every-app-gateway/src/server/oauth/{flow.ts,tokens.ts,service.ts,client.ts}, secrets/sealed.ts and the held-token branch of capabilities/oauthClient.ts; the design is docs/design/2026-10-oauth-providers.md, the invariants the oauth.client-bound-to-endpoints, oauth.client-secret-sealed-at-rest, oauth.tokens-sealed-at-rest, oauth.held-token-never-to-app, oauth.held-token-scope-routes-live, oauth.pkce-on-connect, oauth.state-single-use, oauth.return-to-own-hosts and oauth.google-never-revoked rows of the register.

What it stops. An app learning a provider key, a client secret, or whether a key exists for a capability it didn't request. An app reaching a provider endpoint that lists the operator's whole account, another organization's data, or a non-inference endpoint. An app in one organization getting its calls attributed to another. An agent's identity sending mail, listing members or minting OAuth tokens it shouldn't. An app sending as a domain the operator didn't allow, or reading the directory of people who can't open it. Provider cookies and credentials leaking either way. A remote MCP credential sent anywhere but the origin the operator set it for, followed through a redirect, or a remote MCP app pointed at the gateway itself or at a host whose key the gateway holds.

The provider registry. Since PR 2 of the provider registry (docs/design/2026-10-provider-registry.md) the capability proxy reads its providers from a registry: the built-in catalog first, then the API-key providers an operator registered on this Gateway as rows of its D1 providers table (everyapp provider add, under the Cloudflare login; the Gateway only reads the table). A row is a new host to send a secret to, so the boundary is what a row may say, checked when it is written and again by the Gateway every time it reads one (apps/every-app-gateway/src/server/providers/index.ts): its settings carry its own id as a prefix and are nobody else's, so no row can name the signing key, a catalog provider's key or another row's; its hosts are public DNS names the Gateway doesn't serve itself; it never shadows a catalog id; and its key is read only while the row still has the hosts and auth it had when everyapp secret set set the key, so whoever can rewrite a row can't move a key the operator set. A row that fails is left out and logged provider.row_invalid, never served. A row is gateway-wide (its key is every organization's on that Gateway), which is why a provider whose data is account is refused on a hosted Gateway. What it does not change: whoever can deploy an app can list any provider, as before. PR 2c added the MCP tools: everyapp_provider_add and everyapp_provider_remove write rows for owners and admins on a self-hosted Gateway only, never replace a row and never remove a bound or listed one (providers.tools-self-host-admin, B5).

Invariants. The register has 54. The eight the provider registry added are in the register (providers.row-secret-is-its-own, providers.value-bound-to-hosts, providers.row-hosts-public-https, providers.builtin-precedence, providers.spec-names-no-values, providers.add-is-privileged, providers.query-key-never-echoed, providers.account-data-self-host-only); the three worth trying first are at the end of the table below. The app emit route's attribution (events.emit-route-attributed-like-a-capability, 2026-10-25) is the table's last row; what the event may carry is B9's.

Not this boundary's job. What the provider does with a valid call, an app's own secrets (its secrets in the manifest live on its Worker), and what an app does with the network API tokens it holds (the scope sets bound which tokens it gets, not the calls it makes with them).

Gaps.

• No default limit on provider spend (high, known; cap.per-organization-limits is enforced only for an app an owner or admin capped, or under a default they set, #416 and #621). Every AI call, every DataForSEO paid call and every Context.dev render is attributed, logged and, since #381, counted per organization and app; since #416 an owner or admin may cap an app's calls per month (org_app_settings.monthly_call_cap, Manage workspace → Usage, null by default) and, since #621, set one default cap for every app without its own (org_settings.default_monthly_call_cap, null by default too), refused at the effective cap with 429 app_monthly_cap_exceeded before any provider call. With no cap set nothing bounds the spend: on a self-hosted gateway with one organization this is "an app can spend your OpenAI key unless you cap it"; on hosted it is why the preview stays invite-only (docs/design/2026-10-teams.md).

• A granted OAuth client is all-or-nothing per app (medium; the OAuth-scopes slice: docs/design/2026-10-oauth-scopes.md for the design, #398 merged for the registry's scopePolicy on google-workspace and microsoft-365, #414 merged for the manifest field, #411 merged for the gateway, both 2026-10-24). Before them the gateway completed a network's token endpoints without reading scopes: the app chose the consent's scopes and kept the tokens, so nothing stopped an app granted google-workspace for Search Console from reading Gmail. With #411 on main the invariants in the table below hold. Their honest limits, which stay in this model for the app-driven flow: there the network's API calls still don't pass through the gateway (the app holds the tokens, so the per-set host and path allowlist in packages/sdk/src/internal/oauthScopes.ts enforces nothing on them; the boundary is which tokens an app can obtain). Since 2026-10-25 the Gateway-owned flow (docs/design/2026-10-oauth-providers.md) holds the tokens itself and runs that allowlist on every call (oauth.held-token-scope-routes-live), so an app that uses it is narrowed to its sets by the gateway; the app-driven flow keeps the limits that follow: Google and Slack narrow per app only when the app asks for the status's scopes without include_granted_scopes (a wider token is refused, not narrowed); Microsoft, and Slack installations, may return every scope the person consented to any app on the shared client, which the gateway refuses (availability lost, not narrowing: the fix is one registered client per app); refresh tokens are app-held bearer credentials not bound to an app; and the boundary exists only because the client is confidential (the registry requires a client secret for a scope policy).

  Id	Invariant (#411, merged 2026-10-24; lines at its commit 40159f82)	Enforced by	Pinned by
  oauth.scopes-declared-or-no-token	An app that lists google-workspace or microsoft-365 without a valid scopes list (missing, empty, duplicated, or a name the registry doesn't define) gets no token at all: 403 integration_scopes_undeclared before attribution and before any upstream call.	apps/every-app-gateway/src/server/capabilities/oauthClient.ts:185	oauthClient.test.ts :: refuses an app that lists the client without scope sets (the "scope sets: Google and Microsoft" cases); oauth-client.sqlite.test.ts
  oauth.granted-scopes-within-sets	The gateway never forwards a token whose granted scopes exceed the app's declared sets, on exchange and on refresh, for a person's call and for background calls: the provider's 2xx answer is buffered (64 KiB), its scope parsed per provider, and an excess answers 403 integration_scope_exceeded with the body dropped, never stored, logged or revoked.	oauthClient.ts:384-437	oauthClient.test.ts :: refuses a token outside the app's sets, dropping it; :: refuses the union include_granted_scopes yields; :: refuses a refresh echoing a scope set the manifest dropped, in the background too; the Microsoft case
  oauth.unverifiable-answer-refused	A token-bearing answer that names no scopes is 502 integration_scope_unverified, not forwarded; a non-JSON or oversized 2xx is 502 integration_response_invalid; a read that breaks off is 502 integration_upstream_failed with nothing forwarded.	oauthClient.ts:384, 408, 429	oauthClient.test.ts :: the unverified and broken-read cases
  oauth.request-decided-on-body	The token request is decided on its body alone: grant_type, scope or user_scope in the query string, or grant_type twice in the body, is 400 integration_body_invalid; the grant must be one the client's policy completes (authorization_code, refresh_token) on top of #387's user-grant floor (403 integration_grant_not_allowed); a request asking for a scope outside the sets is 403 integration_scope_not_allowed; Microsoft's request scope is replaced by the app's allowed list, Google's dropped.	oauthClient.ts:227-239, 252, 309, 324, 331	oauthClient.test.ts :: the query-string cases; :: the scope-outside-the-sets case
  oauth.scope-logs-names-only	Logs carry the declared set names and, on a refusal, the scope names in excess (capped), never a token, code, id_token, body or client value, across log, warn and error lines.	oauthClient.ts (the logged object)	oauthClient.test.ts :: logs no client, code or token across a Google exchange, a Microsoft exchange and a refused answer

• The token endpoint signed any grant type (high before #387; fixed there, merged 2026-10-24). Facebook's client-credentials grant returns the app access token <app id>|<app secret>: the operator's secret itself; Discord's, Twitch's and Kick's mint application-level tokens. The proxy now completes only a user's grants (authorization_code, refresh_token, the networks' exchanges, RFC 8693) and refuses the rest with integration_grant_not_allowed.

• App-mail budgets are per address and gateway-wide only (medium, known). One organization's app can exhaust the gateway's 5,000 a day; on hosted, mail from any app goes out as the platform's sender.

• The AI proxy follows redirects; the other proxies don't (low, small fix). A 3xx from a provider to another origin would be followed with the gateway's key in the request.

• The AI proxy passes provider response headers through, set-cookie included (low, small fix). Harmless for a Worker consumer unless the app relays the provider's response to a browser.

• AI_PROXY_EXTRA_ROUTES opens every method and sub-path of a route to every opted-in app across organizations (low, hosted; allowing /v1/files lets any opted-in app list and delete every app's files under the shared account).

• Email budget check is read-then-increment (low): concurrent sends can overrun a budget by the concurrency factor.

• AI request bodies are fully buffered with no size cap (low): email caps at 5 MiB and OAuth at 64 KiB.

• Mastodon's client defaults to mastodon.social (low, known) when MASTODON_URL is unset.

• Reply-To on app mail is unrestricted while From is allowlisted (low).

• A registered provider's hostSetting value is checked for shape only (low, registry slice): a row whose host is the operator's setting (Shopify's shop) sends its key wherever that setting names, a bare host or an https origin, without the public-host and gateway-host rules a row's own hosts pass (providers.row-hosts-public-https, partial). The setting is the operator's, under the row's own prefix.

Merged this week (the teams slice; #381 the counters, #416 the cap): usage counters (usage_daily, usage_monthly; counts only, never bodies or keys) written from the AppGateway entrypoint under waitUntil, and an opt-in per-app monthly cap in org_app_settings (null by default) or, since #621 (migration 0014_caps_defaults), the organization's default in org_settings for every app without one (org_app_settings.unlimited takes an app out of it), refused at the effective cap with 429 app_monthly_cap_exceeded and a Retry-After to the UTC month end, after attribution and before any provider call, a refused call not counted, the cap the attributed organization's own (a shared app's is per organization), the settings cached 30 s per isolate (5 s when none) like the caller cache, a deleted app's caps gone with it. The first answer to the first gap above; pinned by app-cap.sqlite.test.ts (see cap.per-organization-limits in the register).

Docs fixed. docs/capabilities.md lists the checks in the order the code runs them (route, grant, account-wide paths, method and write grant, key and binding, the hosted rule, attribution and the cap, the agent's write scope), since PR 2b of the provider registry.

B5. AI client → /mcp: the OAuth server, personal tokens and the ToolBus

What crosses. An AI client (Claude, ChatGPT, Claude Code, Cursor, a script) holding an OAuth access token the Gateway issued, a personal access token (epat_…), or, behind Managed OAuth, a verified Access assertion; the consent pages a person sees in the browser; the dynamic registration endpoint anyone can call. On the other side, every app's tools, called over the app's binding with a per-call identity, and the provider apps' tools (docs/design/2026-10-mcp-provider-apps.md), which the gateway serves itself and which call the provider through B4's capability proxy. The gateway's own built-ins under everyapp_ cross here too: three read-only ones answered from the caller's view (everyapp_list_apps, everyapp_whoami, everyapp_search_tools) and two wrappers (everyapp_call_read, everyapp_call_write) that each delegate exactly one inner tool call down the same path as a direct call, which is how a client served the compact listing (the built-ins alone in tools/list: automatic past 256 tools or 1 MiB, or chosen with X-EveryApp-Tools or ?tools=) reaches the apps' tools. Since 2026-10-25 a second in-process app kind crosses too: remote MCP apps, any MCP server registered by URL, whose tools the gateway lists from the server and whose calls it forwards there with the operator's credential (B4 holds the credential). The server's tool names, schemas, descriptions and results come back in as untrusted text the model reads. The code is apps/every-app-gateway/src/server/mcp-auth/ (the OAuth 2.1 server on @cloudflare/workers-oauth-provider, consent, registration, validation), src/server/toolbus/ and packages/toolbus/ (the ToolBus: policy, execution, audit), and src/server/services/UserPatService.ts.

What it stops. A token for the gateway's /mcp being used on an app host, or forwarded to an app. A client without PKCE, with a redirect on the platform's own domains, or with an error redirected to its own site. A consent decision taken by a cross-site form, by a different browser, or twice. A read-only connection calling a write tool; anyone calling a destructive tool; a token with API scopes calling tools at all. A revoked connection, removed member or deactivated user keeping access past the next request. A page on another origin driving tool calls with a browser's cookie. A tool receiving a reusable identity, * scopes, or arguments the app's schema refuses. Arguments or results ending up in the audit table. A write tool reached through everyapp_call_read, which mints mcp:read alone; a hidden tool reached through a wrapper or found by the search (hidden stays Unknown tool on every path, where a compact listing only leaves tools unlisted); a wrapper minting an identity of its own, fanning out, or escaping the one audit row, which names the inner tool with via. A remote server's unhinted tool reaching a read-only connection; a tool the operator turned off staying callable; a member registering or changing a remote MCP app.

Invariants. The register has 52 (providers.tools-self-host-admin, the provider tools on /mcp, is in the register only).

Not this boundary's job. What a tool does with valid arguments (the app's code), the AI client's own storage of its tokens, and Access's Managed OAuth grant lifetime (Access's).

Gaps.

• Refresh token replay is never detected (medium, known, medium fix; oauth.refresh-rotation-no-reuse-detection is not enforced). The library accepts the previous refresh token until the latest is used and has no reuse detection, so a stolen refresh token mints access tokens alongside the client until it has refreshed twice. Revoking the connection ends it at once. @cloudflare/workers-oauth-provider 1.2.3 offers no stricter mode; a wrapper that records the last-used token id and revokes the grant on a replay is the fix.
• Personal tokens default to * for 90 days and the UI offers no narrower scope (medium, known, small fix). The create-token dialog offers only access (stored as *: read & write on every app route) or deploy, so the common case, a read-only or MCP-only token for an AI client, can't be made from the UI. TODO: "Access levels for personal access tokens".
• Anonymous GET /oauth/authorize fetches a metadata document before sign-in with no per-address limit (low, small). A client id that is a URL is fetched (under global_fetch_strictly_public) before the user is checked; an SSRF to public URLs only, but unmetered.
• A deploy key's refusal on the gateway's /mcp has no test (low, known).
• Dynamic registration accepts redirect URIs on the platform's domains (low, known): refused where used, kept for 60 days where registered.
• PAT lifetime caps live only in the server-function schema (low). Another caller of UserPatService could mint a token that lasts decades.
• The tokens-only /mcp preflight reflects any Origin (info): the POST is still refused by the origin rule.
• Audit rows store an Access caller's email (info): the only credential kind whose id is personal data, kept for the retention period.
• The tokens page is under /admin while the server functions admit every member (info): any member can mint a token for themselves by calling the server function, which is the intended rule; the UI hides it.

Docs to fix. docs/security-model.md: "redirect URIs must be https or loopback http" holds for the URI an authorization uses; a registration may list other schemes, which are never usable.

B6. Cloudflare Access ↔ the Gateway

What crosses. With the outer ring: every request to the gateway's and the apps' hostnames, which Access has already authenticated, carrying Cf-Access-Jwt-Assertion (and the CF_Authorization cookie); the exceptions are the bypassed paths. With OIDC sign-in: an OpenID Connect code flow between Access and Better Auth. On the other side, Better Auth's sessions and the membership tables. The code is apps/every-app-gateway/src/auth/cloudflare-access/ (the plugin, the JWT verifier, membership rules) and, for Managed OAuth on /mcp, src/server/mcp-auth/access-caller.ts.

What it stops. A forged or foreign assertion signing anyone in. A session being used behind the outer ring by a browser Access didn't authenticate as that person. The apps' Access application vouching for a gateway login. A stranger Access admits getting an account when they were never invited (unless the operator opted into auto-join). An Access identity being handed an existing password account by email coincidence. A deactivated member getting back in because Access still admits them. A site planting a sign-in in someone's browser. The /mcp path taking the Access cookie, which a cross-site POST could ride. Cloudflare Access matches its bypass paths case-insensitively, so /MCP and /OAUTH/TOKEN reach the gateway without a login; the gateway answers every spelling of a bypassed prefix that its MCP/OAuth router doesn't serve (an unclaimed /.well-known/<name> included) with a JSON 404, never the control plane's shell. No control-plane route, server function or auth endpoint lives under /health, /mcp, /oauth/token, /oauth/register or /.well-known/; keep it so. /health is served before that refusal, exact-case, reads no session and says only whether D1 answers (server/health.ts). The one auth endpoint on the bypass list is /api/auth/callback/apple (B10): Sign in with Apple returns with a cross-site POST the browser's Access cookie isn't sent on, which Better Auth answers with nothing but a redirect to the same URL as a GET, which is not bypassed; the POST reads no session and creates nothing, and is served exact-case before the refusal like /health, so every other spelling is the JSON 404.

Invariants. The register has 42.

Not this boundary's job. Whether the Zero Trust configuration matches the runbook (two applications, the bypass list, HttpOnly, the binding cookie): the gateway neither creates nor checks it, it only fails closed on an assertion it can't verify. everyapp access on (PR #379) is the command that sets it up the runbook's way. Personal tokens and OAuth tokens (they never pass through Access).

Gaps.

• Signing out of Access is client-side, from one button, untested (medium, small fix). Only the sidebar's sign-out redirects to /cdn-cgi/access/logout, and only when the cached sign-in-methods answer reported an Access email; the consent page's "switch account" and any other sign-out path leave the Access session alive, so the next page load signs the browser straight back in. The runbook promises more than this. access.sign-out.also-signs-out-of-access is partial.
• The outer ring's security depends on Zero Trust configuration the gateway doesn't verify (medium, known, large). A single application for both hosts, a bypass wider than the list, HttpOnly off, are all silent weakenings to the gateway: access.bypass-list.machine-endpoints-only is not enforced by it (it is operator configuration). Since 2026-10-26 the CLI closes most of the window: everyapp access on makes the right shape, every Gateway upload brings both applications back to it (access.cli.reconcile-on-gateway-deploy), and status reads them back and reports drift (access.cli.status-reports-drift). What stays open: a change made in the dashboard between two runs of the CLI, and a gateway that would refuse to serve behind a shape it doesn't recognise.
• Access's email claim is trusted whatever identity provider issued it (medium, medium fix). A generic OIDC provider that lets users pick their email would let them pick someone else's. The runbook says to enable only verifying providers; the gateway could restrict by idp claim or the operator could pin the identity provider id.
• Account identity is the email, so a recycled address inherits the predecessor's account (info). Both paths key the account by lowercased email, not Access's sub.
• A refused Access sign-in can leave a user row behind in a race (info).
• Managed OAuth and the service-token path are unverified against a live application (low, known; TODO "MCP through Cloudflare Access").

Docs to fix. docs/security-model.md: "The runbook asks for HttpOnly and the binding cookie on both" is true for the plain outer ring; the Managed OAuth body sets the binding cookie off for the gateway's application, as the runbook itself explains. The sign-out promise above.

B7. Operator → Cloudflare: deploy authority on self-host

What crosses. everyapp setup, update, deploy, install, delete, secret, email and db, run on the operator's machine or in CI with the operator's Cloudflare login or an API token: they build the app, check the Build Output against the policy, provision resources, upload Workers, write the registry and the owner setup link in the Gateway's D1, and reconcile the Gateway's bindings. Since #371 (2026-10-23) there is a second path: the browser install, where the Gateway itself downloads a public release and uploads it with a CF_DEPLOY_TOKEN it holds. everyapp teardown --account-id <id> is the one command that deletes everything EveryApp made in an account: it runs only against an id on the test-account allowlist (EVERYAPP_TEST_ACCOUNTS or ~/.config/everyapp/test-accounts), never CLOUDFLARE_ACCOUNT_ID, and asks for the id again (--confirm <id> unattended). On the other side, the Cloudflare account: every Worker, every database, the Gateway included. The code is packages/cli/src/lib/app/policy.ts (the policy), packages/perimeter/src/registry/ (the registration rules the CLI runs before every write), packages/cli/src/lib/gateway/ (discovery, leases, the downgrade guard, releases) and, for the browser path, apps/every-app-gateway/src/server/deploy/install.ts and browser-install.ts.

What it stops. A built Worker that is reachable without the Gateway (a route, workers.dev, a preview URL, a domain), that binds something it wasn't given (another Worker, a foreign database, the gateway's default entrypoint), that ships a helper the manifest doesn't declare, that carries a dev key or the wrong audience, or that deletes Durable Object data it didn't drop. A registry row that takes another app's hostname or Worker name (tombstones included), uses a reserved id, or grants a new app to everyone by default. A secret value on a command line or in output. A deploy from a checkout older than the live Gateway, or over a Worker version everyapp didn't record. A release that was tampered with, or a repository being built from its URL on the operator's machine. Two deploys racing.

Invariants. The register has 52.

Not this boundary's job. Keeping the operator's Cloudflare login safe, or revoking it (Cloudflare's). What a trusted release's code does once deployed (B1–B4 bound it like any app). Reviewing an app's code before deploying it (pnpm security-review helps; the policy checks shape, not intent).

Gaps.

• The browser install is a deploy path on the public Worker, open to every organization owner and admin, untested on self-host (high, medium fix). docs/security-model.md "Operator Authority" records it as the second deploy authority; ADR-0003 predates #371. Once CF_DEPLOY_TOKEN, CLOUDFLARE_ACCOUNT_ID and APP_BASE_DOMAIN are set and BROWSER_APP_INSTALLS isn't off, POST /api/admin/apps/install registers and uploads an account Worker from a public GitHub release or an oss.new URL for any signed-in owner or admin of any active organization, not only the install organization (install.ts:59-104). install-api.sqlite.test.ts claims the route "isn't available on a self-hosted gateway", which passes only because its env sets no APP_BASE_DOMAIN; install.self-hosted-default-on is unpinned and gateway.nothing-public-registers-or-deploys-on-self-host is not enforced. What stands: the admin gate, the CSRF guard, the release intake (integrity, tar refusals, the policy subset) and, behind the outer ring, Access in front of the page. What needs deciding: whether an admin of a secondary organization should be able to deploy at all, or default it off. The security model and this threat model record it as the second authority.

• CF_DEPLOY_TOKEN on the public Worker is account-wide authority (high, known, medium fix). The runbook asks for Workers Scripts Edit and D1 Edit on the account: the token can rewrite every Worker in the account, the Gateway included, and read or write every D1. Whoever reads the Gateway's secrets, or finds a way to make the Gateway call Cloudflare's API, is the operator. A thin deployer Worker that holds the token and accepts only the install's exact operations is TODO "Move CF_DEPLOY_TOKEN into a thin deployer Worker behind DeployerPort".

• The deploy policy doesn't pin the gateway binding's props or the identity settings' values (medium, known, small fix; B3's first gap from this side).

• Top-level Worker config keys and compatibility flags are unchecked by the CLI policy (low, known). tailConsumers (send the app's logs to another Worker), logpush, placement, limits and arbitrary compatibility flags pass through; the gateway's deployer uses an allowlist of keys.

• A helper Worker the manifest dropped keeps running with the app's data access and secrets until delete --purge (low, known).

• Privacy and GATEWAY_URL are enforced at deploy time only (low, medium). After the upload, anyone with the login can enable workers.dev in the dashboard; nothing checks a live Worker for drift until the next deploy. everyapp status is the place for it.

• No test pins that secret set values stay off argv beyond the Hyperdrive password (low).

• secret set|unset on a shared app skip the platform-admin check (medium, known, hosted only).

• Email sending accepts a declared sender on any domain onboarded to Email Sending in the account (medium, small fix): manifest.send-email-senders-required makes every entry name its senders, but a listed sender need not be on a domain among the installation's own (everyapp email set --sender); Cloudflare refuses an unonboarded domain only at send time. Walk-back in TODO "Provisioners: Email sending": require the domain among the senders.

• The Secrets Store dev store is unseeded (low, dev only): everyapp dev doesn't put .dev.vars values into Miniflare's local store, so env.<BINDING>.get() throws until the documented seed script runs; nothing reaches an account.

Docs to fix. ADR-0003: a note that #371 added a gateway-served deploy path. docs/runbooks/browser-app-install.md: "on by default" is true only once the token exists; interactive setup defaults to No.

B8. The hosted tier: the deploy API, the dispatch namespace, egress, third-party hosts, shared apps

Not what launches. Our own install of the same code runs in hosted mode; third-party deploys stay behind THIRD_PARTY_DEPLOYS=on until the launch gate in docs/hosted-vision.md passes, and the Gateway's release config declares no DISPATCHER, so every dispatch row answers 503 today. The boundaries are built and tested against a fake namespace, unverified live. A self-hoster is affected by none of this except where a code path is reachable in self_hosted mode, which the invariants below rule out.

What crosses. A deploy key (deploy-scoped personal token) or an admin's GitHub install bringing customer code into a Workers for Platforms namespace; a member's browser on <app>-<org>.<THIRD_PARTY_DOMAIN> with a per-host session; a dispatched Worker's fetch() to the internet; a shared first-party app serving every organization. The code is apps/every-app-gateway/src/server/deploy/ (the pipeline), outbound.ts (egress), host-session.ts and packages/perimeter/src/hostSession.ts (the handoff), hostSessionAuthenticator.ts, and getAppFetcher.ts.

What it stops. Customer code binding anything the deployer didn't choose, or serving with bindings that differ from what was sent. Customer code on the same site as the control plane's cookie. The first-party session reaching customer code, or a per-host session opening a first-party app. A dispatched Worker reaching a provider with the operator's key, the gateway's own hosts, or anything not on its allowlist (empty today). A deploy key opening an app or /mcp. A tar entry escaping its directory. A handoff code being replayed, used from another browser, or sent to the app in a Referer.

Invariants. The register has 40.

Gaps. (ranked for the hosted shape; none affects a self-hosted gateway unless marked)

• Any organization's owner or admin can deploy public code into the operator's account through the browser install, by default (medium, self-hosted too, small fix): the install accepts any organization the user administers, not only the install organization. See B7.
• The browser install on self-host has no test (high, self-hosted too): see B7.
• connect() from a dispatched Worker is unverified (medium). Outbound Workers intercept fetch(); whether cloudflare:sockets connections pass through them is undocumented. If not, a dispatched app can open raw TLS to any host. Needs a live check before the gate opens.
• Capability and AI-proxy calls are neither refused nor metered for dispatch-tier callers (medium, known): the launch gate's "capability calls refused for dispatch-tier rows" item.
• The org key in a dispatched Worker's name is never compared with the row's organization at read time (low, known; dispatch.org-key-matches-row-organization is not enforced): rows are written only by the pipeline with the organization's own key.
• secret set|unset on a shared app skip the platform-admin check (low, known; shared.secret-set-checks-platform-admin is not enforced).
• PROVIDER_HOSTS is a hand-kept list (low): a provider added later stays reachable from dispatched code until someone adds it.
• The GitHub release download in the gateway has no timeout (low, self-hosted too through the browser install).
• An app-bound deploy key can read any deploy job of its organization (info).
• The egress allowlist ignores ports, and no manifest egress list exists yet (info, known).
• Deleting a dispatch app leaves its namespace script and D1 behind (info, known).
• No sign-out on third-party hosts (info, known): the server refuses the cookie as soon as the gateway session ends.
• The tier is unverified against a live namespace (known, the launch gate).

B9. Gateway → subscriber: outbound webhooks and the email sink

Since 2026-10-25 (#628, main at 2083a662; the design is docs/design/2026-10-events-out.md). The one boundary where the Gateway is the caller and the other side is whoever an owner or admin chose.

What crosses. Out: one signed JSON POST per event and subscription, from the Gateway Worker to a URL an owner or admin subscribed (Slack's Workflow Builder, Zapier, n8n, Linear, their own agent), retried on a schedule for about 35 hours; and the same event as one mail per recipient to the organization's owners and admins through the Gateway's own sender. In: the receiver's status and up to 1 KiB of its answer (200 characters kept in the delivery log), and, over the AppGateway binding (B4), an app's own event (POST /api/events/emit), which becomes app.<id>.<name> on the bus. The subscriptions themselves are made across other boundaries: the control plane (B2: the Events tab and the eight server functions), the CLI's direct D1 writes under the Cloudflare login (B7, ADR-0003: the events group, and the outbox inserts that register, deploy, access and mcp make in their own batch) and, once the twins land, the workspace tools (B5). The code is apps/every-app-gateway/src/server/events/ (catalogue.ts the builders and the one line per event, bus.ts, deliver.ts, signing.ts, target.ts, subscriptions.ts, email-sink.ts, app-emit.ts, cap-events.ts, tool-events.ts, setup-state.ts), apps/every-app-gateway/src/serverFunctions/events.ts, the three Event*Repository.ts files, apps/every-app-gateway/src/db/events.schema.ts (migration 0012_events.sql), the shared rules and limits in packages/sdk/src/internal/events.ts (cited at bb644c05, where #644 added the private-name list and moved the lines below it), and on the CLI side packages/cli/src/lib/gateway/events.ts, packages/cli/src/lib/gateway/eventTarget.ts and packages/cli/src/commands/events/ (#644, main at bb644c05).

What it stops. The bus carrying a credential, a tool's arguments or result, a mail body or a provider's answer to a receiver the operator doesn't control (and to the deliveries list, which shows the envelope). A receiver unable to tell a Gateway's delivery from a forged or replayed one. A subscription making the Gateway call itself, an app host, a private or loopback name or an IP literal (an admin's input turned into a request from the Worker that holds every provider key), or carrying the body wherever a redirect points. An admin of one organization listing, testing, redelivering or receiving another's events. A member, or an agent on a read-only connection, managing subscriptions. An app emitting a gateway type, a credential under a plausible key, or a flood. The email sink mailing an address outside the organization. A signing secret shown anywhere after the one answer that made it. A delivery log kept forever.

Invariants. The register has 10 (and B4 holds the emit route's attribution, events.emit-route-attributed-like-a-capability). The gateway's tests are in apps/every-app-gateway/src/server/events/events.sqlite.test.ts unless another file is named; the CLI's (#644) were read on main at bb644c05.

Not this boundary's job. What a receiver does with a delivery (Slack's, Zapier's or an agent's own rules); whether it verifies the signature (the docs carry the check in three languages; a receiver that skips it is trusting its URL's secrecy); the receiver's availability (a 429 or 503 from it is retried on the schedule like a 500); what an app puts in its own event's data beyond the shape and key rules (an app that emits a customer's address has chosen to); and who may add a subscription: the control plane (B2), the Cloudflare login (B7) and the workspace tools (B5) decide that, and this boundary takes an owner's or admin's choice as given.

Gaps.

• The signing secret is stored as written in D1 (low, known; event_subscriptions.secret; TODO "Events out (2026-10-25)"). The CLI writes subscriptions straight into D1 under the Cloudflare login (ADR-0003) and holds no key to wrap it with; the operator's D1 is root in any case, and a D1 export or backup carries it. What the secret protects is a forged delivery to the subscriber's endpoint, not access to the Gateway: whoever reads it can make a receiver believe an event happened, not act on the Gateway. A wrap under a gateway-held key becomes possible once the Gateway is the only writer of subscriptions (the CLI calling a server function or a deploy-key route instead of D1).
• No automatic pause of a failing subscription (low, known; TODO). A subscription whose receiver is gone keeps getting seven attempts per event for as long as events happen: consecutive_failures climbs, the Events tab and events list show it, and the owners aren't told. Each event costs at most seven outbound requests over 35 hours, bounded by the sweep's 50 rows a minute, so the cost is the operator's subrequests and a log that fills, not a flood at the receiver (which answered 4xx or 5xx, or timed out). A pause after N days of dead letters, with a mail to the owners, is the follow-up.
• A receiver that limits requests sees failures retried on the schedule, not throttled (low). Slack's Workflow Builder webhook trigger takes about one request a second per workflow; a burst of events (an invitation round, a catalog sync that changes several apps) can exceed it, and the refused deliveries come back after 1 min, 5 min, 30 min and so on until they land or die. Nothing is lost (at-least-once; the receiver deduplicates on id) and nothing loops, but there is no per-subscription rate and no reading of the receiver's Retry-After. A per-subscription Durable Object with alarms (the design's walk-back) is where a rate would live.
• The CLI cannot check THIRD_PARTY_DOMAIN (low, hosted only). The CLI's events add reimplements the target rules from the install row's Gateway host and APP_BASE_DOMAIN; THIRD_PARTY_DOMAIN is a Worker secret whose value the CLI can't read back, so a URL under it passes the CLI and is refused by the Gateway at the first attempt (target_refused: gateway_host, retried, never fetched). A self-hosted gateway has no third-party domain.
• A partial send can mail a recipient twice (low; TODO "Events out (2026-10-25)"). Who was mailed is a marker per delivery and recipient in rate_limit_counters (apps/every-app-gateway/src/server/events/email-sink.ts:105-127), written after the send and best effort (a write that fails is swallowed and costs that recipient one duplicate on the retry), and kept three days: past the whole schedule but not the delivery, which redeliver takes while the log keeps it (30 days), with the attempts starting over. A redeliver more than three days after a partial send reads every marker as expired and mails every owner and admin again (events.sqlite.test.ts :: a redeliver more than three days after a partial send mails every recipient again). The duplicate is the same notice to the same members, never a mail outside the organization. A marker kept as long as the delivery (or on the delivery row itself) and a marker write that fails the recipient's attempt close it.
• The target rules are two copies kept in step by hand (info). The Gateway's target.ts and the CLI's eventTarget.ts share the limits through @every-app/sdk/internal; the CLI reads the private-name list from there too (EVENT_PRIVATE_NAME_SUFFIXES, #644) while the Gateway's target.ts still carries its own copy of the same ten names, each with its own order of checks. The Gateway's check before every attempt is the one that counts, so a drift costs an explained refusal at add time, never a delivery the Gateway's rule would refuse; pointing the Gateway at the SDK's list is a one-line follow-up (TODO).
• A delivery's last_error keeps 200 characters of what the receiver answered (info): a receiver that echoes the request puts 200 characters of the envelope in the log, which holds nothing secret by construction; the body itself is never kept.

Credentials: lifetime and revocation

Every credential in the system, how long it lives, what ends it, and how fast. Verified in the code on 2026-10-23; the pinning tests are in the register under the boundary named.

B10. Sign-in provider → the Gateway: Google, Microsoft, GitHub, Apple, Cloudflare and an OIDC issuer

Since 2026-10-25 (the runbook is docs/runbooks/sign-in-providers.md, the catalog packages/sdk/src/internal/signInProviders.ts).

What crosses. An OAuth 2.0 / OpenID Connect authorization-code flow between the browser, the provider and Better Auth's own /sign-in/social, /callback/<id> and /link-social endpoints: the gateway's client id and secret, state, a PKCE verifier and (OIDC) a nonce out; a code, then an ID token or the provider's user and emails APIs in. On the other side, Better Auth's users, accounts and sessions and the membership tables. The code is apps/every-app-gateway/src/auth/sign-in-providers/ (the settings reader, the providers, the generic OIDC provider, the membership rules, the plugin) and the shared src/auth/identity-membership.ts.

What it stops. A stranger with a Google account getting an account on an invite-only gateway. An identity whose email the provider hasn't verified being taken for that person. A provider identity being handed an existing password account by email coincidence. A forged or replayed ID token, one for another client or from another issuer, or one minted for another sign-in (nonce). A posted ID token as a sign-in. A deactivated member coming back through a provider. Anyone signing in before the setup claim. A sign-in method being added by a stolen admin session or agent token (the settings are Worker secrets, and the names are a family no row or manifest can take). A half-configured provider. The ring in front being bypassed: behind the outer ring a provider sign-in is still only the Access person's.

Invariants. The register has 17. The gateway's tests are in apps/every-app-gateway/src/auth/sign-in-providers/sign-in-providers.sqlite.test.ts unless another file is named.

Not this boundary's job. The providers' own correctness (Google's, GitHub's, Microsoft's and Apple's token endpoints, their ID-token handling inside Better Auth's providers, GitHub's emails API). Whether the operator registered the right redirect URL and consent screen (the runbook and everyapp signin show). Personal tokens and OAuth tokens (never issued through a provider). Session cookies, CSRF and the Origin rules (B1, B2).

Gaps.

• Google, Microsoft, GitHub and Apple are Better Auth's providers, run against mocked endpoints only (low, known; TODO "Sign-in providers (2026-10-25)"). The gateway's tests answer their real endpoint URLs with a mock; no live OAuth app was run in this pass (none exists in the loop's account notes). Apple's form_post callback and its six-month client secret are untested live.
• Apple's POST callback behind the outer ring needs a bypass (low, known). everyapp access on leaves /api/auth/callback/apple public (the POST only redirects to the same URL as a GET, which Access then checks); the gateway serves that exact path before its bypass refusal and exempts the POST from the Origin check (csrf.cookie-state-change-same-origin, access.bypass-list.machine-endpoints-only); a ring made by hand without the override blocks Apple sign-in.
• Cloudflare's /user reports no email verification (low, documented). The cloudflare provider counts the address as verified because a private OAuth client is only authorized by the operator's own account members; an operator who makes the client public (permanent, DNS-verified) lets any Cloudflare user, verified address or not, present an email. The setup guide says to keep it private; signin show cloudflare repeats it.
• Microsoft on the multi-tenant endpoints refuses every sign-in until the optional claims are configured (info, documented). Without MICROSOFT_SIGNIN_TENANT and without xms_edov in the app registration's token configuration, no address counts as verified; the setup guide says so.
• No MCP twin for signin add and signin remove (info, by design). The settings are Worker secrets the gateway can't write to itself, and a twin would let a stolen agent token add a way in; signin list and signin show have twins (everyapp_signin_list, everyapp_signin_show; signin.tools.read-state-only).

Known gaps, ranked

Everything this pass found that isn't closed, ranked for the self-hosted launch: what a stranger, a member, an app or an AI client could do that the model says they shouldn't, then what the operator is exposed to, then the hosted tier. Each line names the boundary and, where one exists, the invariant id and the TODO entry. "Fixed" names the pull request; "merged" means it is on main (every boundary fix from this pass merged on 2026-10-24).

Self-hosted, before Monday if possible

1. The browser install lets any organization owner or admin deploy into the operator's account (B7, high; narrowed in #722, merged; install.self-hosted-default-on, gateway.nothing-public-registers-or-deploys-on-self-host). Once everyapp setup has stored a CF_DEPLOY_TOKEN, POST /api/admin/apps/install registers and uploads a public release for any owner or admin (on a self-hosted gateway that is the one organization the setup claim made, so: anyone the owner made an admin), with a token that can rewrite every Worker and database in the account; the release's manifest then grants it the operator's provider keys, sender and members list, which the operator never read. Behind Access the page is behind Access; the token's reach is the problem either way. #722 (Ben's "browser-install authority" decision, merged 2026-10-26; the 2026-10-25 scan's finding 1) builds the strongest default short of a deployer Worker: BROWSER_APP_INSTALLS off unless exactly on (setup writes it with the token when the person opts in) and a session signed in within 10 minutes (install.self-hosted-fresh-session), with self-hosted tests for each; the install organization's owners and admins alike (Ben, 2026-10-26: admins install when it is on). Moving the token into a thin deployer Worker stays the follow-up (TODO "Threat model and security scanning"): with installs on, an owner or admin still spends an account-wide token.
2. The OAuth-client proxy signed any grant (B4, high; fixed in #387, merged). Facebook's client-credentials grant returns the app access token, which is <app id>|<app secret>: the operator's secret handed to the app. Discord, Twitch and Kick mint application-level tokens. The proxy now completes only a user's grants.
3. A release tarball could carry symbolic links, hard links and module paths outside its bundle (B7, high; fixed in #386, merged). The system tar extracted them and cf would have uploaded the operator's private files into the Worker's bundle.
4. The AppGateway binding's props aren't pinned by the deploy policy (B3, B7, high, known; TODO "Redesign stack 2, identity"). On a self-hosted gateway only the operator deploys, so this is the operator misattributing their own app; it is the hosted launch gate's "props pinned on every upload" item.
5. Nothing bounds an app's spend on the operator's provider keys unless a cap is set (B4, high, known; cap.per-organization-limits is enforced only for an app an owner or admin capped, or under a default they set, #416 and #621). A buggy loop in any app runs on the operator's OpenAI or DataForSEO account until the operator notices, or until the app's monthly cap or the workspace's default cap (Manage workspace → Usage; both null, unlimited, by default under Ben's 2026-10-16 ruling) stops it (docs/design/2026-10-teams.md).
6. A read-only MCP token could run write tools on an app that answers /mcp itself (B3, B5, medium; mostly closed by #447, which deleted the SDK's createMcpHandler, the only in-repo way an app served /mcp itself; #404, which patched it, closed unmerged). What remains, by Ben's decision to keep it through launch: the manifest's mcp: { by: "app", why } escape hatch and the perimeter branch that proxies /mcp for it (packages/perimeter/src/gateway.ts) still forward an identity carrying the token's mcp:read scopes to whatever handler the app wrote, so the read-only promise there rests on the app honouring the scopes. Narrowed by the public-surface swath (2026-10-24): an app host serves /mcp only when its manifest sets mcp (with a why the CLI shows), the string form is refused, and on a host without the field an MCP-only token opens nothing, /mcp included. No in-repo app sets it and the starter never did; a post-launch perimeter PR may remove the hatch.
7. A password reset didn't end existing sessions (B2, medium; fixed in #405, merged). Better Auth's revokeSessionsOnPasswordReset was unset, so the standard remedy for a stolen session did nothing to it for up to 7 days.
8. The AI proxy forwarded encoded separators inside an opened extra route, and checked only the first model part of a multipart body (B4, medium; fixed in #403, merged). With /v1/files opened, /v1/files/x/..%2F..%2Fbatches reached OpenAI, which decodes %2F before routing, so the shared key listed the account's batches.
9. An app response's Set-Cookie could keep Domain= past the perimeter: on a first-party WebSocket 101 handshake (B1, medium, known; perimeter.first-party-101-cookie-domain is not enforced; TODO "Strip session-named Set-Cookie headers") and, if the attribute matcher is strict about whitespace and case, on any response: Domain =example.com slipped past the matcher (B1; fixed in #406, merged). A parent-domain session cookie locks every member out until they clear cookies.
10. A stolen admin session can take over any single-organization member and entrench itself (B2, medium): reset links for members, admin invitations, member-to-admin promotion, with no fresh-session requirement. Behind the outer ring the browser must also pass Access as that person, which is the launch mitigation.
11. Script on any first-party app host can overwrite the session cookie and sign the victim's browser in as the attacker (B1, B2, medium; Access in front mitigates). The cookie is Domain=<APP_BASE_DOMAIN> and every app host is one label below, so a page on a sibling host (an XSS, or an app the operator installed) writes a cookie with the same name, domain and path and replaces the member's: a login CSRF across the control plane and every app. The duplicate-cookie refusal catches two copies, not a replacement. A property of the shared cookie (TODO "First-party hosts share the control plane's cookie"); the remedy is per-host sessions as the third-party tier has.
12. Invitations and admin-minted reset links outlive the admin who issued them (B2, medium; fixed in #709, issuer.revocation-ends-what-they-issued). Removing, deactivating or demoting an owner or admin now cancels every pending invitation they sent and deletes every reset link they minted (in that organization; everywhere for a deactivation), and both are re-checked against the issuer's live role when used: an invite link, sign-up through it, Access or a sign-in provider accepting a pending invitation, and /reset-password consuming an admin's token all refuse once the issuer is below admin. The 2026-10-25 scan's findings 5 and 6.
13. Nobody but the holder can revoke a personal token (B5, low). An admin who learns a member's token leaked must remove or deactivate the member; and a member has no page to end their own other sessions.
14. An unclaimed setup link stays valid for 24 hours after the CLI stops waiting, and the agent flow prints it into the agent's output (B2, low; Access mitigates). The link is the whole credential for becoming owner; setup run again replaces it.
15. Public routes are invisible where the operator looks (B1, low): the deploy summary says "Private to you, owners and admins" whatever the manifest makes public, and everyapp access on punches those paths through Access. Fixed in #424: the deploy summary lists them ("Open to the internet without sign-in: GET /t/*, …") and everyapp status shows a PUBLIC column per app.
16. DataForSEO's tasks_fixed was account-wide and served (B4, medium; fixed in #402, merged).
17. No owner recovery for a sole owner (B2, medium, known). Ownership transfer exists: another owner can demote, deactivate or delete a compromised owner, and the last owner is always kept. An organization with one owner still needs the operator (everyapp workspace role <email> owner under the Cloudflare login) to get a second.
18. Signing out doesn't reliably sign out of Access (B6, medium; access.sign-out.also-signs-out-of-access is partial): only the sidebar's button redirects to Access's logout, and only when the cached sign-in-methods answer knew the Access email; the consent page's "switch account" and any other sign-out leave the Access session alive on a shared browser.
19. Access's email is trusted whatever identity provider issued it (B6, medium; fixed in #717, access.idp-allowlist). With CLOUDFLARE_ACCESS_IDP_IDS set, the gateway takes an assertion or an OIDC ID token only from a listed provider (the idp.id claim) and refuses one that names none; email_verified present with anything but true is refused either way. Unset, the runbook's rule (enable only verifying providers) is still the operator's. everyapp access show lists the providers with their ids. The 2026-10-25 scan's finding 7.
20. Refresh tokens for connected AI apps have no replay detection (B5, medium, known; oauth.refresh-rotation-no-reuse-detection is not enforced). A stolen refresh token mints access tokens alongside the client until the client has refreshed twice; revoking the connection ends it.
21. Personal tokens default to * for 90 days and the UI offers no narrower scope (B5, medium; fixed in #716, pat.ui-least-privilege-defaults). The dialog now opens on Read only (mcp:read), one app where there is one, 30 days; Read & write and Full access (*, with a warning) are choices. The service still maps omitted scopes to * and defaults to 90 days for a caller that passes neither; the dialog passes both. The 2026-10-25 scan's finding 8.
22. An admin could mail a reset link to the owner, another admin, themselves or a deactivated member (B2, low; fixed in #407, merged).
23. With GATEWAY_URL missing, the outer ring stops vouching as well as signing in, while the config still reports it on (B6, low; fixed in #711, access.outer-ring.enforced-without-gateway-url). Vouching is now separate from signing in: with the ring configured and no usable GATEWAY_URL, every session still counts only with Access's word for the person and HTTP sign-ins are still refused for anyone else; the ring only stops signing people in, and logs the problem once. The 2026-10-25 scan's finding 14.
24. A held subscriptions/listen stream on an app host's /mcp outlives the token or session that opened it for up to ten minutes (B5, low); the gateway's own /mcp re-checks on every poll, ends the stream at the access token's or Access assertion's expiry, and since 2026-10-24 holds it for 30 minutes (Claude Code parks re-listening after five reopens an hour), keeping the stream open through up to three polls whose D1 read fails, during which it pushes nothing.
25. Any member can read the whole member directory through Better Auth's open /organization/list-members and get-organization (B2, low): emails and roles of the organization. Fine for a four-person company; a decision for teams.
26. everyapp:// was a wildcard-authority trusted origin, and verify-email appended the session cookie to custom-scheme redirects (B2, low; closed by #442). The mobile shell went with #427, and #442 removed the Expo plugin, the everyapp:// trusted origin, the native-origin exemption in the control-plane guard and the Access mobile handoff, so the control plane's same-origin rule has no exceptions left but the token endpoints.
27. An app could publish OAuth authorization-server metadata on its host (/.well-known/oauth-authorization-server, openid-configuration) that legacy MCP discovery honours (B1, low; fixed in #406, merged: both paths are reserved like the protected-resource one).
28. ai.models checks only the JSON model field; OpenRouter's models fallback list is forwarded unchecked (B4, low; fixed in #714, ai.model-allowlist). Every entry of models now passes the allowlist too, and a models that isn't a list of names is refused. OpenRouter's provider routing object picks a provider for the same model, not another model, and is forwarded. The 2026-10-25 scan's finding 13.
29. Consent grants mcp:write to a client that asked for mcp:read (B5, low; fixed in #712, oauth.scopes-are-the-users-choice). A grant is now requested ∩ supported ∩ approved, the connection row records the capped access, the page offers read & write only to a client that asked for mcp:write (or named no scope) and preselects read only; the challenge and the resource metadata name both scopes so a client that follows them can be offered both. The 2026-10-25 scan's finding 12.
30. Proxy-forwarding headers reach apps as the client sent them (B1, low): X-Forwarded-For and friends; cf-connecting-ip is the authoritative address.
31. Revocation windows: 30 s per isolate for memberships, organization status and registry rows; 120 s for an already-minted identity; up to 7 days for a session no one revokes (B1, B2, B3; documented, listed so nobody expects less).
32. A remote MCP server that only takes OAuth can't be used, and its credential is one identity for every member (B4, B5, medium, known; TODO "MCP apps by URL (2026-10-25)"). The gateway doesn't sign in to MCP servers with OAuth yet: such a server can be added and serves nothing ("Not supported yet"). An operator who pastes their own OAuth access token or personal API key as a bearer credential instead gives every member granted the app that person's reach on the server; the server sees one caller. Being an OAuth client (discovery, client registration, PKCE, a callback on the gateway, tokens encrypted at rest and refreshed) is a new boundary, to be designed before it is built.
33. A credential set outside the CLI is pinned on first use (B4, low; fixed in #718, remote-mcp.credential-only-to-bound-origin). The gateway no longer pins on first use: a _MCP_TOKEN with no pin is sent nowhere, every row naming it reads as needing setup with the secret set command, and the refusal is logged (mcp.remote.credential_unpinned). everyapp secret set is the one way to pin, and everyapp mcp show says where each credential is pinned. The 2026-10-25 scan's finding 11.
34. A remote server's tool descriptions, schemas and results are untrusted text the model reads (B5, medium, known). The gateway bounds their size, strips x-mcp-header, and believes a server's explicit readOnlyHint: true (remote-mcp.risk-conservative-default). It can't stop a description or a result from instructing the model, from mislabelling a write tool as read-only, or from steering the model to call another app's tools with what it read. The operator chooses which servers to add, overrides a tool's risk or turns it off (everyapp mcp tool), and Admin → Activity shows every call.

The operator's own exposure

35. CF_DEPLOY_TOKEN on the public Worker is account-wide authority (B7, high, known; TODO "Move CF_DEPLOY_TOKEN into a thin deployer Worker"). Whoever reads the Gateway's secrets is the operator.

36. The old gateway era's Workers ran in the dogfood account (every-todo-app, every-open-seo, every-simple-todo and fourteen more with workers.dev on; TODO "Paused"): pre-#267 code behind nothing. Not this repository's code, but the account that launches. Deleted 2026-10-24 22:54Z by the public-surface thread (cf workers delete <name> --force --delete-with-references, one call per name, under the maintainer's login, after checking each for a Custom Domain, a route, a DNS record, an Access application or another Worker bound to it: none had one): none of the 17 remains, every live Worker is still there, and every old workers.dev host answers 404 (verified 22:54:50Z; everyapp.team still 302s to Access, everyapp.com answers 200). Their D1 and KV bindings (14 each, over 13 databases and 13 namespaces: one pair is shared), R2 (6), one Hyperdrive config and one Secrets Store entry stay for a reviewed list after launch (the per-Worker table is in the maintainers' record of that day, docs/overnight/2026-10-24-old-workers.md, outside the public copy). The five old Workers without workers.dev answer nothing publicly and were left.

37. The published npm versions carry the holes this repository fixed (everyapp 0.2.2, @every-app/sdk 0.2.0; TODO "Paused"): deprecate them.

38. everyapp dev served any name pointed at 127.0.0.1, and its cron trigger took a page's POST (dev only, medium; fixed in #409, CLI). A DNS-rebinding page read and wrote the local app as the seeded owner and could spend the developer's own provider key from .dev.vars.

39. Privacy and GATEWAY_URL are enforced at deploy time only (B7, low): a dashboard change (workers.dev on, a route added) goes unnoticed until the next deploy. everyapp status is the place to read the live Workers back.

40. The Zero Trust configuration isn't verified by the gateway (B6, medium, known): one application instead of two, a bypass wider than the list, HttpOnly off, are silent weakenings. everyapp access on makes the right shape (since #622: the wildcard bypasses nothing, /mcp only where a manifest sets mcp, /health on the gateway's host, both sign-in methods) and everyapp access show says whether the applications it finds match it (paths, sign-in methods, the recorded settings); since 2026-10-26 status reads the applications back and reports drift (ACCESS_DRIFT), and every Gateway upload (update, setup) brings both applications back in line with the release (access.cli.reconcile-on-gateway-deploy); Access is also setup's default unattended (access.cli.default-on). The gateway itself still verifies nothing of the shape.

41. Hygiene before the public copy (the launch-review thread's scan): no LICENSE file. The rest of its list is done: docs/research/ (deleted, #433) and apps/mobile-native/app.json deleted, /docs/internal unpublished, the Postiz fixture's AGPL schema replaced with our own SQL (#458), all 2026-10-24. docs/launch-2026-10-27.md section G.

42. A webhook's signing secret is stored as written in D1 (B9, low, known; TODO "Events out (2026-10-25)"). Whoever reads the Gateway's D1 (the operator, a backup, an export) can forge a delivery to a subscriber's endpoint; nothing it holds opens the Gateway. Beside it in B9: no automatic pause of a subscription that keeps failing, a receiver's rate limit met with the retry schedule, and the CLI's target check without THIRD_PARTY_DOMAIN (low, known).

43. Google, Microsoft, GitHub and Apple sign-in run against mocked endpoints only (B10, low, known; TODO "Sign-in providers (2026-10-25)"). Better Auth's providers, exercised through the gateway's membership hooks with a fetch mock on their real URLs; the generic OIDC provider is the gateway's own and is tested in full. A live run needs an OAuth app in the loop's account.

44. Apple's POST callback needs /api/auth/callback/apple public behind the outer ring (B10, low, known). everyapp access on does it; a ring made by hand without it blocks Apple sign-in. The POST creates nothing.

45. signin add and signin remove have no MCP twin (B10, info, by design). The settings are Worker secrets; a twin would let a stolen agent token add a way in.

Hosted only (nothing here reaches a self-hosted gateway)

46. A dispatch-tier Worker sends mail from the platform's own sender and spends the platform's provider keys with no per-organization bound (B8, medium; fixed in #715, tier.dispatch-no-capability-broker: the AppGateway entrypoint refuses every dispatch row with 403 caller_tier_refused before the route is read, so the launch gate's "capability calls refused for dispatch-tier rows" holds; a per-capability hosted grant table is the day the hosted tier wants them back). The 2026-10-25 scan's finding 2.
47. With open sign-up, anyone with an invite link can plant an account for someone else's email, which the victim's own verification click then hands over (B2, medium; HOSTED_OPEN_SIGNUP=false keeps the preview invite-only, where the invite link's email binding stops it).
48. connect() from a dispatched Worker is unverified against the egress policy; the org key in a dispatched Worker's name isn't compared with the row's organization; secret set on a shared app skips the platform-admin check; the platform-domain refusal doesn't cover THIRD_PARTY_DOMAIN; an organization's app may take a shared app's slug and the gateway's /mcp routes the tool call to the first; a handoff code presented in the wrong browser isn't consumed; there is no sign-out on third-party hosts (B8, low). All recorded in TODO.md's hosted sections or the launch gate.

Roadmap, not gaps (cited, not restated): per-member token scopes, approvals for destructive tools, per-app roles in the identity, read-only members, SSO-only guarantees, audit export and IdP group mapping are the teams design's roadmap (docs/design/2026-10-teams.md); per-app provider scope narrowing is the OAuth-scopes design (docs/design/2026-10-oauth-scopes.md).

Verification

• The tests named in this document. Each invariant's pinned_by names the file and test. docs/TESTING.md lists every suite and the end-to-end perimeter test (packages/perimeter/src/integration/e2e.test.ts) that wires the real proxy core to a real app built with the real SDK.
• The security review, locally. pnpm security-review (scripts/security-review.mjs) runs Claude Code non-interactively in restricted mode (read-only tools confined to the checkout, the branch's settings and hooks ignored), over the branch's diff: the audit prompt of Anthropic's security review for Claude Code (scripts/security-review/audit-prompt.md, pinned to the upstream commit it names), this repository's boundaries (scripts/security-review/scan-instructions.md) and its false-positive rules (scripts/security-review/false-positives.md), judged against this model; it exits 1 while a high or medium finding remains. The review is advisory and not hardened against prompt injection: the diff enters the prompt, so a stranger's pull request gets a person's read first, and the command runs the branch's own copy of the script. The security-review skill (.claude/skills/security-review/SKILL.md, the same at .agents/skills/) says when to run it and what to do with a finding; packages/cli/src/lib/securityReview.test.ts pins the script's exit codes, what the diff carries and the flags Claude Code gets, with a fake claude. There is no CI job and no API key in the repository: the maintainer chose local skills over a review in Actions (2026-10-24). New apps get the app boundaries and the recipe in the everyapp skill (packages/cli/skills/everyapp/security-review.md).
• Dependency audit. pnpm audit runs in CI on the lockfile and fails on critical advisories (.github/workflows/pr-checks.yml).
• A live Gateway. everyapp status says whether the live Gateway was built from the checkout's sources; docs/runbooks/mcp-oauth.md and docs/runbooks/cloudflare-access.md each end with a checklist for a deployed gateway.

Reporting a problem

EveryApp is alpha and open source. If you find a hole, we'd rather know:

• Open a private vulnerability report on the repository (Security → Report a vulnerability) so it isn't public before a fix is out.
• Say which invariant breaks (its id from this document), the shape it affects (self-hosted, hosted, both; with or without Access in front), and how to reproduce it. A failing test is the best report.
• Expect a fast, informal reply from a very small team. There is no bounty.