Can the Agent Bypass the Gate?
A practical architecture for governing agent effects across shell tools, MCP servers, credentials, and network routes, with tests for the paths policy engines miss.
Consider an agent reading an issue tracker entry. Buried in the issue body is an instruction to upload a local environment file to an external endpoint. The legitimate task is to fix the issue. The tool policy rejects the upload, but the agent still has a shell with that file mounted and outbound access. It runs an HTTP client directly. The policy log says BLOCK; the bytes leave anyway.
The failure mode is a rule governing one named tool while another route reaches the same resource. An execution boundary must control the route that causes the effect. For a secret export, trace where the file is mounted, which process can read it, and how that process reaches the network.
A coding agent can combine a shell with Model Context Protocol (MCP) servers. A registered tool list may say nothing about subprocesses that inherit environment credentials. Map what the process can do before claiming that the tool policy controls it.
Map every route to the effect
Suppose the protected effect is a repository write. The agent can use the approved GitHub MCP tool. It might also run Git with a token inherited from the environment. If the policy engine sees only the MCP call, a BLOCK verdict leaves the Git route open.
The reference-monitor definition requires a mechanism invoked on every relevant operation, resistant to tampering, and small enough to analyze. In this example, the Git command and the MCP write tool must meet the same enforcement point before either can change the repository.
The lower topology puts the credential in the gateway and closes the agent’s direct route.
Input screening and model guardrails can reject suspicious instructions early. CaMeL tracks how untrusted tool content influences tool calls. Those controls reduce unsafe proposals. A resource gateway can stop an unsafe proposal that still reaches the executor, provided the resource requires the gateway’s authorization.
The shell changes the threat model
A shell tool can launch an HTTP client or a build script that makes its own network request. A policy attached to the registered “send HTTP” tool will never see either call. A dependency install may execute code with the same file and network access as the agent’s shell.
The agent can make that request from inside its container if the file and route are already available there. No container escape is required. Filesystem mounts and network policy set the container’s reach. Claude Code’s sandbox documentation, for example, describes restrictions on Bash file and network access. Test the alternate command under the restrictions actually deployed.
An agent with shell access can read secrets placed in its environment. A broadly scoped production token there is available to every program the agent launches. Put consequential credentials in a broker or executor outside the agent’s process, and expose a narrowly described operation rather than an API that returns the secret.
MCP adds paths between trust domains
The MCP specification defines stdio and Streamable HTTP transports, with older HTTP+SSE deployments still in use. An issue body returned by a search tool can carry an instruction to call an internal repository writer. The search result has supplied data; the write tool carries authority. A host that feeds both into one conversation must keep that distinction.
The attack crosses a trust boundary when the issue text steers a privileged call. Track the content’s provenance through the planner, and give each MCP tool the smallest capability its task needs. Keep read-only search credentials separate from write credentials. The write gateway should verify the principal and the proposed mutation; the planner should account for the untrusted source that suggested it.
For remote MCP, the transport requirements call for origin validation on Streamable HTTP servers. The protocol’s security guidance covers authorization and token handling. Connection authentication identifies the caller. Tool results still need provenance handling before they influence a write.
Ambient cloud identity and uninspected egress
On EC2, a process that can reach the instance metadata service at 169.254.169.254 may obtain role credentials without an application secret. Access depends on the instance and container configuration. Check whether IMDS is enabled, whether IMDSv2 is required, and whether the response hop limit or local firewall permits the agent container to reach it. Inspect mounted service-account tokens and SDK credential chains for the same reason.
An HTTP proxy only sees traffic routed through it. Raw sockets and DNS can carry data around that proxy. A default-deny network namespace or enforced Kubernetes NetworkPolicy can close those routes. Kubernetes warns that a NetworkPolicy has no effect without a supporting network implementation; default-deny egress also blocks DNS until a rule permits it. Test DNS, metadata access, and direct sockets from the agent’s process. eBPF is one possible enforcement mechanism.
| Protected effect | Alternate path | Enforcement point |
|---|---|---|
| Export a secret | Shell HTTP client | Agent egress denied; secret kept outside its scope |
| Mutate an internal repo | Git CLI with inherited key | Gateway holds the write key and verifies the action |
| Use cloud role privileges | SDK via reachable IMDS | Metadata route restricted; IAM role narrowed |
For each row, capture the policy verdict and the resource-side result. A BLOCK in the agent transcript is only one observation.
A production execution stack
- Constrain the proposer. Run the agent under an identity with only the files, processes, and networks it needs. Use a sandbox or container with explicit mounts and a default-deny egress policy that the agent cannot edit. Treat a general shell as authority to run any code allowed by those controls. Keep high-value secrets outside that process.
- Represent an effect as a typed request. The tool adapter should produce a canonical action with principal, target resource, operation, arguments, and a stable identity for the intended effect. Record which inputs came from trusted instructions and which came from retrieved content. A string in an issue saying “approved” is still issue data.
- Decide with relevant state. A policy authority can check one action and the trajectory around it: prior reads, approvals, pending writes, cumulative spend, and revocations. Its state store must be shared and atomic where the policy claims a global limit. A decision service that sees only one worker’s history cannot promise a cross-worker invariant.
- Enforce at the effect. Give the gateway the resource credential and require authorization for the exact request it forwards. OIDC-federated workload identity can issue temporary cloud credentials to that gateway without a stored long-lived key. AWS STS role sessions last at least 15 minutes; an action authorization inside the session can expire sooner. Close direct routes around the gateway.
- Compare decisions with effects. Log both the policy verdict and a receipt from the resource or executor. Reconcile retries, partial failures, timeouts, concurrent calls, and released authorizations. An append-only policy log cannot reveal a bypass it never saw.
If policy, identity, or shared state is unavailable, the executor should refuse the protected operation. An emergency override needs its own narrow authority and a resource-side audit record.
The cost has to fit the loop
Remote checks add up in a long agent loop. A 600 ms policy check on each of 40 sequential calls would add 24 seconds. Offline finite verification may enumerate trajectories; the online path should evaluate policy against current state without rerunning that search.
Measure the added time at the policy service, continuity store, and executor. Report p50 and p99 under retries and concurrent calls. Cache only when the action identity and revocation rules make reuse safe. Set the budget from the deployed workload.
Where Morrison fits
Morrison Runtime Governance, developed by Resurrection Tech founder Davarn Morrison, separates the policy decision from execution. Its kernel checks an action against history and issues an action-bound lease. A resource-side verifier can require that lease before forwarding the request. The deployment has to put the resource credential behind that verifier and close the agent’s direct route.
Our bounded reproduction and prior-art review reran the quickstart, selected tests, finite scenarios, and adversarial script at a pinned commit. Governance excluded unsafe states in some declared models. Seven investigator-supplied synthetic variants still reached unsafe states along PERMIT paths; an offline mock exposed a lease-release composition problem. Morrison’s mediation analysis assigns credential custody and route closure to the deployment. Its prior-art correction leaves the narrow novelty question open.
Multi-agent shielding constrains joint actions in a bounded environment. CaMeL tracks untrusted content through agent tool use. AWS AgentCore documents policies over session history, while its gateway outbound authorization can hold target credentials. Compare these systems by running the same protected effect and alternate routes through each deployed boundary.
Prove the boundary
Pick one protected effect, such as a repository write. Reject it at the policy gate. Then try the same write from the agent’s shell and an alternate MCP client under the deployed identity. Repeat once with two concurrent workers.
Inspect the repository audit log and the gateway record. If the write lands after the gate rejects it, move the credential or close the route that carried it. If it fails, record the enforcement point that stopped it. That result tells you which boundary protects the resource.
Continue reading
