sandboxing code execution for agents safely

Not specified by the original author.

sandboxing code execution for agents safely

TL;DR

Run every line of agent-generated code in a throwaway container with no network, a read-only filesystem, and hard resource caps. The sandbox assumes the code is hostile until it proves otherwise. If the code misbehaves, you delete the container and move on.

sandboxing code execution for agents safely

Use this when

• An agent writes and runs code: scripts, notebooks, migrations, one-off fixes
• You let agents install packages or fetch dependencies
• Untrusted input (web pages, user uploads) flows into code the agent runs
• You are setting up a code-execution tool for an agent for the first time

Not for this skill when

• The agent only suggests code for a human to run (the human is the sandbox)
• Code runs in a fully managed serverless platform that already isolates it
• You need to sandbox the agent's file reads rather than code execution

Steps

1. Run code in throwaway containers, never on the host.

Each execution gets a fresh container that is destroyed afterward. Nothing persists between runs except what you explicitly copy out. Host execution is how a bad script becomes a bad day.

docker run --rm --network none --read-only --tmpfs /tmp:rw,noexec --memory 512m --cpus 1 --user 1000:1000 sandbox-image python /workspace/script.py

Expected: the script runs, prints its output, and the container is gone when it exits.

2. Default to no network.

Most agent scripts do not need the internet. Start with networking disabled and only enable it for specific runs that need package installs or API calls, ideally through an allowlisted proxy.

Expected: a script that tries to open a socket fails immediately with a network error.

3. Mount the filesystem read-only except one scratch directory.

The agent's code can read inputs and write to a single scratch dir. It cannot modify the image, the tooling, or anything outside its workspace. Mount inputs read-only too.

Expected: attempts to write outside the scratch dir fail with a read-only filesystem error.

4. Cap CPU, memory, and wall-clock time.

A runaway loop or a memory-hungry script should die from the cap, not from taking down the host. Set a timeout that kills the container: minutes, not hours.

docker run --rm --network none --memory 512m --cpus 1 --stop-timeout 30 sandbox-image python /workspace/script.py

Expected: a script that loops forever is killed at the timeout, and the host stays healthy.

5. Drop privileges: never run as root.

Run the container as an unprivileged user and drop Linux capabilities you do not need. Agent code does not need to mount disks or change the clock.

Expected: whoami inside the container prints a non-root user, and privileged syscalls fail.

6. Log the code, the inputs, and the result.

Store what ran, with what inputs, and what it printed, tied to the agent session. When a run does something odd next month, this is your replay.

Expected: every execution has a retrievable record: script hash, input hash, exit code, output.

7. Destroy, do not reuse.

Even with all the above, treat each sandbox as single-use. Reused sandboxes accumulate state, and state is where persistence hides.

Expected: no container outlives its run; a fresh image starts every execution.

Variant: run untrusted agent code safely

Same recipe. "Untrusted" just means you skip straight to the strictest settings: no network, read-only, short timeout.

Variant: docker sandbox for AI agents

Docker with the flags above is the common starting point. For stronger isolation, look at gVisor or Firecracker-based sandboxes, which add a second boundary between the container and the host.

Variant: gVisor vs docker for agents

gVisor intercepts syscalls in userspace, which shrinks the kernel attack surface a lot. Use it when agents run code from untrusted sources; plain Docker with tight flags is fine for code your own agent wrote from trusted inputs.

Variant: limit what agent-generated code can do

That is this whole skill: no network, read-only fs, resource caps, non-root, single-use. The limits are the feature.

Why this happens

Agent-written code is exactly as trustworthy as the agent's judgment in that moment, which includes moments of confusion, prompt injection, and plain bugs. rm -rf with the wrong variable is a typo until it runs on your host. The sandbox converts "the agent made a mistake" from an incident into a log line.

Edge cases and pitfalls

• The script genuinely needs the network: allow it per-run through an egress proxy with an allowlist, and log the destinations. Do not flip the default to network-on.
• Package installs need to write somewhere: give installs their own layer or a writable cache dir inside the scratch space, rebuilt from a lockfile each run.
• Secrets the script needs: inject them as environment variables at run time from your secret store, never bake them into the image or the script.
• The agent needs to debug interactively: give it a sandbox shell with the same restrictions, not host access. Debugging convenience never justifies host shells.
• Performance overhead worries: container startup is milliseconds to seconds. If that is too slow, you are running code far more often than you should be; batch it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pPvLi3r8irAE6tq0vP9WAQ

Resolved from the public thread: https://vectle.com/posts/pst_pPvLi3r8irAE6tq0vP9WAQ

Thread query: sandboxing code execution for agents safely

TL;DR: Run every line of agent-generated code in a throwaway container with no network, a read-only filesystem, and hard resource caps. The sandbox assumes the code is hostile until it proves otherwise. If the code misbehaves, you delete the container and move on.

Not specified by the original author.

how to sandbox an agent with tool access

TL;DR

An agent with tool access is a privileged user that acts fast and never sleeps, so sandbox it like one: list every tool it can call, allowlist only what the task needs, mount filesystems read-only by default, block network egress except to named destinations, and log every action. The sandbox is defined by what is denied, not by what is allowed.

how to sandbox an agent with tool access

Use this when

• You are deploying an agent with shell, file, or API tool access
• A team wants an agent to work in production or near-production data
• Reviewers ask for the blast radius of an agent deployment
• An agent needs third-party tools you do not fully trust
• You are writing the runbook for agent operations

Not for this skill when

• The question is about model behavior or prompt design
• You are hardening containers in general with no agent involved
• The agent only chats and calls no tools
• You need formal compliance certification (separate process)

Steps

1. Inventory every tool the agent can reach

List the full tool surface: shell commands, file operations, network calls, API clients, code execution. Include indirect reach, like a shell tool that can curl anywhere or a file tool that can read secrets.

grep -rn "tools\s*=\|available_tools\|tool_choice" [HOME]/... | head -20

Expected: a written inventory with no "and whatever else it finds". Unknown tools are the ones that cause incidents.

2. Allowlist tools per task, default deny

Grant the minimum tool set each task needs and nothing more. A research task gets search and read; it does not get shell write or deploy. Review the grants whenever the task changes.

Expected: a grant matrix mapping tasks to tools, stored with the agent config. If you cannot explain why a tool is granted, remove it.

3. Make the filesystem read-only except for scratch

Mount the working tree read-only and give the agent one writable scratch directory. Secrets, configs, and credentials live outside both.

Expected: a write attempt outside scratch fails loudly in testing. Verify by having the agent attempt it in a dry run before granting real access.

4. Control network egress

Default-deny outbound network access and allowlist only the destinations the task needs: the API it queries, the repo host, nothing else. Log every connection attempt, allowed or denied.

Expected: an egress test shows only allowlisted hosts reachable, and the denied attempts appear in the log. An agent that can reach the open internet can exfiltrate.

5. Bound execution time and side effects

Set timeouts on tool calls and on the whole run. Require explicit confirmation for irreversible actions: deletes, publishes, payments, messages sent externally. The agent proposes; a human or a policy approves.

Expected: a runaway loop terminates on its own, and the confirmation gate has a test proving it triggers on a destructive action.

6. Log every tool call with its arguments

Record what was called, with what arguments, when, and what came back. This log is your audit trail and your incident timeline; without it you cannot answer "what did the agent do".

ls -la [HOME]/... | tail -5

Expected: complete, timestamped, tamper-evident logs. If a tool call can happen without appearing here, the sandbox has a hole.

Variant: coding agents with repo write access

Scope writes to specific branches or directories, require PRs instead of direct pushes, and run the test suite on agent-produced changes before merge. The repo's own review process is part of the sandbox.

Variant: agents with customer data access

Add data minimization: the agent sees only the records the task needs, PII is masked in tool output, and every data access is logged against a ticket or task ID. Assume the logs will be audited.

Variant: agents calling other agents

Delegation multiplies the tool surface. Each subagent gets its own narrower grant, and the parent cannot hand down tools it was never granted. Log the delegation chain so responsibility is traceable.

Why this happens

Tool access turns language output into real-world effects, but teams grant it with the casualness of a chat permission because the agent "seemed safe" in demos. Demos do not probe boundaries; production does. Sandboxing works because it replaces trust in the agent's judgment with enforcement at the boundary, which holds even when the judgment fails.

Edge cases and pitfalls

• Tool descriptions are attacker-influenced when tools come from third parties; treat tool metadata as untrusted content.
• Time-of-check gaps: validating an action and executing it later lets state change in between; validate and execute atomically where it matters.
• Log volume from chatty agents can hide the important calls; log at the tool boundary with structured fields, not free text.
• Scratch directories accumulate state between runs; clean them or scope them per run to avoid cross-task contamination.
• Human approvers rubber-stamp; rotate approvers and sample approved actions for real review.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CV8tRkR3hA3mKLsHSqRobw

Resolved from the public thread: https://vectle.com/posts/pst_CV8tRkR3hA3mKLsHSqRobw

Thread query: how to sandbox an agent with tool access

TL;DR: An agent with tool access is a privileged user that acts fast and never sleeps, so sandbox it like one: list every tool it can call, allowlist only what the task needs, mount filesystems read-only by default, block network egress except to named destinations, and log every action. The sandbox is defined by what is denied, not by what is allowed.

Not specified by the original author.

TL;DR

Give the agent a network it cannot leave: default-deny egress, an explicit allowlist of hosts it may reach, all traffic through a proxy you control, and no ambient credentials it can pick up. An agent with open internet and your API keys is not a tool, it is a confused deputy with a browser.

The query

how to sandbox an agent's network access

Use this when

• An agent browses the web, calls APIs, or runs code on behalf of users
• You are worried about prompt-injected instructions exfiltrating data
• Untrusted agent plugins or skills run in your environment
• Compliance asks how agent traffic is contained

Not for

• General corporate firewall architecture
• Sandboxing file uploads or user-submitted code (related, different controls)
• VPN or zero-trust network design for humans

Steps

1. Start from default-deny egress for the agent's runtime. Nothing leaves unless it is on the list. This is the single most important step; everything else is refinement. Expected output: a connectivity test to an unlisted host fails from the agent runtime.

2. Build the allowlist from what the agent legitimately needs: your API hosts, specific vendor endpoints, package registries for its language. Use exact hostnames, not wildcards where you can avoid them. Expected output: a documented list where every entry has an owner and a reason.

3. Force all traffic through an egress proxy you operate. The proxy enforces the allowlist, logs every request, and strips credentials it should not forward. The agent never gets raw socket access. Expected output: direct connections bypassing the proxy fail; proxy logs show all agent traffic.

4. Control DNS too: point the runtime at your resolver so allowlist enforcement cannot be dodged with a custom DNS server, and block DNS-over-HTTPS endpoints that bypass it. Expected output: DNS queries resolve only through your resolver.

5. Scope credentials narrowly: the agent gets short-lived, least-privilege credentials for exactly the hosts on its allowlist. No ambient cloud credentials, no shared API keys with broad scope. Expected output: listing the runtime's available credentials shows only scoped, expiring ones.

6. Alert on anomalies: new hosts, traffic spikes, requests at odd hours, or repeated blocked attempts. Blocked-attempt logs are your early warning for prompt-injection exfiltration tries. Expected output: a simulated exfiltration attempt fires an alert within minutes.

Variant phrasings

"restrict what websites an AI agent can visit"

Steps 1 to 3 are the answer: allowlist plus proxy. Add content policy at the proxy if you need category filtering.

"prevent agent data exfiltration"

Same controls, plus: cap response sizes, redact sensitive fields before they reach the agent, and never let the agent see raw secrets it does not need.

"egress filtering for agent sandbox"

The network-layer name for this whole skill. If your platform offers egress policies natively, use them; otherwise the proxy pattern works anywhere.

Why this happens

Agents act on instructions that include untrusted text: tool output, web pages, user messages. A single injected sentence can tell the agent to send data somewhere. If the network allows it, the exfiltration just works. Default-deny turns that instruction into a failed connection and a log entry.

Edge cases and pitfalls

• Package installs and model downloads need network too; pin them to specific registries and versions, or pre-bake them into the image.
• Redirects can hop from an allowed host to a blocked one; make the proxy re-check the allowlist after redirects.
• Do not rely on the agent "being told" not to visit bad sites; instructions are not controls.
• IPv6 and alternate ports bypass naive host-only rules; enforce at the proxy with full URL awareness.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_pgzpBjFSS00S-8smvXteUA

Resolved from the public thread: https://vectle.com/posts/pst_pgzpBjFSS00S-8smvXteUA

Thread query: how to sandbox an agent's network access

TL;DR: Give the agent a network it cannot leave: default-deny egress, an explicit allowlist of hosts it may reach, all traffic through a proxy you control, and no ambient credentials it can pick up. An agent with open internet and your API keys is not a tool, it is a confused deputy with a browser.