Network isolation for browser and AI-agent workers

The agentic SSRF threat model

Server-Side Request Forgery represents a critical threat to AI agents and isolated browser workers that autonomously interact with external resources. When an application accepts user input or language model generation to construct outbound network requests, inadequate validation allows attackers to proxy traffic into internal corporate networks, cloud metadata services, or restricted loopback interfaces.

Unlike traditional web applications where permitted outbound destinations are static and tightly bound, AI agents frequently require dynamic egress to varied webhooks, APIs, and site content. Defending this dynamic request architecture requires assuming that malicious inputs will attempt to coerce the worker into accessing restricted IPv4 and IPv6 space. Defensive strategies must isolate worker egress at the network layer while implementing rigorous application-layer validation before initiating TCP connections.

Parser differentials and input validation constraints

Applications often cross service boundaries where URLs are evaluated as strings and reconstructed multiple times. Vulnerabilities emerge when different parsers interpret the same URL byte string differently. An attacker can craft a payload like http://example.com\@evil.com to exploit these discrepancies.

As highlighted in the OWASP SSRF validation guidance, a parser following the WHATWG URL Standard treats the backslash under a special scheme as a path separator, evaluating the host as example.com. Conversely, a parser relying on RFC 3986 admits no backslash and treats everything before the final @ symbol as userinfo, interpreting the host as evil.com. For instance, CPython's urllib.parse derives the host using netloc.rpartition('@'), returning evil.com. Applications must reject any URL whose host is not read identically by every parser in the stack, treating parser disagreement as an outright rejection rather than attempting to reconcile the readings.

Defeating DNS rebinding via IP pinning

Domain allowlisting alone is insufficient to prevent SSRF due to DNS rebinding attacks. In a rebinding attack, a malicious domain initially resolves to a safe, public IP address to pass domain validation. However, the DNS record carries an extremely short Time-To-Live. By the time the application's HTTP client connects, a second DNS lookup occurs, which the attacker's nameserver resolves to an internal target, such as 169.254.169.254. Evaluating DNS query answers separately does not prevent this race condition.

To securely facilitate allowed domain requests, systems must validate the resolved destination IP addresses against permitted networks, and then bind the HTTP client connection explicitly to that validated address. Implementations should mimic curl's custom address resolution mechanism, connecting to the pre-validated IP while preserving the original hostname for the HTTP Host header, TLS Server Name Indication, and certificate verification. All retry logic and connection fallbacks must enforce these identical pinning constraints.

Safe test matrix for egress isolation

Validating network egress controls requires a deterministic test matrix executed against isolated synthetic fixtures. Security test cases must evaluate the routing logic without exposing real infrastructure or utilizing active exploit targets. The following expected outcomes define a standard enforcement baseline.

Expected allowed connections include requests to explicitly allowed domains resolving to public, non-reserved IP space, with corresponding valid SNI and Host headers. Valid Webhook requests with compliant token payloads to verified public endpoints should also proceed.

• Fixture A: Input http://127.0.0.1/admin. Expected Outcome: Denied. Fails non-reserved IP verification.
• Fixture B: Input http://169.254.169.254/latest/meta-data/. Expected Outcome: Denied. Fails cloud metadata IP blocklist.
• Fixture C: Input http://safe-domain.test resolved to 10.0.0.5. Expected Outcome: Denied. DNS resolution yields internal RFC 1918 address.
• Fixture D: Input http://trusted.test\@malicious.test. Expected Outcome: Denied. Fails parser differential consensus checks.
• Fixture E: Input http://0x7f000001/. Expected Outcome: Denied. Hex-encoded loopback fails strict IP parsing validation.

Implementation tradeoffs and failure modes

Implementing strict IP pinning and parser consensus checks introduces operational overhead. Custom HTTP client configurations that override default DNS resolution paths can complicate connection pooling and observability metrics. If proxy infrastructure intercepts traffic, the custom IP bindings might be stripped, reverting the system to vulnerable deferred DNS lookups.

A common failure mode in webhook processing involves IPv6 bypasses. If an application meticulously filters IPv4 private ranges but fails to reject Unique Local Addresses or Link-Local IPv6 addresses, attackers can pivot to internal IPv6 services. Furthermore, maintaining custom deny-lists for dynamic egress is inherently fragile. Cloud providers frequently update metadata endpoints, and neglecting to block all relevant IP variations leads to silent exposure.

Sources and evidence limits

Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results.

Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results.

• OWASP SSRF Prevention Cheat Sheet