Beyond the Sandbox

A sandbox protects the host from the agent. Confinement protects everything the agent can reach from the agent.

This paper is for teams that select, build, or review an agent runtime. It sets out the architecture confinement requires, the four properties that define it, how to test them, and the evidence a confinement claim must carry.

By our definition, an agent is confined when four properties hold together. It holds no credential it can use as authority on its own (P1). Every external effect receives a policy decision it cannot bypass (P2). It cannot change the policy, the decision point, or the recorder (P3). Every decision and every blocked attempt is recorded where it cannot alter them (P4). An environment that meets only some of the four is unconfined with mitigations.

Confinement of effects, not of information flow. “Everything the agent can reach” means every system the agent can act on: confinement decides each action it attempts there. It does not stop information from leaving. Data the agent reads for its task travels with every permitted request, including every permitted model call, and an agent can encode information in the timing, ordering, or content of permitted traffic. Confinement bounds those flows to permitted channels where content checks apply, and no further [2]. Section 6 sets out what remains.

The properties restate established results on reference monitors, complete mediation, and least privilege [1–3]. What this paper adds is a threshold for agent environments and the tests that decide whether it has been met.

Status. The procedures in Section 9 summarize the draft Confinement Conformance Tests. A result reported against them is an assessment, not a certification, and this paper asserts no conformance result for any product.

Treat the agent, its harness, and any code running with its privileges as potentially compromised. Four sources can direct an agent’s authority: an instruction planted in content it reads, a poisoned tool or MCP server response [8], a compromised dependency, and its own mistaken reasoning. Nothing inside the agent reliably predicts which will occur. The boundary therefore does not try to tell them apart; it decides every effect against policy.

Isolation and confinement

Isolation separates the agent from its host and from other workloads, so a fault or an attack inside it does not reach them. Confinement governs every effect that crosses the agent environment’s boundary. Isolation is the substrate confinement rests on, because only an isolation mechanism can close channels by construction, but isolation provides none of the four properties by itself. Escape to the host remains isolation’s responsibility.

What the boundary is trusted to do

The boundary is trusted to bind each request to the right principal, decide it against policy, apply credentials, and write the record. Two things sit outside the four properties and need their own assurance: the correctness of the policy (Section 6) and the hardening of the boundary itself (Section 5).

A request moves through the boundary in five steps:

1. The agent submits an operation. It carries no credential, and the boundary refuses any it presents as authority.
2. An enforcement point in the path binds the request to its principal, the user or service the agent is or acts for, and asks the decision point for a decision on that principal and operation.
3. On allow, the credential service applies the boundary’s own credential to that exact request. On deny, the request stops at the enforcement point.
4. The authorized request goes to its destination.
5. The recorder writes the decision, whichever way it went. Attempts the isolation layer blocks before any decision are recorded as attempts.

The boundary need not be one gateway. Proxies, sidecars, and per-destination connectors can all serve, provided that together they cover every external effect, bind principals consistently, and keep the controls and the record protected.

Destination authorization

A destination’s own authorization still matters, but it usually decides what the presented principal may do. The enterprise’s policy for an agent acting for that principal is often narrower: limited to the task, to certain resources, or to non-destructive operations. Enforcing policy at the destination can satisfy mediation there, but handing the agent the credential it presents still fails P1.

• P5a, tamper evidence. Any insertion, deletion, reordering, or backdating is detectable by a verifier who does not trust the recording system.
• P5b, self-sufficiency. The record alone establishes what was attempted, on whose behalf, and under what authorization.

Tamper evidence requires proof of the record’s contents held where neither the recorder nor its operator can alter it, plus a stated window between anchors during which a change could go undetected. Append-only logs that anyone can audit, such as Certificate Transparency [6], and database ledgers that anchor digests in storage outside the administrator’s control are established patterns.

Neither P4 nor P5 shows that the recorder recorded truthfully in the first place. That rests on the recorder sitting outside the agent’s reach (P3) and on the recorder itself being sound.

Credential exchange and standing keys

Where a destination supports token exchange, prefer it [5]. The boundary holds a subject token for each active principal and exchanges it at call time for a short-lived destination token; the agent never receives either. A compromise of the boundary then yields tokens only for the principals active at that moment, and only until the boundary’s exchange client is revoked or the subject tokens expire.

That bound depends on three conditions the token-exchange standard does not guarantee: the identity provider logs every exchange, the boundary’s exchange client can be revoked there, and the boundary holds no refresh tokens or other standing credentials beyond that client. Where a destination cannot support exchange, the boundary holds a standing key for it. If concentrating that key is unacceptable, remove the destination from the confined agent’s reach, or serve it from a separate agent population under the conditions in Section 7.

Sessions and protocols

Because the boundary applies the credential, it opens every authenticated session to each destination. Three requirements follow:

• Trust. Clients that pin certificates or carry their own trust bundle must trust the boundary or be replaced.
• Protocol coverage. Most of what agents call, including model APIs, SaaS APIs, remote MCP servers, and gRPC services, runs over HTTP. Database wire protocols and message queues need their own support or must be blocked.
• Granularity. Policy finer than destination, method, and path requires the boundary to understand each API it decides on. An allowlist of destinations cannot authorize individual operations within them.

Assuring the boundary

The boundary is the most concentrated part of the design. It sees every request in plaintext, so it and the record are processing locations subject to the same residency, access, and retention rules as the systems they front. Every mediated effect waits for a decision, which adds latency, and because the boundary fails closed in front of every agent, it must run at the availability of the services it fronts, for recording as well as for decisions.

Review it as you would any credential store: credential access, identity provider configuration, patching, administrative access, resource exhaustion, and recovery. Passing the confinement tests does not substitute for that review, and a confinement claim says nothing about it.

Policy and reach

Confinement makes the stated policy the one enforced. It does not make that policy correct: a confined agent under a permissive policy can do everything that policy allows, which is why every claim must state its policy. The record exposes policy errors in both directions, as denials of necessary work and as permitted decisions a reviewer can question.

Assess reach transitively. A permitted destination can proxy requests, run supplied code, or carry a vulnerability that opens another system. In July 2026, an agent left its evaluation environment through a zero-day in a package-registry proxy that was one of its permitted egress paths [9]. Record such findings, then harden, constrain, or remove the destination. Mediation alone does not repair it.

What it cannot cover

Confinement cannot govern a SaaS platform’s own agent inside that platform, or agents already running on desktops and in browsers where no boundary can be placed in their path. It narrows covert channels to permitted traffic where content checks apply, and no further [2].

Where the enterprise runs a boundary, confine by default and record each exception with its reason. Elsewhere, an isolated deployment is acceptable for an agent population while all four conditions hold, each recorded in the design review as evidence:

1. Every path out ends at a gateway that decides each call or at an allowlisted destination, and none reaches the internet directly. Each allowlisted destination adds whatever it can be made to reach.
2. Credentials are short-lived and scoped to actions whose worst misuse is acceptable, with destination controls or human approval limiting them further. P1 excludes such credentials; here they are accepted as mitigations.
3. Nothing reachable extends the agent’s authority: no instance metadata endpoint, mounted secret, leaked token, or reachable service. Recheck on a schedule, and suspend the agent when a check fails.
4. The residual risk is recorded, including misuse of permitted destinations through permitted requests.

Describe such an environment as unconfined with mitigations. When a condition fails and cannot be restored, the options are confinement, a narrower reach, or not deploying the agent. A badly run boundary can give less assurance than a well-run isolated deployment with a narrow task, and a design review should say so.

Revocation is not a clean stop:

• Work already handed to a destination completes or fails there. Completed steps are not rolled back.
• Streams and sessions opened under the old policy must be closed, or each message decided afresh. Otherwise they keep producing effects under their opening decision.
• Denying model calls stops remote inference. A model running inside the environment keeps reasoning, though its effects are denied.
• The harness can still retry, hold locks, and keep transactions open. Contain it with host-enforced limits on compute, memory, request rate, and session lifetime.
• Dependent services stall and may need compensation.

Live revocation is reported separately and is not a condition of confinement. A runtime that loads policy only at session start can be confined and still need a shutdown. T3 measures propagation time, in-flight work, and stream behavior.

The qualifier is part of the name: a result resting on attestation is Confined (attested) or Accountable (attested) and cannot be shortened to the tier alone. An effect the operator discloses as outside the boundary is a P2 failure, not an exclusion that preserves the claim.

The form of a claim

Confined (evaluated | attested), [date]
Evaluator      [operator | supplier | independent party]
Environment    [runtime and version]
Tests          Confinement Conformance Tests [version]; probes [list]
Evidence       [black-box | disclosed | attested]
Policy         [what it decides on, or the policy itself]
Revocation     [reaches running sessions? closes streams? how fast? | not measured]
Reach          [paths from permitted to unpermitted destinations | none found]
Exclusions     [destinations removed from the agent's reach | none]

The policy field is required because a tier says nothing about how much the agent may do. A claim without these fields cannot be confirmed. Of any environment, your own included, ask which tests it passes and who ran them.

• The credential inventory, at rest and during calls
• The outbound-channel and trust-domain map
• Principal and policy definitions
• Test findings, with probes, evidence class, and evaluator
• Record reconciliation results
• Live revocation measurements
• Destination reach findings and exclusions
• The boundary assurance review
• The residual-risk decision and its owner

Re-evaluate when the runtime, the policy, the destinations, or the identity design changes.

Start with one agent population

Map its authority and reach, run T1 to T4 against the environment it actually runs in, and document the permitted policy and residual risks before expanding its responsibilities. For the business case and the questions to ask a vendor, read the executive paper, Confining AI Agents.