Inspecting Claude Code’s Network Traffic with Linux Namespaces and MITM Proxying (Part 5)

Classifying all of Claude’s network connections

So far we’ve examined individual connections. We looked at a single WebFetch and a single decrypted API call. To build a complete picture of Claude’s network behavior, we need to exercise all of its network tools in a single session and categorize every connection it makes. This produces a full traffic matrix: which destinations Claude contacts, what each connection carries, and whether each request originates from your machine or routes through Anthropic. That matrix is the basis for the security analysis that follows.

Setting up the full test

Run a prompt that exercises multiple network tools:

./mitm-capture.sh "First, use WebFetch to fetch https://example.com and tell me the page title. Then use WebSearch to search for 'linux network namespaces tutorial' and summarize the top result."

Analyzing by category

WebFetch traffic:

We can pull specific get requests by parsing the mitm.txt file generated by the mitm-capture.sh script

grep -A 5 '>>> GET https://example.com' mitm.txt

The command above will provide you with the results of a direct GET request to the target URL from the local machine. The request includes the Claude-User User-Agent. The response body contains the full page content.

WebSearch traffic:

grep -A 5 '>>> .*search' mitm.txt   # Look for search-related requests

Observe whether search queries go directly to a search engine or route through the Anthropic API. Run this yourself. The behavior may depend on your Claude Code version and configuration. Document what you find. The traffic capture tools give you the means to answer this question empirically rather than guessing.

API traffic:

grep '>>> POST.*api.anthropic.com' mitm.txt

These are the model inference calls. Your prompt goes to Anthropic, the model reasons about tool use and the response comes back with tool invocations and final answers.

Telemetry traffic:

grep '>>> .*datadoghq' mitm.txt

Usage logging and metrics sent to DataDog’s intake endpoint.

MCP traffic:

grep '>>> .*mcp\|>>> .*cloudflare' mitm.txt

If you have MCP servers configured, claude contacts them at startup.

The traffic matrix

Traffic Type	Destination	Origin	Encrypted	Contains
WebFetch	Target URL directly	Your machine	Yes (TLS)	Full HTTP GET with Claude-User UA
WebSearch	Observe and document	Observe	Yes (TLS)	Search queries and results
Model API	api.anthropic.com	Your machine	Yes (TLS)	Prompts, tool calls, model responses, API key
Telemetry	*.datadoghq.com	Your machine	Yes (TLS)	Usage metrics
MCP	Configured servers	Your machine	Varies	MCP protocol messages

The key architectural finding is WebFetch is a local operation. When claude uses the WebFetch tool, the Claude CLI running on your machine makes a direct HTTP(S) connection to the target URL. The request originates from your IP address, goes directly to the target server, and the response comes back to your machine. The Anthropic API is not in the middle.

These are the Immediate implications:

• Claude can fetch from any URL your machine can reach
• Internal/LAN services (http://192.168.x.x/..., http://localhost:...) are accessible
• The target server logs YOUR IP address as the requester
• Network restrictions on your machine (firewall rules, VPN routing) apply to these fetches

Security implications of local fetch for your network

LAN accessibility by Anthropic

If WebFetch connects directly from your machine, then claude can be prompted to reach internal services:

"Use WebFetch to fetch http://192.168.1.1/ and tell me what you see."

By default, Claude Code shows each tool invocation to the user for approval before executing it. If a user approves that WebFetch call and the target is reachable (say, a router admin page), claude will fetch it. The same applies to:

• Internal wikis and documentation servers
• Development servers running on localhost
• Cloud metadata endpoints (http://169.254.169.254/... on cloud VMs)
• Internal APIs and admin interfaces

This isn’t a vulnerability in Claude Code. This is the expected behavior of a local fetch tool. The per-call approval prompt is a first layer of defense: you see the target URL before the request fires… but approval prompts are easy to click through, especially during long sessions. If you configure auto-approve policies, you’ll bypass them entirely. Network-level controls provide defense-in-depth beyond the approval model.

Internet-accessible vs. LAN-only targets

Understanding this distinction is critical:

Internet-accessible site (e.g., https://example.com):

Your machine ──── Internet ──── example.com
     │
     └── claude's WebFetch goes this way
         Target sees YOUR public IP

LAN-only service (e.g., http://192.168.1.100:8080):

Your machine ──── LAN ──── internal-server:8080
     │
     └── claude's WebFetch goes this way too
         No internet traversal needed
         Internal server sees your LAN IP

This distinction matters because Anthropic’s infrastructure can’t reach your LAN. If WebFetch were server-side, internal services would be safe by network topology. But because WebFetch is local, it can access anything your host is approved to access.

Using namespaces for defense, not just observation

You can use claude-sandbox.sh

Earlier we used network namespaces to observe Claude’s traffic. The same technique can also block Claude from reaching internal services while still allowing it to access the internet APIs it needs to function. This can turn the observation tool into a security control.

The same namespace technique from the isolation section can restrict claude’s network access:

# After creating the namespace, add restrictive iptables rules INSIDE it:
sudo ip netns exec claudesbx iptables -A OUTPUT -d 10.0.0.0/8 -j DROP      # Block RFC1918
sudo ip netns exec claudesbx iptables -A OUTPUT -d 172.16.0.0/12 -j DROP   # Block RFC1918
sudo ip netns exec claudesbx iptables -A OUTPUT -d 192.168.0.0/16 -j DROP  # Block RFC1918
sudo ip netns exec claudesbx iptables -A OUTPUT -d 169.254.0.0/16 -j DROP  # Block link-local

Now claude has internet access (via NAT) but cannot reach any internal/LAN address. You get both isolation for observation and restriction for defense.

Defense-in-depth considerations

For production use of AI agents with network tools:

1. Network namespace isolation: Run the agent in a namespace with controlled egress. Capture and audit all traffic.
2. Egress filtering: Allowlist specific destinations rather than blocklisting RFC1918 ranges. If the agent only needs to reach specific APIs, restrict it to those.
3. DNS-based control: Use a controlled DNS resolver in the namespace that only resolves permitted domains.
4. Proxy-based inspection: Route all agent traffic through a forward proxy with URL allowlisting. This gives you both filtering and a complete audit log.
5. Credential scoping: The API key used by the agent should have minimal permissions. If your Anthropic key is stolen (e.g., from a decrypted capture), the blast radius should be limited.

That covers it. You now have sufficient skill to be able to wrap a binary in a private namespace, implement packet inspection & MITM teardown of TLS Sessions for claude so you can observe it’s requests out to claude API endpoints and any assets on the internet for scraping. We covered a ton of ground. Circle back to part 1 or head over to the github repository for this project.