how to sandbox an agent's network access

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.

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 prevent agents from exfiltrating data

TL;DR

Assume any agent with tool access can send data somewhere, and design so it cant. Block network egress by default and allowlist only the domains the task needs, hand the agent scoped short-lived credentials instead of real secrets, and put a review gate on anything that sends data out: uploads, outbound messages, publishes. Exfiltration prevention is a configuration problem, not a trust problem. The agent never gets a path it doesnt strictly need.

The query

how to prevent agents from exfiltrating data

Steps

1. List everything the agent can reach

Write down the data the agent can read, the tools it can call, and the network it can reach. If you cant enumerate it, you cant control it.

Expected: a short list of repos, file paths, API endpoints, and which of those are sensitive. Most agents can reach more than their operator thinks.

2. Deny network egress by default, allowlist the rest

Configure the agent's network so outbound requests fail unless the destination is on an explicit allowlist of domains the task requires.

# example allowlist; adapt to your runner's egress format
[https://api.your-workspace.com, https://registry.your-org.com]

Expected: a fetch to any non-listed domain fails closed. Test it once: ask the agent to fetch an unlisted domain and confirm the request is blocked.

3. Give the agent scoped, short-lived credentials

Issue credentials that only cover the task: read-only scopes, the minimum repos or tables, and expiry measured in hours, not months. Never put a real secret or a full-access key into the agent's context. Prefer per-task tokens with the narrowest grants the work needs.

Expected: the agent can do its job and nothing adjacent. A leaked or abused credential from this agent expires fast and can touch little.

4. Gate every outbound action on review

Route uploads, outbound messages, publishes, and any tool that sends data outside your boundary through an approval step: a human click, or an automated policy check that inspects payload content before release.

Expected: no data leaves without a recorded decision. When the agent "helpfully" tries to email a file out, the request waits for approval instead of going.

5. Log what the agent touched and scan for anomalies

Keep an append-only log of the agent's reads, writes, and network calls, and review it for patterns: reads of sensitive files followed by outbound calls, or fetches to newly seen domains. A compromised or misbehaving agent shows up in this log long before anyone notices the leak.

Expected: every agent action is traceable to a timestamp and a payload. Spot-check one run and confirm you can reconstruct what data the agent saw.

When to use

• You are setting up an agent with tool, file, or network access
• You are reviewing what data an agent can read and where it can send things
• An agent fetched an unexpected URL or tried an outbound action you didnt expect
• You run agents in production and want exfiltration to be a solved problem, not a hope

When not to use

• You want to hide agent activity from your own monitoring or oversight (thats evasion, and this skill is not that)
• You need to lock down a whole network or org, not one agent (use your cloud and network security controls)
• The threat is a human insider, not an agent (different controls, different skill)
• You are looking for anti-detection or bypass techniques (not covered here, and never covered here)

Tool compatibility

Any agent framework with tool use and network access: Claude Code, OpenAI Codex and similar CLI agents, LangChain/LangGraph agents, custom MCP-based agents. Egress allowlisting applies wherever you control the agent's network: containers, sandboxed runners, proxy-based tool gateways. Credential scoping depends on your provider's token model; short-lived scoped tokens work on any platform that supports them.

Variant phrasings

how to stop an AI agent leaking data

Same controls, different words: egress allowlist plus scoped credentials plus outbound review. "Leaking" usually means someone wants the checklist for a new agent deployment. Start with steps 1 and 2; they cover most of the risk.

can an agent steal my data

Treat the answer as yes and build the controls anyway. An agent with broad file read and open network access can move data out. The steps above close the read-to-send pipeline at every joint: less readable data, fewer places it can go, review on the way out.

how to prevent AI agents from sending data to external servers

The strict version of this skill. Run step 2 with an empty allowlist during sensitive work, plus step 4 so even an approved fetch's response cant be forwarded somewhere else. For the highest-stakes runs, run the agent with no network at all and have it hand results to a human for the final step.

Why it happens

Agents turn intent into tool calls, and their tool calls have no judgment about which destination is fine. A model that reads your whole repo and can fetch arbitrary URLs will, at some point, combine the two: read sensitive data, send it somewhere. Every agent data incident is some version of that pipeline. The fix doesnt ask the agent to be careful; it removes the paths where carelessness becomes exfiltration.

Edge cases and pitfalls

• Indirect exfil: the agent may not send data directly. Watch for encoding tricks like data hidden in a URL query or posted through a benign-looking webhook. The outbound review in step 4 catches these if it inspects payloads, not just destinations.
• Allowlist drift: tasks change and people widen the allowlist "just for this run". Review the allowlist monthly and default new tasks to a fresh empty one.
• Cached credentials: an agent that saw a real secret once may echo it back later. Prefer issuing scoped tokens from the start over rotating after the fact.
• The review gate becomes the bottleneck: too many approvals and operators rubber-stamp everything. Keep the agent's reach small so the approval list stays short and each one gets real attention.

Provenance

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

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

Thread query: how to prevent agents from exfiltrating data

TL;DR: Assume any agent with tool access can send data somewhere, and design so it cant. Block network egress by default and allowlist only the domains the task needs, hand the agent scoped short-lived credentials instead of real secrets, and put a review gate on anything that sends data out: uploads, outbound messages, publishes. Exfiltration prevention is a configuration problem, not a trust problem. The agent never gets a path it doesnt strictly need.