Agent Sandboxing: How Infrastructure Teams Isolate What Agent Code Is Allowed to Touch

Sit in on a platform team's agent design review and notice which question comes last. It is rarely model selection and it is rarely prompt structure — it is someone asking, near the end of the hour, what the agent is actually permitted to run.

That is the sandboxing question, and most teams reach it after the agent is already writing files, calling an internal API, and executing code it generated four seconds earlier. The execution environment never got scoped, because when the first agent shipped it only read from a vector index.

Retrieval agents did not need an isolation story. Agents that write do, and the distance between those two postures is where a great many enterprise agent programs are sitting right now.

What Agent Sandboxing Actually Covers

The word "sandbox" gets used loosely enough that two engineers in the same review can mean entirely different things by it. One means a container image; the other means a separate AWS account with its own VPC and no peering back to production.

In practice, a working agent sandbox is a stack of boundaries, each of which fails in its own way and each of which needs a named owner. Those boundaries include but are not limited to:

• Execution boundary. The kernel or hypervisor line between the agent's process and everything else on the host. This is what decides whether generated code making an unexpected syscall gets a permission error or a shell.
• Filesystem boundary. The paths the agent can read and write, and whether that volume survives the run. An ephemeral scratch mount destroyed on exit removes an entire class of cross-run contamination.
• Network boundary. The egress allowlist, expressed at DNS, SNI, or IP level, plus the VPC endpoints that let the agent reach S3 or Bedrock without touching the public internet. Most teams get ingress right and leave egress wide open.
• Credential boundary. Which IAM role the run assumes, how long that session lives, and whether the credential is reachable from inside the process running generated code at all.
• Data boundary. Which tables, buckets, prefixes, and rows the assumed role can see once it is authenticated. Isolation that stops at the network and then hands the agent a warehouse-wide Snowflake role is not isolation.

These are not alternatives to choose between. Each one catches what the layer above it missed, and a program that has implemented only the container layer has covered roughly a fifth of the problem.

Why Retrieval-Only Agents Never Needed This

The first generation of production agents did one thing: embed a question, search a Pinecone or OpenSearch index, and hand the model some context. The failure modes were retrieval-quality problems, including the ones covered in AI retrieval blind spots.

Nothing in that loop executes. The agent has no write path, no shell, and no reason to reach any host other than the index and the model endpoint.

Then the tool registry grew verbs. Once an agent can open a ServiceNow ticket, patch a HubSpot record, run a statement against Snowflake, or write a file that a downstream Lambda will read, the runtime has become an execution environment and the threat model changed underneath it.

Keep in mind that the boundary is really set on the registry, not on the host. A tool signature accepting a free-form shell string or a raw SQL string has already handed the model the key, which makes this an agent tool design problem before it is an infrastructure problem.

Where The Container Boundary Stops Being Enough

Most teams start with a container, because they already run containers. An ECS task or a Kubernetes pod with a read-only root filesystem, a dropped capability set, a non-root user, and no host network is a genuine improvement over running tool code inside the orchestrator process.

That said, it is still a shared kernel. For agent code you wrote and reviewed, that is an acceptable trade; for code the model wrote thirty seconds ago that no human has read, the calculus is different.

Here is how the common isolation tiers compare on what they actually stop:

Isolation tier	What it stops	What it leaves open	Typical fit
Same process (exec inside the orchestrator)	Nothing beyond language-level checks	Full access to orchestrator memory, environment variables, and credentials	Prototypes only
Hardened container (ECS task, Kubernetes pod)	Filesystem sprawl, root actions, host process visibility	Shared-kernel escalation, plus anything the task role can already reach	Reviewed tool code
User-space kernel (gVisor)	Most direct syscall paths to the host kernel	Network reach and data scope, which it does not address at all	Untrusted or generated code
microVM (Firecracker, Fargate)	Host compromise, via hardware-level separation per run	Egress destinations and credential scope, still entirely yours	Multi-tenant or generated code
Separate account and VPC	Any lateral path into production data stores	Nothing at the infrastructure layer; cost and operational overhead rise	Regulated or PHI-adjacent workloads

The rule most teams land on is to choose a tier per workload rather than per platform: reviewed tool code runs in a container, model-generated code runs in a microVM or a gVisor sandbox, and anything touching regulated data runs in an account with no route to production. Accordingly, the expensive isolation ends up only where it earns its keep.

Egress Allowlists Are Where Programs Stall

Ingress rules are straightforward, because someone already owns them. Egress is the one that stalls, because writing the allowlist requires knowing every hostname every tool touches, and nobody has that list on day one.

The shape that works is a forward proxy — Squid, Envoy, or a managed network firewall — that terminates or inspects SNI, paired with interface VPC endpoints for the AWS services the agent legitimately calls. Bedrock, S3, Secrets Manager, SQS, and DynamoDB all have endpoints that keep that traffic off the public internet entirely.

However, two entries reopen the boundary almost every time. A public package registry means generated code can pull an arbitrary payload at runtime; a general-purpose HTTP tool or a broadly allowlisted SaaS domain gives anyone with prompt-injection access a working relay.

Run the allowlist in log-only mode first and let it collect real destinations for a week or two before you flip it to deny. The list you derive from observed traffic is the one that survives contact with the second team that onboards, and the Bedrock agent patterns most teams start from assume exactly that kind of endpoint-first networking.

Ephemeral Credentials And The Blast Radius Question

Isolation that stops at the network is only half the control. The other half is what the agent is authenticated as once it reaches somewhere it was allowed to go.

The pattern that holds up is a role per workflow, assumed per run, with session tags carrying the run ID and the requesting principal, and a session duration measured in minutes rather than hours. That produces a credential which expires before most exfiltration attempts finish, plus an audit record tying every downstream API call back to one specific run.

What's more, that credential should stay out of the process running generated code. A broker sidecar that holds the STS session and exposes only signed, parameter-checked operations means a compromised inner process gets the operation and never the key.

The identity design underneath all of this is its own discipline, covered in agent identity and access management. At the sandbox layer, the rule is narrower: no long-lived access key is ever baked into an image, mounted as an environment variable, or shared between two runs.

Where Sandbox Escape Actually Happens

Kernel exploits get the conference talks. In enterprise agent workflows, the escapes that actually happen are architectural and, frankly, boring.

Five paths account for most of what turns up when reviewing an existing deployment:

• The over-broad tool signature. A tool accepting a shell command, a raw SQL string, or an arbitrary URL is not constrained by any container, because the model has been invited to specify the action rather than the parameters.
• The shared credential. One IAM role reused across every agent on the platform makes the isolation boundary the platform itself, so a bad instruction in the low-risk summarization agent reaches the same Postgres cluster as the billing agent.
• The trusted artifact path. Stage one writes to an S3 prefix and stage two reads and executes what it finds there without revalidating. The sandbox held and the handoff did not, which is why agent handoff patterns belong in the same review.
• The allowlisted relay. Any allowlisted domain that can forward arbitrary content — a pastebin, a webhook service, a package registry, a third-party model API — turns a technically correct egress rule into an exfiltration channel.
• The injected instruction. Content pulled from a Zendesk ticket, an inbound email, or a scraped page carries instructions the model then follows using a tool it was legitimately granted. Nothing was escaped; the granted authority was simply pointed somewhere new.

Note that four of those five are design decisions rather than runtime failures. In each case the sandbox is doing exactly what it was built to do, and the boundary was drawn in the wrong place upstream of it.

How Do You Know Your Sandbox Is Holding?

A sandbox with no telemetry is an assumption. The signals worth instrumenting are the denials rather than the successes.

Egress denies per run, credential-scope violations, filesystem writes attempted outside the scratch mount, and blocked syscalls are all leading indicators, and they belong on the same dashboard as your latency and cost metrics. Feeding them through the pipeline described in agent observability keeps that in one pane instead of two.

Then run a standing escape suite. A small set of adversarial cases — write outside the scoped path, resolve an unlisted hostname, attempt to assume a neighboring run's role, request a row belonging to another tenant — executed on every release, with every case expected to produce a deny log rather than a result.

Treat a passing escape suite as a release gate, the same way you treat evaluation scores, and wire the deny signal into alerting so the first real attempt does not sit unread in CloudTrail for a week. The pairing with agent incident response matters here, because a denial nobody is paged for is a metric and not a control.

What Isolation Actually Costs

The honest answer is that it costs some latency and a line item, and both are smaller than teams expect. A Firecracker microVM boots in roughly 125 milliseconds, which is noise against a multi-second agent turn, and a warm pool absorbs most of what remains.

Networking is where the line item shows up. In us-east-1, an interface VPC endpoint runs about $0.01 per hour per availability zone plus data processing, and a NAT gateway adds roughly $0.045 per hour plus about $0.045 per gigabyte — trivial against one workflow, meaningful across a fleet, and worth modeling before the fleet exists.

The larger cost is engineering time on the allowlist and the role matrix, which is front-loaded and then largely static. Budget it the way you budget the rest of the platform, using the framing in AI agent cost governance.

A Rollout Sequence That Does Not Stall

The programs that finish this work do it in order rather than all at once. The sequence that tends to hold:

• Inventory the verbs first. List every tool in the registry and mark each one read, write, or execute. The execute tools set your isolation tier, and in most deployments they number fewer than five.
• Split the credential before the container. A role per workflow with a short session buys more blast-radius reduction in a week than a hypervisor migration buys in a quarter.
• Run egress in log-only mode. Two weeks of observed destinations produces an allowlist that will not page you on the first Monday after enforcement.
• Isolate generated code on its own. Move only the code-execution tool to a microVM or gVisor sandbox instead of migrating the whole platform to a new runtime.
• Gate what you cannot bound. Anything that resists a technical boundary gets an agent approval gate, which remains a legitimate long-term answer for low-frequency, high-consequence actions.

Each of those ships on its own and reduces real exposure without waiting on the next one. That is what keeps the work from turning into a six-month platform project that never quite starts.

Common Questions About Agent Sandboxing

These come up in nearly every scoping conversation on this topic:

Is a Docker container enough to sandbox an AI agent?

For known tool code with no generated execution, a hardened ECS task or Kubernetes pod is usually enough. For model-generated code, add a microVM or gVisor layer, since a shared kernel is one privilege escalation away from the host.

What belongs on an agent's egress allowlist?

Only the destinations a tool actually calls: your interface VPC endpoints, the named SaaS API hostnames, and an internal package mirror. Public registries and general-purpose HTTP tools are the entries that quietly reopen the boundary.

How long should agent credentials live?

Scope an STS role per run and keep the session under fifteen minutes wherever the workload allows it. Long-lived access keys baked into an image are the most common way a sandboxed agent stops being sandboxed.

Does sandboxing solve prompt injection?

No. Injection uses authority the agent was legitimately granted, so sandboxing limits the damage rather than preventing the action. Narrow tool signatures, a tight egress allowlist, and approval gates on high-consequence verbs are what actually reduce it.

How do you test an agent sandbox before production?

Run a standing escape suite in shadow mode: writes outside the scoped path, calls to unlisted hosts, and use of a neighboring run's credential. Every attempt should produce a deny log rather than a success, on every release.

Scoping This For Your Own Workflow

If you are moving an agent from retrieval into write operations and want a second set of eyes on the execution environment before it ships, the team at iSimplifyMe builds and operates production agent systems across CRM, ticketing, and data warehouse environments every week. Reach out for a working session — we will map your tool registry against isolation tiers, draft the egress allowlist and role matrix, and hand back a rollout sequence you can start on Monday.

The adjacent controls are covered elsewhere in this cluster, including agent audit trails and the release gating that decides when a new boundary goes live. Both sit alongside the rest of the AI agent operations practice.