AI agent isolation is the practice of confining what an autonomous agent can execute, reach, and authenticate as, so that a compromised or mistaken agent cannot damage systems outside a defined boundary. Isolation is structural. It does not ask the model to behave; it removes the model''s ability to misbehave.

This guide describes the three boundaries that matter most — process, network, and credential — explains how each fails, and gives concrete tests for verifying that a boundary is real. It is part of our coverage of secure AI infrastructure.

Why behaviour controls are not enough

Prompt-level instructions, refusal training, and output filters are behavioural controls. They influence what a model tends to do. They are useful, and they are probabilistic. An agent that writes and runs code, browses untrusted pages, and calls internal tools will eventually encounter input that steers it somewhere its instructions did not anticipate.

Isolation answers a different question. Instead of asking whether the agent will try something harmful, it asks what happens if it does. A well-isolated agent that attempts to read a production database simply cannot: there is no route, no credential, and no process privilege that would allow it. That property holds regardless of how the attempt was provoked.

Boundary one: process isolation

Process isolation controls what code the agent can execute and what that code can see on the host.

The weakest common pattern is running agent-generated code in the same process as the application, with a language-level sandbox. This is fragile; language sandboxes are routinely escaped. Container isolation is the practical baseline: a dedicated container per session, with a read-only root filesystem, a non-root user, no host mounts beyond a scratch directory, dropped Linux capabilities, a seccomp profile restricting system calls, and hard CPU and memory limits. Stronger still is a microVM or a kernel-isolating runtime, which gives each session its own kernel rather than sharing the host''s.

Two properties matter as much as the technology. Sessions must be ephemeral: a fresh environment per task, destroyed afterwards, so nothing an agent writes persists into another user''s run. And environments must be reproducible from an image, not mutated in place, so you can state exactly what was running when an incident occurred.

Process isolation fails in recognisable ways: shared writable volumes between sessions, a container that runs as root, a socket for the container runtime mounted inside the sandbox, or a long-lived environment reused across tenants. Each of these converts isolation into the appearance of isolation.

Boundary two: network isolation

Network isolation controls what the agent can reach. It is the boundary organisations most often leave open, because agents are useful precisely when they can fetch things.

Default-deny egress is the correct starting position. From there, allow only the destinations a task requires, by hostname, through an explicit proxy that logs every request. Block access to link-local metadata endpoints, private address ranges, and internal service discovery unless a task genuinely needs them. Terminate DNS inside the boundary so an agent cannot resolve arbitrary names, and treat DNS queries themselves as an exfiltration channel worth logging.

Ingress deserves equal attention. An agent environment should not be addressable from outside except through the gateway that created it, and inter-agent traffic in a multi-agent system should traverse a mediated channel rather than a flat network, so that one compromised worker cannot talk directly to every other.

Network isolation fails when egress is open "temporarily" for debugging, when an allow-list is maintained by IP address and a cloud provider reassigns it, when the proxy is bypassed by a library using its own resolver, or when logging records that a request happened but not what was sent.

Boundary three: credential isolation

Credential isolation controls who the agent is. This is the boundary with the widest blast radius when it breaks, because a stolen credential travels outside your infrastructure.

The rules are simple and frequently broken. An agent gets its own machine identity, never a human user''s. Secrets are never placed in the agent''s environment, prompt, or filesystem; the agent calls a mediated tool and the gateway attaches the credential on the far side of the boundary. Tokens are short-lived, scoped to a single task, and bound to the session that requested them. Write access is granted per operation and, for consequential actions, gated behind a human approval step.

The practical test is blunt: if an attacker obtained everything inside the sandbox — memory, disk, environment, and logs — what could they authenticate as? If the answer includes anything beyond the current task, credential isolation has not been achieved.

How the three boundaries interact

The boundaries are not independent, and attacks move between them. Untrusted content read from a web page is an input problem that becomes a network problem when the agent is steered into fetching an attacker-controlled URL, and a credential problem if that request carries a token. A code-execution escape is a process problem that immediately becomes a network problem, because the escaped process inherits whatever egress the host allows.

Designing for this means assuming each boundary will eventually be tested and ensuring no single failure is sufficient. Isolation, mediated tool access, and least-privilege credentials are layers, and the value is in their combination.

Verifying isolation instead of assuming it

Claims are cheap; tests are evidence. Run these against any agent platform, your own or a vendor''s.

Attempt an outbound connection to an address that is not on the allow-list and confirm it is refused and logged. Attempt to read the cloud metadata endpoint from inside the sandbox. Write a file in one session, start a new session, and confirm it is gone. Inspect the sandbox environment for anything resembling a long-lived key. Request a credential and check its expiry and scope. Trigger a consequential tool call and confirm the approval step is enforced rather than advisory. Finally, ask for the audit trail of everything you just did, and confirm it is complete enough to reconstruct the sequence.

If a platform cannot survive those tests, its isolation is a diagram rather than a control.

Where this sits in a production architecture

In a complete design, a gateway authenticates the caller and issues a scoped session; an isolated ephemeral sandbox executes the work; a default-deny egress proxy mediates every outbound request; a credential broker holds the secrets; and an observability layer retains the trace, the approvals, and the decisions. Each function is separable, which is why each has become its own product category.

Those categories are the reason our infrastructure portfolio exists. IsolatedSandboxAI.com and RuntimeSecurityAI.com name two of them precisely. For the input-side controls that complement isolation, read our guide to prompt injection defence.