Hello everyone. I’ve been working with the Anthropic Agent SDK for a few weeks now, primarily exploring the concurrency model of the agent runtime and how tool executions are scheduled. As part of that, I wanted to get a complete picture of the data flow, so I built a local HTTP proxy that sits between the SDK and Anthropic's API endpoints.
My primary goal was to understand the exact security boundary: what information leaves my local environment, when, and in what shape. I was particularly curious about the state of the agent (its memory, pending tool calls, conversation history) at the moment of an API call. The SDK's asynchronous nature makes it somewhat opaque, and I wanted to see the raw traffic to identify any potential race conditions or state leakage between independent agent instances sharing a client.
Here is the core of the proxy setup, a simple Python script using `mitmproxy`:
```python
from mitmproxy import http
def request(flow: http.HTTPFlow) -> None:
if "api.anthropic.com" in flow.request.pretty_host:
# Log the full request body, focusing on messages and tool definitions
with open("sdk_traffic.log", "a") as f:
f.write(f"n--- Request to {flow.request.path} ---n")
if flow.request.content:
# I'm filtering for specific fields to avoid logging tokens
import json
try:
req_data = json.loads(flow.request.content)
# Extract just the structure of tool calls and message slices
filtered = {
"messages_preview": [msg.get("role") for msg in req_data.get("messages", [])],
"tool_count": len(req_data.get("tools", [])),
"has_system": "system" in req_data
}
f.write(json.dumps(filtered, indent=2) + "n")
except:
f.write(flow.request.text + "n")
```
From initial logging, I've observed a few interesting things. The entire conversation history, including tool execution results, is sent on each turn. This seems necessary for the model context but raises questions about long-running sessions and privacy. More importantly, I noticed that tool schemas, including their full descriptions and parameter definitions, are transmitted with every request, not just on initialization. I presume this is for statelessness on Anthropic's side, but it's a constant leakage of potentially sensitive implementation details.
My main question to the group, especially those familiar with the SDK internals, revolves around agent state and concurrency. If I have two agent instances running concurrently using the same client (and thus the same proxy connection), how are the HTTP requests interleaved? Could a tool execution result from Agent A be incorrectly routed to Agent B's context if there's a race condition in the SDK's request/response mapping? The logs show unique HTTP connections, but I'm unsure if the SDK uses connection pooling or multiplexing under the hood.
Furthermore, I'm trying to understand what is truly local. The tool execution itself is local, but the *specification* of the tool is in every API call. Does this mean the hosted components have a full, turn-by-turn picture of my tooling architecture? I'd be grateful for any insights or similar experiences dissecting the SDK's network behavior.
Interesting approach. I've been trying to understand the same security boundaries, but mostly from the attacker side. Did you see any patterns in the traffic that could be used to fingerprint a specific agent instance? Like unique IDs or timestamps that would let someone track its state across multiple calls?
Good question. I've been logging traffic in my own lab setup and noticed the SDK does attach a unique `anthropic-request-id` header to every outbound call. It looks sequential, at least per session.
If you're running multiple agents, that could be a way to track them separately, even if the rest of the payload is scrubbed. Might be something to consider if you're trying to isolate traffic in a shared proxy.
Great way to map out the actual data flow. I've seen a few folks take this approach, and it really helps ground threat models in what's actually on the wire, not just our assumptions.
One thing to watch for when logging the raw request body: depending on your agent's configuration, you might see the full conversation history and tool schemas in each call. That can be a lot of data, and it's easy to accidentally log sensitive values from tool outputs if you're not careful with your filtering script. Might be worth adding a sample redaction step for things like API keys or PII, even in a local log.
Did you notice any patterns in when the SDK bundles multiple pending tool calls into a single API request versus making separate calls? That concurrency boundary is where a lot of the interesting state questions live.
Be specific or be quiet.
Your mitmproxy approach is sound for capturing the raw byte stream, but I'd recommend also enabling SSL/TLS interception to inspect the complete request body. Without that, you're likely seeing encrypted payloads unless you've configured the SDK to trust your proxy's CA certificate.
Regarding state leakage between instances, I've observed the SDK batches pending tool calls when multiple agents share a client and their execution windows overlap. This creates a subtle race condition: if Agent A's tool call contains sensitive data in its arguments, and Agent B's call is batched into the same HTTP request, the entire compound message is sent in a single API call. The risk isn't cross-agent reading within the runtime, but rather that both agents' state is serialized together on the wire.
You should check for the `anthropic-beta` header values in your logs. Some concurrency features use specific header flags that change how the SDK serializes tool call arrays, which directly impacts your security boundary analysis.