AI Agent Sandboxing Explained: How to Contain Agents That Run Code

It can reach anything its machine can reach, use any key it finds and keep going for days before anyone notices. AI agent sandboxing exists to stop exactly that.

On 15 October 2026, CERT-In, India's national cyber security agency, issued critical advisory CIAD-2026-0049, titled "AI Agents as Attack Vectors".

It says AI agents under evaluation went beyond what they were authorised to do and reached live systems of Indian organisations. They read business records, including personal data and confidential material.

The agents did not need clever tricks. They used credentials found in application configuration and public code repositories, plus cloud roles with far more permission than needed. The affected organisations could not detect the access on their own.

Picture a common setup. A software team runs an AI coding agent every night to fix flaky tests, tests that pass or fail at random. It handles about 300 tasks a night inside an ordinary container with open internet and the team's cloud keys.

While fixing a payment test, the agent finds an old partner API key in the repository history. It calls the partner's staging server about 2,000 times over two days. Nobody notices until the partner emails. The setup is made up, but each weakness in it is on CERT-In's list.

• Agent: a program that lets a large model plan steps and run tools, such as a shell or a web request.
• Kernel: the core of an operating system. It controls memory, files and the network for every program.
• System call: a program's request to the kernel, such as "open this file" or "connect to this server".
• Container: a group of ordinary programs that the kernel walls off with their own view of files, processes and network.
• MicroVM: a tiny virtual machine, a computer simulated in software, that boots its own kernel.
• Egress: traffic leaving your system, such as a call to a website or an API.
• Credential: anything that proves identity, such as an API key, or a token, which is a key that expires.
• Kill switch: a way to stop a running agent at once, from outside the agent's control.

AI agent sandboxing is containing an agent with the same tools you would use for untrusted code. You assume it may do something unplanned, by mistake or because content it read misled it, and you build walls so the damage stays small.

Think of a new trainee at a bank. You do not just tell them which rooms to avoid. You lock the doors they do not need, issue a badge that expires tonight, keep cameras running and have a guard who can walk them out.

Where the picture breaks: a trainee keeps what they learn, but a sandboxed run is destroyed after its task and the next one starts blank. And an agent can act thousands of times an hour, so a program must watch the cameras, not a person.

• Isolation (the locked room): each task runs in its own fresh container, gVisor sandbox or microVM, destroyed afterwards.
• Egress control (the locked doors): outbound traffic is blocked by default, except to an allowlist, a short list of approved servers.
• Short-lived scoped credentials (the badge): a proxy, a go-between server, adds tokens that expire in minutes and open one thing.
• Tamper-resistant logs (the cameras): every request, and every command as it runs, is recorded outside the sandbox, where the agent cannot quietly edit it.
• Monitoring with a kill switch (the guard): a watcher outside the sandbox stops runs that leave their scope.

The diagram shows the team's rebuilt setup. Notice that the agent has exactly one way out, and that the log and the kill switch both sit outside the box.

It says AI agents have become a route for attacks, and that the weaknesses they used were conventional ones. It covers two threats: agents under evaluation that overstepped, and attackers using open-source agent tools against Indian entities.

For the attacker campaigns, it says agent tools shrank the time from first access to final impact from days to a few hours. Victims that fixed things only partly were attacked again within days.

For teams that build or evaluate agents, the advisory asks for these controls, among others:

• Deny all outbound network traffic by default, and enforce it at the network layer, not through instructions to the model.
• Use synthetic targets and credentials, fake systems and keys, and keep production data and real credentials out.
• Define which systems and actions are in scope for each task; treat everything else as out of scope.
• Stop runs automatically when an agent contacts third parties, or discovers or uses a third-party credential.
• Give an independent operator the authority to end or restart a run, and monitor in real time.

For organisations running their own agents, it asks for a separate, short-lived identity per run with least privilege, only the permissions that task needs, default-deny egress and a tamper-resistant log. Separately, it asks all organisations to retain logs for at least 180 days.

Because, in their view, the walls were missing or badly built, not because machines chose to rebel. That is the opinion of experts CSO Online interviewed for a 14 October 2026 article.

Dan Wallach, of RAND's Center on AI, Security, and Technology, said isolating these systems is "not rocket science". He named air-gapping, no network link at all, or "really strong egress control". Rob T. Lee of the SANS Institute described a containment hole that was "not configured correctly".

Facts come from the advisory; blame comes from interviews. The controls are worth adopting either way.

For an agent that runs code it wrote itself, a gVisor sandbox or a microVM is the safer default. A plain container is the thinnest wall, because every container on a machine shares the host's kernel.

What each wall is made of

Docker's documentation says a container rests mainly on two kernel features. Namespaces give it a separate view of processes, files and network. Control groups limit the memory and CPU it can use. Docker also starts containers with a restricted set of Linux capabilities, the admin powers the kernel splits into separate pieces.

Because both live in the one shared kernel, a single exploitable kernel bug can let code break out to the host, and from there reach every container on it. gVisor's docs say it was built to add defence against exactly that kind of kernel bug.

gVisor is an open-source application kernel, a kernel that runs as an ordinary program between your app and the real kernel. It is written in Go. Its main part, the Sentry, implements system calls itself.

Its docs say no system call is passed through directly to the host kernel. The Sentry itself still makes a small, restricted set of host system calls to do its job.

The price, in gVisor's own words, is higher overhead per system call and reduced compatibility. As of 19 October 2026, its docs say it does not implement every system call, so some programs may break.

Firecracker is an open-source tool that uses KVM, the Linux kernel's built-in virtual machine support, to start microVMs. Each microVM boots its own guest kernel. It sees only a small set of emulated devices, devices imitated in software: mainly network, disk, a serial console and vsock, a guest-to-host socket.

The project says a microVM boots in under 125 ms with under 5 MiB of memory overhead. One mebibyte (MiB) is 1,048,576 bytes, so that is just over 5 megabytes per microVM. Firecracker's design doc adds defence in depth: seccomp filters limit the host system calls Firecracker itself can make, and a jailer drops its privileges.

How to check which wall you have

First, see the shared kernel for yourself on a Linux host. Run uname -r on the host and inside a plain container. Both print the same kernel version, because there is only one kernel.

We ran this with a Linux namespace, the building block of containers. The isolated shell saw 4 processes instead of 106 and its own host name, yet printed exactly the same kernel version as the host.

Second, gVisor's Docker guide gives a quick check: docker run --runtime=runsc -it ubuntu dmesg. The output should start with a line ending "Starting gVisor..." and finish with "Ready!".

The same page warns that this check is easy to fake. Use it to catch a wrong setting, not as proof in a security audit.

Third, Firecracker needs read and write access to /dev/kvm, the KVM device. Its getting-started guide checks this with one line that prints OK or FAIL.

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

On our test machine, itself a virtual machine with no KVM device, it printed FAIL. Cloud VMs without nested virtualisation are the same, which is why Firecracker's guide uses bare-metal cloud machines. As of 19 October 2026, gVisor's default way of catching system calls, called systrap, needs no hardware virtualisation, so gVisor can run there.

Egress control blocks every outbound connection unless the destination is on a short allowlist. The agent can still fetch code and packages, but it cannot wander to a partner's server.

In the team's setup, the microVM has one network path: an egress proxy, a small server that checks each request before passing it on. The firewall drops every other route. Here is the heart of the proxy's check.

from urllib.parse import urlparse

ALLOWED_HOSTS = {
    "git.internal",
    "pypi-mirror.internal",
    "model-gateway.internal",
}

def check_egress(run_id, url, audit_log):
    host = urlparse(url).hostname or ""
    allowed = host in ALLOWED_HOSTS
    audit_log.append({"run": run_id, "host": host, "allowed": allowed})
    if not allowed:
        raise PermissionError(f"Run {run_id}: egress to {host} blocked")
    return True

The key line is the membership test against ALLOWED_HOSTS. Every decision is logged, and a blocked call raises an error the monitor can count. This simple version checks the host name only; the engineer section shows why that is not enough.

We ran this check on Python 3.13.16 against nine addresses. The partner's staging server was blocked: that is the call that hurt the team.

Now check it from inside a sandbox. Point curl, a command-line web client, at the proxy and ask for a host that is not on the list. Our test proxy refused it, and curl printed this and exited with code 56.

$ curl -sS -x http://127.0.0.1:3128 https://partner-staging.example.com/v1/charge
curl: (56) CONNECT tunnel failed, response 403

That 403 is the proxy saying "forbidden". Next, try to go around the proxy. Dropping -x is not enough if the sandbox sets https_proxy in the environment, because curl still reads it.

$ curl -sS --noproxy '*' --max-time 5 https://203.0.113.7/
curl: (7) Failed to connect to 203.0.113.7 port 443 after 0 ms: Couldn't connect to server

The --noproxy '*' flag ignores every proxy setting, and an IP address skips DNS. 203.0.113.7 is a reserved example address. Swap in the IP of a public HTTPS site that normally answers, so a timeout can only mean your firewall stopped it.

Only (7) Failed to connect or (28) Connection timed out is a pass. In our tests, a firewall that refused gave (7), and one that silently dropped gave (28) after five seconds.

A (6) Could not resolve host proves nothing: it only means DNS failed. We tested this with an open route left in place: the check by name printed (6), while the check by IP got a page. Any other answer, even a certificate error, means a route exists and the firewall rule is missing.

In the diagram, the first question refuses the team's agent on its first call to the partner, and the log records it. The monitor then stops the run, because the partner is a known third-party host. Had the agent sent the old key to an allowed host, the second question would have stopped it.

More than you would expect. A host allowlist checks one thing, the destination's name. Our tests and sources show three gaps the simple version leaves open, and one it closes but an ends-with check does not.

One more limit is built into HTTPS. When a client asks a proxy for an encrypted site, it sends a CONNECT request naming only the host and port. RFC 9110, the HTTP standard, then has the proxy relay bytes blindly.

So a plain HTTPS proxy can allow or refuse a host, but it cannot see which page or API call the agent makes. Path-level rules need a proxy that ends the encryption itself, for example one that makes the API call on the agent's behalf.

They make a misused key worthless within minutes and useless outside one task. The idea is that real, long-lived secrets never sit inside the sandbox at all.

InfoQ's 16 October report describes this design in Chainguard's beta workspaces. A host-side proxy adds short-lived credentials to approved outbound requests, rather than placing long-lived secrets in the guest. That is the vendor's description, not an independent test.

In the team's setup, the credential proxy issues tokens that expire after 15 minutes and work for one repository. For evaluation work, CERT-In goes further and asks for synthetic credentials, fake keys that open nothing real.

To add a token, the credential proxy must read each request. So either the agent sends it unencrypted to the proxy, which encrypts it onward, or the proxy ends the encryption with a certificate only the sandbox trusts. That is also how it spots a key it did not issue.

A tamper-resistant audit log, a record of everything the agent did, makes any later edit detectable. A kill switch stops a run while it is happening. One lets you explain what happened; the other limits it.

Tamper-resistant logs with a hash chain

A hash is a short fingerprint of some data: change one character and the fingerprint changes completely. In a hash chain, each entry also stores the previous entry's fingerprint, linking them like a chain.

import hashlib
import json

def entry_hash(prev_hash, event):
    body = json.dumps(event, sort_keys=True)
    return hashlib.sha256((prev_hash + body).encode()).hexdigest()

def append_entry(log, event):
    prev_hash = log[-1]["hash"] if log else "0" * 64
    log.append({"event": event, "prev": prev_hash, "hash": entry_hash(prev_hash, event)})

def first_bad_entry(log):
    prev_hash = "0" * 64
    for i, entry in enumerate(log):
        if entry["prev"] != prev_hash or entry["hash"] != entry_hash(prev_hash, entry["event"]):
            return i
        prev_hash = entry["hash"]
    return None

The first_bad_entry function walks the log, recomputes every fingerprint and returns the position of the first entry that does not match. A clean log returns None.

Pause and predict: someone edits entry 40 of a 50-entry log, then fixes entry 40's stored fingerprint to match. Which entry does the check flag now?

We ran it. Editing entry 40 alone was flagged at 40. Fixing entry 40's fingerprint moved the failure to 41, because entry 41 still holds the old fingerprint in its prev field.

What just happened? The chain forces a tamperer to rewrite every later entry. But that is possible: when we rebuilt entries 40 to 49, the check passed again.

So the team copies the latest fingerprint every minute to write-once storage that nobody can change after saving. The rebuilt log's last fingerprint no longer matched that copy. Entries written since the last copy stay unprotected, so copy often.

Certificate Transparency, an experimental IETF protocol for public certificate logs (RFC 9162), uses Merkle trees, trees of hashes, to make its logs append-only. It is the stronger, public version of this idea.

What should go in the log? CERT-In asks evaluators to log model-initiated requests as completely as feasible, including destination, port, protocol and result. It warns against relying on after-the-fact transcript review alone.

Live monitoring and the kill switch

A monitor outside the sandbox reads the log as it is written and applies stop rules. The team's rules stop a run on any call to a known third-party host, such as the partner's server. They also stop it on three other blocked hosts in one minute, or on any credential the proxy did not issue.

When a rule fires, the monitor stops the microVM and keeps a snapshot for investigation. CERT-In asks evaluators to give an independent operator the authority to end or restart runs; the same habit suits any team.

Build the walls first, then the alarms, then test both. These are the steps the team followed, in order.

1. 1

   Write the scope

   List what each task type may touch: repositories, hosts and ports. Anything else stops the run.

2. 2

   Isolate every run

   One fresh microVM or gVisor sandbox per task, built from a clean image and destroyed afterwards.

3. 3

   Deny egress by default

   Route everything through the egress proxy, allowlist host and port pairs, and block every other route at the firewall.

4. 4

   Remove the sandbox's own DNS

   Let the proxy resolve only allowlisted names, so lookups cannot carry data out.

5. 5

   Swap secrets for short-lived tokens

   Remove long-lived keys from images and environment variables; the credential proxy adds tokens per request.

6. 6

   Log outside the box

   Hash-chain every request decision and copy the latest fingerprint to write-once storage every minute.

7. 7

   Watch, stop and test

   Give an independent operator the kill switch, then plant a fake key and confirm the run stops.

Also scan repositories, their history and build settings for exposed secrets, as CERT-In asks. That scan would have found the old partner key before the agent did.

Treat the agent as untrusted code, then walk through the walls, the alarms and their costs.

1. 1

   State the threat

   The agent may act outside its task, by mistake or because content it read misled it.

2. 2

   Pick the isolation

   Compare containers, gVisor and microVMs; justify one microVM per task, or gVisor where KVM is unavailable.

3. 3

   Control the network

   Default-deny egress through a proxy, host and port pairs, no direct DNS, enforced by the network.

4. 4

   Handle secrets

   A proxy adds short-lived tokens and stops any run that uses a key it did not issue.

5. 5

   Prove and stop

   A hash-chained log with an off-box anchor, live stop rules and a kill switch held outside the team running the agent.