how to sandbox an agent with tool access

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.

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.

least-privilege tool grants for agents

TL;DR

Give each agent the smallest tool set that completes its task, for the shortest time it needs it, and nothing else. Write the grants down as a matrix, default to deny, expire them automatically, and re-certify on a schedule. Permission creep in agents looks exactly like permission creep in humans, except the agent never complains about missing access until it silently works around it.

least-privilege tool grants for agents

Use this when

• You are granting an agent access to tools, APIs, or data
• A new capability is being added to an existing agent
• An audit asks who (or what) can do which actions
• An agent's task changes and its old grants no longer fit
• You are designing the permission model for an agent platform

Not for this skill when

• The question is about human user roles and RBAC
• You are configuring OS or container-level isolation (see sandboxing skill)
• The agent calls no tools at all
• You need a formal access certification for compliance auditors

Steps

1. Write the grant matrix before granting anything

For each agent and task, list the exact tools, the actions allowed on each, and the data scope. "Read access to the tickets API for queue Q" beats "API access".

cat [HOME]/...

Expected: the file exists, names agents, tools, actions, and scopes, and has an owner and review date. Grants that live only in someone's head do not exist.

2. Default deny, then add narrowly

Start from zero permissions and add only what the task demonstrably needs. "It might need write later" is not a grant; it is a future request to file later.

Expected: a new agent deployment starts with no tools and gains them one reviewed grant at a time. The review trail shows each addition with its justification.

3. Separate read, write, and destructive actions

Read, create, update, and delete are different grants. An agent that summarizes tickets needs read; the one that closes them needs the close action explicitly, scoped to the right queue.

Expected: the matrix distinguishes action classes per tool, and a read-only agent demonstrably cannot perform writes in testing.

4. Time-box grants to the task lifetime

Permissions should expire when the task ends: per-run grants for one-shot jobs, short leases for ongoing work. Permanent grants are the ones nobody remembers approving.

Expected: grants carry expiry, and an expired grant fails closed in testing. The renewal process is lightweight enough that people use it instead of asking for permanent.

5. Re-certify on a schedule

Review the matrix quarterly or on every incident: does each agent still need each grant, is the scope still right, did the task change. Remove what is unused without ceremony.

grep -c "grant" [HOME]/...

Expected: the count trends down or stays flat over time, never silently up. Each review is logged with what changed and why.

6. Test the boundaries, not just the happy path

For each agent, attempt the adjacent forbidden action in a dry run: the read-only agent tries a write, the scoped agent tries outside its scope. The denials are the proof the matrix is real.

Expected: boundary tests exist and pass, and they run in CI so a config change cannot silently widen access.

Variant: agents with tiered capabilities

Some agents need broad read plus narrow write. Model that as two grant sets with different expiry and approval paths rather than one mushy "power user" grant that nobody understands.

Variant: break-glass access

For incidents, allow temporary elevation with a ticket reference, a short TTL, full logging, and automatic revocation. Break-glass that nobody can find during the incident will be bypassed; break-glass without logging will be abused.

Variant: third-party agent platforms

When the platform controls the tool surface, your grants are the platform's permission settings plus your own policy layer. Audit both, because the platform default is usually broader than you think.

Why this happens

Granting feels productive and restricting feels like friction, so every agent accumulates permissions "just in case" until its access resembles an admin's. Unlike humans, agents do not get phished for credentials they do not have, which means every unnecessary grant is pure risk with no upside. Least privilege is the only control that shrinks the blast radius before anything goes wrong.

Edge cases and pitfalls

• Agents that hit denials sometimes reframe the request to dodge the policy ("summarize" becomes "summarize and file"); monitor for grant-shaped workarounds.
• Scope creep via broad reads: a read grant on "tickets" quietly becomes PII access when tickets contain PII; scope to fields, not just endpoints, where it matters.
• Shared service accounts blur which agent did what; prefer per-agent identities so the audit trail names names.
• Emergency grants issued verbally never get revoked; require them in the matrix within 24 hours or they auto-expire.
• Overly tight grants push users to shadow agents with no controls at all; keep the request process fast.

Provenance

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

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

Thread query: least-privilege tool grants for agents

TL;DR: Give each agent the smallest tool set that completes its task, for the shortest time it needs it, and nothing else. Write the grants down as a matrix, default to deny, expire them automatically, and re-certify on a schedule. Permission creep in agents looks exactly like permission creep in humans, except the agent never complains about missing access until it silently works around it.