Skip to main content

Confinement

AgentVisor™ confines AI agents. This page defines what that word means, explains why it is not the same thing as sandboxing, and maps each property of confinement to the AgentVisor features that provide it.

Definition

Confinement is a property of an execution environment in which an agent holds no ambient authority, every outbound effect is mediated by a policy decision the agent cannot bypass, the policy, the decision point, and the recorder sit in a trust domain the agent cannot modify, and every such decision is recorded in an account the agent cannot alter.

The definition breaks into four properties. An environment is confined only if it satisfies all four. An environment that satisfies some of them is not "partially confined": it is unconfined, with mitigations, and should be described that way.

PropertyRequirement
P1: Zero ambient authorityNothing in the agent's execution context can be used directly against an external system.
P2: Complete, non-bypassable mediationEvery outbound effect produces a policy decision before it takes effect, and the agent cannot opt out.
P3: Tamper-resistant control planeThe policy, the decision point, and the recorder live in a trust domain the agent cannot modify.
P4: Independent recordEvery decision, including denials, is recorded by the control plane, and the agent cannot alter the record.

Sandboxing and confinement​

A sandbox protects the host from the guest. A browser sandbox, a seccomp profile, a hypervisor guest, and a container all limit blast radius: a fault inside the guest does not propagate into the machine that runs it. A sandbox holds no opinion about what the guest does within its permitted bounds.

Running an agent adds two problems a sandbox was not built for:

  • Authority. A working agent, possibly steered by instructions injected into the data it processes, takes real actions against real systems using real credentials.
  • Accountability. Afterward, nobody can establish what it did, on whose behalf, or under what authorization.

Confinement addresses the first directly and requires a record that the agent cannot alter.

Isolation is not being downplayed here. For an agent that executes code, only an isolation mechanism stops it from reaching the raw substrate and making an unmediated syscall, socket, or subprocess. The sandbox is how the boundary that mediation needs is actually built, which makes it necessary but not sufficient. A sandbox that still holds the agent's cloud keys in its environment, with no per-request policy decision and no independent record, is fully isolated and completely unconfined.

This is also why AgentVisor keeps the word sandbox where it means the isolation layer: the --sandbox flag, the sandbox modes, and the gVisor or Docker boundary around the guest.

Confinement is not simply access control either. Role- and attribute-based access control answer whether a given principal may take a given action on a given resource, and confinement builds on that check: the policy decision is that check. What access control assumes is that the subject making the request sits inside the trusted computing base. An agent does not. Its request can carry an injected instruction, and it may hold broad credentials in a context it does not control. Confinement moves the agent outside the trusted computing base, so that every effect it attempts produces a policy decision and a record, and it holds no authority of its own to use.

How AgentVisor addresses each property​

P1: Zero ambient authority​

The agent never holds a usable credential. AgentVisor injects symbolic tokens into the guest instead of real API keys. A token stands in for a credential but cannot itself be used outside the boundary. The host substitutes the real credential only after a policy decision, and only for destinations you have explicitly configured. Short-lived credentials delivered into the agent's context would not satisfy P1; the test is possession, not lifetime.

OAuth flows are covered too: with a response_intercept rule, the real access_token and refresh_token returned by a token endpoint are replaced with symbolic tokens before they reach the agent.

AgentVisor keeps real credentials out of the guest when they are routed through credential brokering. Credentials placed in the guest by other means, such as forwarded environment variables, .env files, mounted files, or the image itself, are ambient authority, so supply credentials through brokering rather than alongside the agent.

See Credential Brokering.

P2: Complete, non-bypassable mediation​

Every outbound effect leaves the sandbox through a single channel, the hostlink session, and is policy-checked by the Manetu PolicyEngine on the host. That covers HTTP and HTTPS egress (including CONNECT tunnels, which are TLS-terminated so that policy can see the request), MCP tool and resource calls, A2A calls, key-value and state access, and calls to model APIs.

Completeness comes from how the environment is built, not from the agent cooperating:

  • In gvisor and docker modes on Linux, the guest has no network interface beyond loopback. There is no other route out.
  • In docker mode on macOS and Windows, where the guest needs a TCP route to the host, nftables rules restrict outbound traffic to the host link only, and the capabilities needed to change those rules are permanently dropped.
  • The proxy environment variables are a convenience for standard libraries. Unsetting them does not open a path, because there is no path to open.
  • A WebSocket or other HTTP upgrade is authorized when the connection is established. Once the upgrade completes, the frames that follow are relayed without a further decision per frame.

See Architecture, Egress Controls, HTTP Proxy, and Policy Enforcement.

P3: Tamper-resistant control plane​

The policy domain, the decision point, and the audit pipeline run in the host runtime, outside the guest trust domain. The guest neither evaluates nor can modify policy. Its only communication path is the hostlink, which exposes request, checkpoint, state, store, MCP, A2A, and logging calls, and no call that changes policy or configuration. Inside the guest, process, filesystem, and kernel hardening keep the agent from tampering with the guest runtime or other agents' processes.

An authorization failure fails closed. When the policy decision point is unreachable, requests are denied.

See Security and Policy Enforcement.

P4: Independent record​

Policy decisions are recorded in the host's access log by the decision point, not by the agent, and the log records both allow and deny decisions. Syscall-level trace events, available in gvisor mode, are captured by the sandbox runtime and routed to host-side sinks.

The agent has no write path to either. See Tracing, Observability, and Security Monitoring.

Where confinement does not hold​

Be precise about which configurations are unconfined:

  • --sandbox=none runs the agent as an ordinary subprocess with no isolation. Mediation is bypassable, so this mode is unconfined. It exists for local development only.
  • Disabling hardening features (see Granular Hardening) can remove the isolation that P2 and P3 rest on. An explicit disabled setting is a decision to run with that protection off.
  • authz.type: allowall turns every decision into a grant. Isolation remains, but there is no meaningful policy, so the environment is unconfined. It is blocked when AGENTVISOR_ENV=production.
  • Authorization enrichment is fail-open by design (see Authorization Enrichment). Do not make a policy depend on enrichment succeeding without a coarse-grained rule behind it.

What confinement does not claim​

Stating the limits is part of the definition.

  • It is not confidentiality. An agent with an authorized channel to an external system can encode information in the timing, ordering, or content of requests the policy permits. Confinement does not prevent policy-compliant exfiltration. Bounding it takes content-level policy on the permitted channels, which is a separate control.
  • It does not make policy correct. Confinement guarantees that the stated policy is the one enforced and that its application is recorded. It says nothing about whether the policy authorizes the right things. A confined agent under a permissive policy is still a problem. What confinement gives you in that case is a single place where every effect is decided and recorded, so misbehavior can be watched for and stopped there.
  • It does not constrain reasoning. It governs effects. A confined agent can still be wrong, manipulated, or useless.
  • It governs outbound effects, not inbound content. Prompt injection arrives through an inbound channel that confinement does not address. The properties are designed to hold when an agent has already been injected, but nothing here prevents the injection itself.
  • Model calls are an outbound channel like any other. AgentVisor mediates them, but P2 does not bound what a permitted prompt carries.
  • The record is itself sensitive. A durable log of every decision is a confidentiality target and should be protected like the authority it describes.

Beyond confinement: accountability​

Confinement requires a record the agent cannot alter. It does not, by itself, establish accountability, which has two further requirements:

  • Integrity against the operator. The record is tamper-evident, so that insertion, deletion, and reordering are detectable by a verifier who does not trust the recording system. That requires an external anchor for the record.
  • Sufficient content. The record establishes, after the fact and from the record alone, what effect was attempted, on whose behalf, and under what authorization.

Every authorization request AgentVisor makes carries the principal, operation, resource, and context, including the RFC 8693 delegation chain when an AgentVisor ID is configured, so the content requirement has the inputs it needs.

Requires MPE Premium

Tamper-evidence comes from pairing AgentVisor with Manetu PolicyEngine Premium. Its Audit Integrity feature notarizes every authorization decision as it is recorded, so the access log can be checked for tampering instead of simply trusted. Verification bundles can be checked offline by an external party using keys obtained out of band, without trusting the deployment. Audit Integrity makes tampering detectable, not impossible.

With the embedded or community PolicyEngine, the record is still produced on the host and out of the agent's reach (P4), but it is not tamper-evident or externally anchored.

For the underlying decision and record model, see the PolicyEngine documentation on audit and access records.

Evaluating a deployment​

The useful question to ask of any agent environment, including your own, is not "is it sandboxed?" but "which of these properties does it satisfy, and who checked?"

Confinement claims are best made in a form that says so: which properties were tested, when, by whom, and with which probes. A passing result means no failure was found under those probes. It is not a guarantee that the property holds in general, because several properties are universal negatives (no credential anywhere, every channel mediated, no tamper path) that no finite set of probes can prove.