Your AI Agent Has an Unsupervised Internet Connection

Somewhere in your infrastructure right now, a process is deciding on its own which websites to visit.

It was not written by a person. It reasons its way to a plan, calls whatever tools it decides it needs, fetches whatever pages look useful, and posts results wherever it concludes they belong. Nobody reviewed that list of destinations, because nobody could. The list does not exist until the moment the agent invents it.

We spent two decades convincing engineering teams that unreviewed outbound network access is unacceptable. Then we shipped AI agents, and quietly made an exception.

The thing nobody configured

Ask a team running agents in production how they bound what the agent can reach. You will usually get one of three answers.

The first is a tool allowlist inside the agent framework. The second is a system prompt containing a sentence like "do not access external services other than those provided." The third, most honest, is a pause.

All three are the same answer. None of them is a network control.

Here is the problem in one sentence: an AI agent is a program that writes and runs other programs. If it can execute a shell command, it can open a socket. If it can install a package, it can install one that makes network calls on its behalf. If it can write a file that something else executes, the boundary has already moved somewhere you are not watching.

A restriction inside the agent is a request. The agent has to cooperate for it to hold. That is a fine property for a linter and a terrible one for a security boundary.

The oldest trick in the book still works

The fix is not new, not clever, and not exciting. It is a forward proxy: a server that makes outbound connections on behalf of the things behind it, so policy can be enforced in one place. The technology is roughly as old as the commercial web.

What makes it the right answer for agents is structural rather than technical. The proxy does not need the agent's cooperation. Put the workload in a network namespace whose only route out is the proxy, and the agent's opinion about which destinations it may use stops being relevant. It cannot decide to skip a hop it has to physically traverse.

It is also the only place that sees everything: every model API call, every tool invocation over the Model Context Protocol, every page fetch, every WebSocket frame. One vantage point, one policy, one log.

The design that works is default deny. Nothing is reachable until you allow it. Build the allowlist from traffic you actually observed by running the agent against real tasks in log-only mode first, because a list assembled from imagination manages the impressive trick of being simultaneously too permissive and missing the things that break in production.

If you want the full architecture, including how forward and reverse proxies differ and where each sits in a Zero Trust design, I wrote that up separately in Proxies Explained.

Now the part that ruins the good feeling

You have built the allowlist. The agent can reach your model provider, your issue tracker, your CRM, and three internal APIs. Everything else is denied and logged. This feels finished.

It is not, and the reason is worth sitting with.

An attacker who achieves prompt injection does not need to reach an attacker-controlled server.

They do not need to exfiltrate to a suspicious domain, because you already gave them somewhere better. They put the data in a free-text field of a service you permitted. A comment on your own issue tracker. A message in your own chat workspace. A note field in your own CRM. A commit message. A support ticket.

The destination is on the allowlist. The request passes policy. The connection looks exactly like the thousands of legitimate ones before it. And the data is gone.

Every service on that list is there for a good reason, and nearly every one of them accepts free-form text. That combination is the exfiltration channel, and no amount of destination-based policy can see it, because from the network's point of view nothing unusual happened at all. Prompt injection has sat at the top of the OWASP Top 10 for LLM Applications since the list existed, and this is the quiet reason it stays there: the payoff does not require breaking out of your perimeter, only using it.

Closing that gap means the proxy has to read the request body, not just the address on the envelope. Credential patterns leaving in a payload. Base64 blobs sitting in a field that should hold a sentence. A tool call that normally carries two hundred characters suddenly carrying two hundred kilobytes.

That is the actual difference between a firewall and an agent egress proxy. A firewall asks whether the connection is allowed. An egress proxy for agents asks whether this particular request is allowed, which means opening it.

The gate you left in your own fence

There is one more hole, and it catches the teams who did everything else right.

MCP tool servers are usually their own processes. Often their own containers. Sometimes their own hosts. And when a tool server does its job, it makes its own outbound connections: to the API it wraps, the database it queries, the endpoint it fetches from.

So if you scoped egress control around the agent's process and not around the tool servers it calls, you built a fence with a gate in it. The agent's traffic is controlled. The traffic the agent causes is not. And an injected agent choosing which tool to call, with which arguments, is choosing what that unconstrained process sends on its behalf.

The mitigation is unglamorous: route the tool servers' egress through the same proxy, under the same default-deny policy, each with its own allowlist. A tool server wrapping one API should only ever reach that API. I go through the server side of this in Secure Your MCP Server, and the full egress pattern in Egress Control for AI Agents.

Meanwhile, the same technology is being used against you

Worth remembering that proxies are dual-use, and the offensive side of this market is large and professionally run.

Attackers want to originate traffic from addresses that look ordinary. Residential and mobile addresses look ordinary. Data center addresses get challenged or blocked. So there is real money in supplying residential exit nodes, and one reliable way to supply them is malware.

Bitsight's research, published in December 2024, documented Socks5Systemz, a malware family that installs a SOCKS5 proxy on infected consumer machines and rents them out as exit nodes. It peaked around 250,000 compromised systems in early 2024. In August 2026, Fortinet's FortiGuard Labs documented Evooo1Bot, a Linux botnet that turns routers, cameras, and firewalls into SOCKS5 relays by exploiting flaws that were already patched.

Two things follow. Residential IP space is not a trust signal, so stop scoring it as safer than data center space in your fraud and abuse logic. And a workstation on your network that starts accepting inbound connections and relaying traffic outward is doing something no workstation should ever do. Your egress logs are where you notice.

What to do this week

None of this needs a procurement cycle. In rough order of payoff:

1. Find out what your agents actually connect to. Put a proxy in front in log-only mode and read the list. Most teams are surprised, and the surprise is the point.
2. Turn that observed list into a default-deny allowlist, kept in version control next to the agent's code, so adding a destination is a reviewed change and not a console click nobody remembers.
3. Proxy your MCP servers too, each with an allowlist much narrower than the agent's.
4. Add body inspection on the destinations that accept free text, scanning for credentials and encoded payloads. This is the control that addresses injection rather than just misconfiguration.
5. Log destination, decision, rule matched, and a body hash. Not full bodies by default, because for agent traffic a complete log is a copy of every prompt, document, and customer record the agent has ever touched.
6. Then go remove the static credentials sitting in the agent's environment, because those are what an injection is usually reaching for in the first place. Replace Static API Keys covers that.

The unglamorous conclusion

There is a pattern in security where the newest problem turns out to need the oldest control, and everyone is faintly disappointed.

Agents are genuinely new. They plan, they choose, they act, and they will keep getting more capable. But the question "what is this thing allowed to talk to, and what is it allowed to say" is not new at all. We have known how to answer it since the 1990s, at a box in the middle that both sides have to go through.

The mistake is not that we lack the technology. It is that agents arrived through the AI budget rather than the infrastructure budget, so nobody in the conversation was the person who normally asks about egress. That gap is where the exposure lives, and closing it is mostly a matter of someone noticing.

Bound where your agents can go. Inspect what they send. Extend both to the tool servers. Then worry about the model.

Read next

• Proxies Explained: Forward, Reverse, and Why They Are a Security Control Plane, the full architecture reference.
• Egress Control for AI Agents, the implementation guide for everything above.
• Identity for AI Agents, because bounding where an agent goes is only half of it. Who it is when it gets there is the other half.
• TLS Inspection with a Forward Proxy, if you are inspecting human traffic as well and need the bypass list and privacy line.
• Top 5 Reverse Proxies for 2026 and Top 5 Intercepting Proxy Tools for 2026, if you are picking the actual software.
• Zero Trust Architecture Explained, for where all of this sits in the wider picture.