Blog · June 23, 2026

Environment and containment: where the agent runs, and what it can reach

Nine Security-domain containment controls (EC-01 to EC-09): sooner or later the agent will be hijacked, so bound the blast radius before it happens.

apeiris.ai·The Seams series · originally June 2026

The identity layer decides who the agent is and what it is allowed to do. This layer assumes that, sooner or later, something gets past all of that. The agent gets prompt-injected, or a tool returns something poisonous, or a model just does the wrong thing with confidence. Containment is the set of controls you build for that day. The goal is simple: keep the blast inside a small room.

There are nine controls here, more than any other layer, and a lot of them are about where the code runs and what it can physically touch. I will group them by the question each one answers.

Put the agent in a room sized to its job

Run it in a sandbox (EC-01). Put the agent in a sealed room sized to how risky its job is. An agent that can run code can break out of a weak sandbox and reach the host or other systems. The fix is to match the isolation tier to the threat. Process isolation is the floor. A userspace-kernel sandbox (gVisor is a common one, which puts a software layer between the agent and the real kernel) is stronger. A hypervisor-backed micro-VM (a lightweight throwaway virtual machine, the model Firecracker popularized) is the strongest of the three against host compromise, and it is what an agent running untrusted code should get; it sharply reduces direct exposure of the host kernel rather than removing it outright, since real isolation strength still depends on configuration, kernel exposure, and device access. Pair even a micro-VM with a localized seccomp profile, so a guest that does break out still meets a syscall wall at the host boundary rather than the full kernel surface. Record the tier in the deployment spec so you can actually check it later. To prove it, in an isolated and authorized test environment, run a known sandbox-escape (a benign breakout canary, or a controlled exploit) and confirm it reaches, at most, the guest, never the host.

This is one of the clearest places to see where the field is heading. Microsoft's Execution Containers, for example, describe a policy-driven sandbox that runs at the process and session level today, with micro-VM isolation on the roadmap. The direction across the industry is the same: climb the containment spectrum as the agents get more autonomous. Building to the stronger tier now is building for where this is going.

Give it only the files and tools it needs (EC-04). The agent gets the files and tools its task needs, and nothing else. An over-scoped agent can read bulk files, touch secrets, or run destructive operations far beyond its task. So mount only the files the task needs, keep home and secrets directories out of reach, expose only the required tools, and turn destructive tools off unless the task explicitly calls for them. Set per-agent limits at the operating-system level (seccomp profiles, which restrict which system calls a process can make). To prove it, instruct the agent to bulk-read sensitive files or call an out-of-scope destructive tool, and confirm the sandbox denies it.

Operational profile. Enforcement points, EC-01: the host kernel / hypervisor boundary (container → gVisor → micro-VM), hardened with a localized seccomp syscall profile. EC-04: the OS sandbox and the tool broker (mount allowlists, exposed-tool allowlists), set below the agent and outside its context.

Control what leaves

Filter outbound traffic (EC-02). Only let the agent phone the few places its job needs, and block the rest by default. This one matters more than it first looks, because a hijacked agent stealing data looks exactly like an ordinary encrypted web request at the network layer. Without destination controls, encrypted exfiltration is hard to tell apart from legitimate traffic. So route all of the agent's outbound traffic through a control point it cannot influence (a firewall or proxy outside its reach), default-deny everything, and allow only the destinations the task needs. Add DNS-layer rules to stop data being smuggled out through domain lookups. Log every connection at the network layer, not from the agent's own report of what it did. And test the failure class, not just the happy path. There is a documented bypass where a wildcard allowlist is defeated by a SOCKS5 null-byte in the hostname: the agent's traffic is routed through a SOCKS proxy (a generic relay that forwards connections), and a null character planted in the hostname makes the parser mis-read where the traffic is actually going, so it slips past the allowlist. In effect, one permissive rule plus a parsing quirk is enough to walk data straight out a door you believed was shut. Confirm your filter blocks that whole class, and that SOCKS and other non-web traffic is logged too, not just ordinary HTTP requests.

Keep secrets out of the prompt (EC-08). Never paste passwords or keys into the agent's text, because anything in context can be pulled back out. System-prompt leaks and credentials-in-context are real problems, not theoretical ones. Secret-scanning research has turned up more than 24,000 secrets sitting in MCP-related config files on public GitHub, over 2,000 of them still live. (MCP, the Model Context Protocol, is the common standard for connecting an agent to its tools.) So credentials should never go in prompts, system prompts, or config. Retrieve them at the moment of use, through a broker the model never sees, and keep the reasoning engine separate from the execution engine so a prompt-extraction attack turns up nothing. To prove it, scan prompts and config for embedded credentials and aim for zero, then try to extract the system prompt and confirm no secret comes out.

Operational profile. Enforcement points, EC-02: an egress proxy / firewall outside the agent's reach, default-deny, logging at the network layer rather than from the agent's own report. EC-08: a secrets broker / vault that resolves credentials at point-of-use, with the reasoning engine kept separate from the execution engine so the prompt never sees them.

Watch what it reads and remembers

Validate memory before it is trusted (EC-03). Don't let the agent quietly save a poisoned note that it will trust and act on later. Memory poisoning is one of the sneakier attacks, and Microsoft's own failure-mode taxonomy flags it as especially insidious, because a malicious instruction gets stored in one session, recalled in a later one, and executed, with nothing checking it on the way in. And this is not a theoretical worry. A 2026 audit of widely used agent frameworks (LangChain, AutoGPT, the OpenAI Agents SDK) found that a single poisoned memory write persisted across every storage backend they tested, because the frameworks did not validate what went in. In the paper's simulated government-benefits agent, that single poisoned write drove wrongful-denial rates to 88.9% for the applicants it targeted. Put another way, the poison spread as far as the memory reached, and the tested frameworks allowed it across every backend the researchers evaluated. So keep agent memory short-lived and session-scoped by default. Any write to long-term memory has to pass authentication and format validation before it can ever be recalled, and raw tool output never gets written verbatim. To prove it, plant an instruction designed to be stored, start a fresh session, and confirm it is not silently recalled and run.

Trust-rank what the agent retrieves (EC-07). Check and rank documents and web pages before the agent reads them as if they were true. Poisoning has moved into retrieval and RAG (retrieval-augmented generation, where the agent pulls in outside documents to inform its answer). A single malicious document, web page, or knowledge-base entry pulled into context can steer the whole agent, and noticing the injection is not the same as knowing whether the source can be trusted. So attach a source-risk classification and a provenance trail to retrieved content before it hits the prompt, make retrieval respect the requesting user's own permissions, and quarantine or clearly label low-trust sources. Treat the rank as a risk signal, not a truth score: a highly ranked source can still be compromised. To prove it, plant a poisoned document in a retrievable source and confirm it gets down-ranked or quarantined rather than acted on.

Operational profile. Enforcement points, EC-03: the memory write-path, an authentication and format gate that runs before anything persists to long-term memory. EC-07: the retrieval / RAG ingestion layer, where a source-risk classification and provenance trail are attached before content reaches the prompt.

Bound how far it can go

Cap spend and resource use (EC-05). Put a meter and a hard ceiling on how much the agent can spend or consume. A runaway agent can burn through hundreds of thousands of tokens or API calls in minutes, running up a serious bill while the system keeps right on going. OWASP tracks this kind of failure as unbounded consumption. I elevate denial-of-wallet into its own control on purpose: budgets and hard caps are established mechanisms, but the OWASP agentic list has no standalone category for it, so a faithful crosswalk would inherit that gap. I would rather name it. Give every agent and task a budget for tokens, cost, compute, and step count, make a breach halt the agent by default instead of warning and continuing, and enforce the budget at the gateway, outside the agent's own loop. To prove it, drive an agent into a loop and confirm it stops at the ceiling.

Operational profile. Enforcement points, EC-05: a budget / quota service at the gateway, outside the agent's own loop, that halts rather than warns on breach. EC-06: the orchestration runtime itself, holding deterministic loop caps, circuit breakers, and a forced exit condition on every loop.

Grant the least autonomy the task needs (EC-06). Stop an agent that keeps looping or grabs more autonomy than the job needs. An agent can be behaving "correctly" and still iterate without end, or act with more independence than its task warrants. This is where a useful new idea has entered the standards themselves: the 2026 OWASP agentic list adds least-agency, the minimum autonomy for the job, as a companion to the old principle of least-privilege. Put it into practice with deterministic caps on how many times an agent can loop, circuit breakers that trip when its tool-call rate spikes, and a forced exit condition on every loop. To prove it, trigger a looping condition and confirm the cap halts it.

Treat the workspace itself as untrusted

Don't let a workspace run its own hidden setup (EC-09). Do not let a repository you just opened run its own hidden setup; check its config and hooks before the agent trusts them. This one is sharp for coding agents, which are among the most widely deployed agents there are. Opening an untrusted repo can ship attacker-controlled configuration files or git hooks (scripts git runs automatically at certain moments) that the agent loads or executes, or it can nudge the agent into an auto-approve mode that skips the human gate entirely. So treat the workspace as untrusted by default: do not auto-load repo-supplied config or hooks, require explicit approval, and disable the dangerous "skip all permissions" modes outside throwaway sandboxes. To prove it, open a booby-trapped repo with a planted malicious config and confirm the agent neither executes it nor escalates its own permissions. This is another spot the published frameworks underweight, so part of the control is my own position on where the line should sit.

Operational profile. Enforcement point, EC-09: the workspace / config loader in the agent runtime, which must not auto-load repo-supplied config or hooks and must keep "skip all permissions" modes off outside throwaway sandboxes.

Where this layer is heading

Two trends are worth watching. The isolation tiers are climbing, from process to session to micro-VM, as vendors react to agents that run real code. And the poisoning surface keeps widening, from the prompt, to stored memory, to retrieved documents, which is why three separate controls here all come back to the same idea: nothing enters the agent's context as trusted until something has checked it.

The handoff

Containment decides where the agent runs and what it can reach, then hands off to runtime detection. The invariant that must survive: the detector can attribute a host action to a specific agent. You can isolate perfectly, but if the runtime layer cannot tell which agent spawned the shell or attempted the egress (because the identity from the first layer never reached the OS telemetry), you have containment without accountability. The evidence that must cross is the agent identity stamped on every process and connection. Who owns the failure when the sandbox holds but the alert says only "a process did something"? The concrete test: your egress filter blocks a canary exfiltration, good, but can the detector name the agent that tried it, or only the container?

If containment is the layer you find emptiest, the fastest wins are usually the boundary controls, sandbox tier and egress filtering, because they cap the damage of almost everything else going wrong. You can see just these nine Security-domain containment (EC) controls, with the standards, the tools that build them, and the validation steps, at apeiris.ai.

Sources

Apeiris Security →All 12 domains →