Back to Blog

Proxy Settings Are a Suggestion to Your AI Agent

Proxy Settings Are a Suggestion to Your AI Agent

Coding agents install packages on their own. Claude Code, Cursor, Copilot and similar tools will run npm install or pip install mid-task, often without a human reading the package name first, and increasingly in sessions nobody is watching at all.

The usual way teams try to put guardrails on this is configuration: point HTTP_PROXY at a filtering proxy, set npm_config_registry or PIP_INDEX_URL to a vetted mirror, add rules to an AGENTS.md file. All of these share one property. They work only as long as the process reading them chooses to respect them.

Configuration only works when the agent cooperates

Proxy environment variables are honored by convention. Most HTTP clients read them, but nothing forces a client to. One command is enough to show the gap:

curl --noproxy '*' https://example.com

That request skips the proxy entirely. So does any tool that opens its own socket, any script that clears its environment, and any package manager invoked with a different registry flag. An agent doesn't need to be malicious to do this. It only needs to decide, for reasons that seem sensible in the moment, that the proxy is in the way.

Instruction files have the same problem in a different form. A rule in AGENTS.md is text the model reads, and the model reads a lot of other text too.

Prompt injection makes this worse

An agent's next action is shaped by whatever it just read: a README, a GitHub issue, a comment in a dependency, a web page it fetched to answer a question. If any of that text contains instructions, the agent has no reliable way to tell them apart from yours.

That means the same channel you'd use to tell an agent "only install from our mirror" is a channel an attacker can use to tell it something else. A guardrail the agent is trusted to follow can be talked out of by anyone who gets text in front of it. For enforcement to hold, it has to sit somewhere text can't reach.

Speed removes the human backstop

When a developer installs a package, there's a brief moment where a typo or an odd name might get noticed. An agent doesn't have that moment. It can resolve dependencies dozens of times in a session, across several sessions in parallel, overnight. Typosquats and hallucinated package names, names that sound plausible but don't exist until someone registers them, depend on exactly this: an install that nobody looks at.

None of this requires a sophisticated attacker. It requires one wrong name and nobody positioned to catch it.

Where enforcement has to live

If configuration can be ignored and instructions can be overridden, the boundary has to be something the agent runs inside, not something it is asked to respect. In practice that means:

  • No direct route out. The agent's process shouldn't have a network path to the internet except through the policy check. On Linux, network namespaces make this possible: a process can start with nothing but a loopback interface, and the only way out is a socket the host controls.
  • Package installs checked before they land. Registry traffic should go through something that can evaluate the package name and metadata (typosquat similarity, allow/deny lists, package age) before anything is written to disk.
  • A filesystem that doesn't contain your secrets. If ~/.ssh and ~/.aws don't exist inside the agent's view of the world, an injected instruction can't read them.
  • A policy you can read. The rules should be a file you own and version, not behavior buried inside a vendor's agent.

Agent vendors are building sandboxes of their own, and those help. But a guardrail owned by the same company that wants the agent to be as capable as possible is answering to two goals at once. An independent check answers only to your policy.

What's still hard

This approach has real limits, and they're worth stating plainly:

  • Enforcing at the network level sees which hosts an agent connects to, not what it sends. Inspecting request contents means terminating TLS, which brings its own trust problems.
  • Linux namespaces don't exist on macOS, where much agent work actually happens. The equivalents there are different and less complete.
  • Some CI environments block the unprivileged user namespaces this approach depends on.

What we're working on

We've been building this kind of boundary on top of Hextrap's package firewall: an agent sandbox where network access and package installs go through your policy whether or not the agent cooperates. It isn't ready for general use yet. If this problem matters to your team, the waitlist asks where you run agents and on which OS, and those answers decide what we build next.

Join the Hextrap for Agents waitlist

Comments

Loading comments…

Protect Your Supply Chain

Add a security firewall to your package manager and CI/CD pipelines.

Get Started Free