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

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

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.

Beyond the standard platform

Some tenancy requirements are addressed by enterprise capabilities rather than by the standard platform, and some aren't addressed at all. Both are listed, because a clear "no" early beats a hopeful "let's discuss".

Note the split in that table. An enterprise deployment can give you your own account boundary and a database in a region you choose — but nothing changes where your code executes, which is nearest the user on every tier. If your obligation covers processing location and not just storage, bring the exact wording.

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.