how to prevent agents from exfiltrating data

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