# AgentFort Isolation: an AI agent sandbox that assumes the code is hostile

> An AI agent sandbox runs the code an agent executes inside a boundary that limits what that code can reach. AgentFort Isolation assumes the code is already the attacker's. Each task gets its own sandbox built from Linux kernel features, with no network and no credentials, and its only way out is a broker that inspects requests, adds credentials and holds anything leaving the company.

Source: https://agentfort.net/platform/isolation · Updated 2026-10-28 · AgentFort

## What an AI agent sandbox has to assume

Agents run code. A poisoned document, a bad dependency, or a tool that does what a file told it to, and that code belongs to an attacker. It then has the agent's reach: the network, credentials on disk, the host's files, other tasks and the machine itself. OWASP lists this risk as ASI05 Unexpected Code Execution (RCE) in its Top 10 for Agentic Applications, published in December 2025.

An AI agent sandbox is an isolated environment that limits what an agent's code can reach. AgentFort Isolation starts from the worst case. It assumes the code inside the sandbox is already the attacker's, and contains the blast radius. The question it answers for a security team: what happens when an agent is manipulated? The vendor-neutral guide is [AI agent sandboxing and isolation](/agent-security/sandboxing).

## A sandbox per task, built from kernel features

Every task runs in its own sandbox, built from Linux kernel features, with no virtual machine and no systemd. Each layer closes a different path.

| Layer | What it does |
|---|---|
| Empty network namespace | No network at all, only a downed loopback |
| Read-only root | The root filesystem can't be written |
| Landlock ruleset | Keeps the task to its own workspace |
| Unprivileged user | Runs with no capabilities |
| seccomp filter | Refuses mounting, kernel modules, BPF and new user namespaces |
| cgroup | Caps memory and processes |
| Broker socket | The only way out; credentials are added outside the sandbox |

Network namespaces isolate a process's network interfaces, routing and ports. Landlock lets a process restrict its own access to files. Seccomp filters the system calls a process may make. AgentFort Isolation layers all of them.

## One way out: the broker

The only way out of the sandbox is one socket to a broker. The broker adds credentials the sandbox never sees and holds outbound actions for review. In a customer evaluation, verify the complete inspection path with [AgentFort Data Protection](/platform/data-protection) and the selected business services. The person the agent acts for can see a held message but can never approve it. A security reviewer decides.

## The demo: a takeover at Northwind

The recorded run took place at Northwind, a simulated company. Support Triage started in a fresh sandbox, drafted a reply through the broker and read a document. Then it read a partner document that hid an instruction, and the attacker's code took over.

- It tried to open a socket to the outside. There was no network to reach.
- It searched the disk and its environment for credentials. There were none.
- It tried to mount the host, load a BPF program and a kernel module, and create a user namespace. The kernel refused every one.
- It forked until the machine should have fallen over. The cgroup stopped it at 127 processes.
- It tried the one way out. Emailing the customer list outside was held for review, and a message carrying a secret was blocked.

Priya, the person the agent acts for, could see the held message but not approve it. Jo, a security reviewer, denied it. What reached Northwind's services was the draft and the 2 reads, each with a credential the broker added outside the sandbox. Remote code execution happened inside the sandbox. Its effect stayed there.

## Receipts: the Visibility control

Each receipt in the demo recorded where the request was going and why it stopped, never the content, and the chain can be verified. This is AgentFort's fifth control, Visibility: a receipt for every request showing the identity, owner grant, policy and outcome, and a live inventory of agents, owners and connected business systems. Allowed and denied activity can be filtered, so a security team can see what each agent did and why it was allowed. For background, read our guide to [audit trails for AI agents](/agent-security/audit).

## What Isolation doesn't do, and what you still need

Isolation limits what compromised code can reach. It doesn't prevent the compromise itself: in the demo, a partner document still took over the code inside the sandbox. Catching hidden instructions before an agent reads a document is Data Protection's job. Because there is no virtual machine, the sandbox relies on the host's Linux kernel to enforce every layer. And Isolation doesn't make the agent's permitted work correct; [AgentFort Access](/platform/access) limits what that work may be.

- Keep the Linux kernel patched on the hosts that run sandboxes.
- Name the security reviewers who decide held outbound messages.
- Set the Data Protection policy the broker enforces.
- Review receipts for held and blocked requests.

## How Isolation connects to the other controls

[AgentFort Discover](/platform/discover) and [AgentFort Identity](/platform/identity) establish which agent is running and who owns it. Access limits what its calls may do. Data Protection inspects everything the broker passes. Isolation assumes any of those might be bypassed by code the attacker controls, and keeps the damage inside the sandbox. The [AI agent security guide](/agent-security/) shows how the controls fit together.

## Assume the agent is compromised

[Request a demo](/demo) to see Isolation contain a takeover like the one above, or [apply as a design partner](/design-partners) to run your code-executing agents in AgentFort sandboxes in your own environment.

## Frequently asked questions

### What is the difference between an AI agent sandbox and a virtual machine?

A virtual machine runs its own guest kernel on virtualized hardware. A kernel-feature sandbox runs on the host's kernel and uses namespaces, Landlock, seccomp and cgroups to limit what a process can see and do. AgentFort Isolation takes the second approach, with no virtual machine and no systemd, and assumes the code inside is already hostile. Which approach fits depends on your threat model.

### How do I contain a compromised AI agent?

Assume the code is already hostile and take away what it would use: the network, credentials in its environment, files outside its workspace, risky system calls, and unlimited memory and processes. Then give it one inspected way out. Hold anything leaving the company for a reviewer who is not the person the agent acts for, and keep a receipt of every request.

### How do I know AgentFort receipts haven't been edited?

Receipts are chained, so a missing or edited entry shows when the chain is verified. They are kept on the customer's side and reconciled to the AgentFort console, and gaps in delivery are reported. Each receipt records the identity, the owner's grant, the policy and the outcome; for a held or blocked request it records where the request was going and why it stopped, never the content.

## Sources

- [OWASP Top 10 for Agentic Applications for 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/)
- [Landlock: unprivileged access control (Linux kernel documentation)](https://docs.kernel.org/userspace-api/landlock.html)
- [Seccomp BPF (Linux kernel documentation)](https://docs.kernel.org/userspace-api/seccomp_filter.html)
- [network_namespaces(7), Linux manual page](https://man7.org/linux/man-pages/man7/network_namespaces.7.html)