Isolation and tenancy

Security reviews get evasive answers to this question often enough that being precise is a differentiator. So: what is actually isolated, by what mechanism, and where does it stop.

The three boundaries

1. Between apps — separate everything

Each app gets its own worker script, D1 database, KV namespace, Durable Object namespaces, and R2 bucket. There is no addressing path from one app's code to another's bindings: a binding is a capability handed to a specific worker at deploy time, not a name to be looked up. One app cannot enumerate, connect to, or query another's data.

2. Between environments — separate state, shared code

Production and staging of the same app share source, history, agents, and connectors, and have separate databases, key-value namespaces, object state, and metrics datasets. A non-production database starts empty. Staging cannot read production rows, which is what makes it safe to give a wider group access to. See Environments.

3. Between platform tenants — isolates, not dedicated hardware

Here is the honest version, because the marketing version fails diligence:

Your code runs in a V8 isolate — the same technology that keeps one website's JavaScript from reading another's in your browser. Each isolate has its own heap and cannot address memory outside it. It is strong memory and execution isolation on shared infrastructure, and it is not dedicated single-tenant compute.

What that means practically:

• Memory is not shared between tenants. No process, heap, or filesystem is reachable across the boundary.
• Your code cannot enumerate other tenants, their workers, or their bindings.
• Infrastructure is shared. CPU, network, and the underlying hosts serve many tenants — the same model as every major serverless platform.
• The security boundary is the isolate, maintained by Cloudflare and by V8, and it is the most battle-tested sandbox in computing, precisely because every browser depends on it.

If your requirement is dedicated, physically separated compute, this platform does not provide it today, and no amount of phrasing changes that. Better said now than after an architecture review.

Secrets

Property	Behavior
Storage	Per-environment worker secrets, injected at deploy time
Readability	Never readable back — listing returns names only
Scope	One environment of one app
In source	Never — and reserved platform names are rejected if you try to set them
In the browser	Never — server-side only
Rotation	Set again; the new value attaches on the next deploy

Platform-injected values (the app id, the capability endpoint, the tenant key, the routine signing secret) are provisioned automatically and always correct — including after a clone — which is why application code should read the injected app id rather than hardcoding one.

The tenant capability key deserves specific care. It can reach every integration your team has configured, so it is server-side only: never in a response, never in a log line, never in client code. Detail in Domains and secrets.

Credentials for third-party systems

A pattern worth highlighting in a security review, because it removes a whole category of exposure: integration credentials live in platform connectors, not in your app or your agents' prompts.

• An agent calling an external service does so through a platform capability. It never sees an API key.
• A repository-reading agent gets an ephemeral clone credential vended per use, with the connector's repository allowlist enforced. No git secret is ever in your worker.
• Connector access is scoped per team member and per connector — read, write, or admin — so a contractor's agent can be denied the payments integration.

The net effect: a compromise of your application code does not hand over your third-party credentials, because they aren't there.

Network egress

Workers egress from Cloudflare's shared, changing IP ranges, so a third party requiring IP allowlisting cannot allowlist a Worker directly. For those cases the platform provides a static egress address to hand to the third party — see Files and assets. Ordinary public API calls don't need it.

Access control

Layer	Mechanism
Platform sign-in	Email one-time code — no passwords to leak
Team membership	Roles per team
Connector access	Read / write / admin, per connector per member
App conversation access	Granted explicitly
Machine access	API keys, scoped to a team
Your application's own users	Yours to implement

That last row is not a gap — it's the boundary. The platform authenticates your team; authenticating your customers is your application's job, and it's the right place for it. Where an AI agent serves an authenticated user, identity arrives as verified claims the agent cannot be argued out of, and tools must read the user from that rather than from model arguments. See Browser chat.

What we don't offer today

Requirement	Status
Data residency guarantees	Not offered. Compute runs nearest the user
Bring-your-own Cloudflare account	Not available
Dedicated / single-tenant compute	Not available
Customer-managed encryption keys	Not available
On-premise or air-gapped deployment	Not available
Private network / VPC peering	Not available
SSO / SAML / SCIM for platform sign-in	Not available today
HIPAA	Not claimed

What is in place: SOC 2 Type II attestation and ISO 27001 certification, with a GDPR data processing agreement available. Reports and certificates are shared under NDA — ask your account contact. Full posture in SLAs, limits and quotas.

This table exists because a clear "no" early is worth more to both of us than a hopeful "let's discuss" that wastes a quarter. If one of these is a hard requirement, start the conversation with it.

Next

• SLAs, limits and quotas — commitments and compliance in full.
• Observability and audit — what's recorded and for how long.
• Domains and secrets — configuring secrets in practice.