What Agent Run Isolation Means for Production Deployments

Most agent platforms run every task with the same credentials, the same network reach, and the same identity. That holds up in a demo. It stops holding up the first time one run reaches a secret it had no business touching, calls an endpoint it was never meant to reach, or takes an action the logs attribute to the wrong actor.

Agent run isolation is the property that prevents this: each run gets only the access that run needs, and nothing it does leaks into another run. As operators move agents out of experiments and into production, run isolation is what separates a platform you can put in front of real data from one you can't.

The vocabulary is still forming. A running list of "agent jails" made the rounds on Hacker News recently, and a sandbox-escape report covering four coding agents landed in the same window. The interest is real and the language is early.

What a run touches

Three distinct things cross the boundary of an agent run, and each is its own isolation problem. Treating them as one is how platforms end up with the illusion of isolation and none of the substance.

Credentials

An agent run needs secrets: an API key, a database password, a vault token. The failure mode is a shared credential pool, where every run can read every secret the platform holds. One misbehaving or compromised run then exposes all of them at once.

Run-bound secret access closes this. Secrets are bound to the specific run that needs them instead of sitting in a pool the whole fleet can read. Paperclip shipped run-bound secret access in v2026.722.0, and Hermes v0.19.0 added native Bitwarden and 1Password integration in the same window, so the vault stays the source of truth and the agent receives a scoped grant rather than a copy. This is the credential-confinement layer, and it has its own detailed write-up coming in this series. The point here is narrower: credentials are one face of isolation, not the whole of it.

Network egress

A run that can reach any endpoint on the internet can exfiltrate anything it can read. Egress control scopes each run's outbound network to an allowlist, so this run reaches these hosts and no others. It is the boundary operators most often skip, because an open network is invisible until something abuses it, and by then the data is already gone.

Paperclip recently landed task-scoped egress grants (#10155): each run's outbound access is provisioned per task rather than left open by default.

Attribution

Isolation is not only about what enters a run. It is also about correctly recording what a run did. When a run's writes are attributed to the wrong actor, a subtle failure appears: the boundary between "the agent did this" and "a person did this" dissolves, and you lose the ability to reason about what any single run was responsible for. Attribution gaps are not only an audit problem. A run mis-stamped as a user action has been enough to trigger a self-sustaining wake loop that quietly burned compute until someone noticed. This is the run-attribution layer of the governance stack, and it is why isolation and accountability are the same problem seen from two sides.

What it means for production deployments

When you evaluate a platform for production, run isolation stops being abstract and turns into a short list of questions you can actually check:

• Can a run read a secret that belongs to a different run or project? If every run shares one credential pool, you do not have credential isolation, you have a blast radius.
• Is a run's outbound network open by default? An agent that can POST anywhere can leak anything it reads.
• When a run writes to a system, who does the record say did it? If runs are stamped as a generic user, you cannot audit them and you cannot trust a kill switch to stop the right thing.
• What is the blast radius when a run misbehaves? Isolation is what lets you stop one run without stopping the fleet, and keeps the damage bounded to that run.

The payoff is not hypothetical. The same week those "agent jails" lists were circulating, a sandbox-escape report showed four production coding agents could be broken out of their sandboxes. Isolation is what stands between an agent that is contained when that happens and one that is loose inside your infrastructure.

Where this is going

Run isolation is moving from a nice-to-have to a baseline expectation, the way audit logging did for SaaS a decade ago. The platforms that treat each run as its own scoped environment, with its own credentials, its own network boundary, and its own attribution, are the ones operators will trust with production data. I expect "agent jails" and the surrounding vocabulary to keep shifting for a while. The mechanism underneath it is already clear, and it is worth building against now rather than after the first incident.

If you are standing up agents on infrastructure you actually control, this is the kind of thing I write about every week. Follow along.

— Kimmo