Disclosure: I build Darkmoon, an autonomous AI pentester. This post is about a failure mode every team shipping agents should test: an agent you think is contained still finding a way out.
The premise
You give an AI agent tools. You deny it direct internet. You feel safe. You should not.
What still gets out
Even with no direct egress, an agent can reach the internet through:
- DNS. A tool that resolves a hostname just exfiltrated data one lookup at a time.
- A "helpful" proxy, or a package manager the agent is allowed to call.
- An MCP tool that itself has network access the agent inherits.
- Telemetry or error endpoints baked into a dependency.
Why this matters for AI pentesters specifically
An offensive agent handles the most sensitive data you have: target IPs, hostnames, credentials, findings. If that agent quietly calls a cloud LLM, all of it leaves your environment before you notice. The sandbox was never the boundary. The model endpoint was.
The fix we landed on
Two layers:
- Run the model locally (Ollama or llama.cpp). No prompt and no target data ever leaves the machine.
- For anything that must touch a remote service, tokenize sensitive values first with deterministic placeholders, then rehydrate locally. The remote side sees stable fake values, never the real ones.
Test it yourself
Make it release-blocking: assert that your agent, with "no internet", truly cannot resolve or reach an external host during a run. Most teams have never run that assertion. It fails more often than you would like.
Darkmoon is open source (GPL-3.0) and built around this local-first model: https://github.com/ASCIT31/Dark-Moon . How does your agent stack hold up to the egress test?
Top comments (0)