Scope, sandbox, and gate are three different controls for

An illustrative scenario, nothing more. An agent is asked to tidy up the team's onboarding doc. Its scope says it may edit that doc and nothing else. Its code runs in an isolated sandbox. Someone configured both, someone checked both, and both are working.

The agent rewrites the doc. In the rewrite it drops the access-request section half the team relies on, and the write lands. The doc is now wrong in a way nobody chose.

Both controls worked. The write landed anyway.

The gap between those two sentences is the whole subject. Blast radius is one word doing the work of three different controls, and it is easy to trust the first two to answer a question only the third one can.

What blast radius names, and why one word hides three different controls

Blast radius names three controls: scope limits what an agent may touch, a sandbox limits where its code runs, and a gate decides whether a write lands. When a write lands that nobody wanted, the usual cause is a control trusted with a question it cannot answer.

There is a portable test. Ask it of any platform. What may the agent touch? Where does its code run? And when the agent decides to write, what stands between that decision and the write becoming real? Three questions. Harden one and it is easy to believe you hardened all three.

Scope: what the agent is allowed to touch

Run the scenario with only scope in place. The agent may edit the onboarding doc. The rewrite sits inside its permissions, so it lands. Scope did exactly its job.

Least privilege is real, and you should use it. A read-only agent has no write blast radius at all, and that is a fine way to live. But a useful agent needs write scope, and scope works in classes. It grants edits to a document, not judgment about which edits are good. The dropped section was in scope. Nothing in the scope configuration ever saw it.

Scope answers what. It has no opinion on whether, and no opinion on when. Scope without a gate still lets a bad write land, which is the opening scenario in one line.

Sandbox: where the agent's code runs, and what it does not isolate

Agent code runs in an isolated sandbox (E2B). A sandbox limits where code runs, not whether a write to shared data is allowed.

Run the scenario with only the sandbox in place. The rewrite script executes contained. If it tried to read outside its box or spawn a stray process, that is the sandbox's job. But the rewrite of the shared doc is something else. The code ran in the right place; the problem is the durable write it requested through the ordinary API. Containment has no opinion on permission.

The pairing fails in the other direction too. A sandbox without scope still shares credentials. The contained code runs with whatever the agent is allowed to use, and containment is not permission.

Gate: whether a consequential write lands at all

A consequential agent write is held as a proposal by a pre-application, server-enforced approval gate, and it never lands until a human accepts it. In our platform the gate is enforced at three independent layers. The coverage is specific: the automatic halt covers snip_rewrite and snip_patch only, creation and metadata are ungated, and it depends on autoAccept being off. Narrower than it sounds, and it keeps the queue to rewrites of existing content.

Under that gate, the rewrite never becomes the doc. It waits as a proposal until a person accepts it or it does not happen. The smallest blast radius is a write that never lands.

That is why the gate belongs in the platform, not in a workflow. A rule written as text describes a boundary but cannot halt an action. The rule you wrote in five seconds gets worked around for ten weeks. A gate on the execution path halts the action. The description sits beside it.

The held proposal buys one more thing. Evidence. The write sitting in the queue is the record that the control fired. Not a claim about enforcement. The enforcement, waiting to be read.

Where isolation stops: org-scoped data, not org-isolated compute

Per-org isolation is Postgres row-level security at the data plane. Organizations share one process and one set of workers: org-scoped, not org-isolated.

Row security is a policy on rows, not a wall around compute. The PostgreSQL documentation describes it plainly: row security policies restrict, per user, which rows normal queries return or data modification commands can change. "Superusers and roles with the BYPASSRLS attribute always bypass the row security system when accessing a table." A policy like that separates which rows one organization can read and write, and nothing more. That is what per-org isolation means here.

There is no per-org isolation at the level of compute, memory, or filesystem. On compute isolation, this is currently unanswerable. If you own blast radius for a stack where that is disqualifying, hold that verdict.

What none of the three controls covers

The strongest objection to a gate is that approval queues decay into rubber-stamping. None of the three controls covers a human who approves without reading. Scope cannot read, the sandbox cannot read, and the gate can only wait. If the approver skims, the dropped section lands with a green check next to it. No mechanism closes that gap, and pretending one does is how a control becomes decoration.

The second objection is the claim that one control can cover the other two. Configure scope plus sandbox well enough and nothing lands that should not. The opening scenario is the whole answer. The write was in scope, the code was contained, and it landed.

Run the scenario one last time with all three controls in place. The rewrite is in scope, so it is allowed. The code is contained, so nothing leaks while it runs. The write is held (a rewrite, with autoAccept off), so before the doc changes, a person sees a proposal missing the section half the team relies on.

Then the three questions are yours. What may the agent touch? Where does its code run? What stops a write it is allowed to make? Ask them of any platform you are evaluating. Ask them of ours.

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Blast Radius Is One Word Doing the Work of Three Controls: Scope, Sandbox, and Gate" } </script>