MCP transport: outbound request-signing hook is a no-op (current_operation ContextVar not propagated to the task that sends the request)

[KonstantinMirin]

Summary

On adcp==6.6.0, ADCPClient/ADCPMultiAgentClient constructed with signing=SigningConfig(...) never actually sign outbound requests over the MCP transport, even though the signing hook fires and no error is raised. Reproduced end-to-end against a local FastMCP server with a header spy: the signing hook fired on every call, current_operation read None every time, no get_adcp_capabilities fetch occurred, and no Signature header was ever sent on the wire.

Root cause

adcp/protocols/mcp.py:560 sets the current_operation ContextVar in the caller's asyncio task, wrapped around the session.call_tool(...) invocation.

mcp/client/streamable_http.py:566 (the mcp package's own transport) dispatches the actual signed POST via tg.start_soon(handle_request_async) from post_writer's task. Since contextvars.Context is captured at task-spawn time (i.e., when post_writer's task group started, at connect time) and NOT inherited live from the calling task at request time, the spawned task's copy of current_operation is whatever it was when the connection was established — effectively always None for the first (and typically only) request.

ADCPClient._sign_outgoing_request (adcp/client.py:972) reads current_operation from the ContextVar, sees None, and returns early without signing — silently, no exception, no log.

The SSE transport branch (adcp/protocols/mcp.py:383-388) is aware of this class of problem and explicitly warns-and-skips rather than attempting to sign. The streamable-HTTP transport (the default) has no such guard and just silently no-ops.

Note: the A2A transport is unaffected — its signing hook runs in the caller's own task (adcp/protocols/a2a.py:262), so current_operation propagates correctly there. This appears to be specific to how the mcp package's streamable-HTTP client schedules its send.

Suggested fix direction

Capture the operation at message-send time (inside the task that actually performs session.call_tool/the HTTP POST) rather than via a ContextVar set in a different task, OR thread the operation through ClientMessageMetadata (or an equivalent explicit parameter) rather than relying on ambient context propagated across an anyio task-group boundary.

Impact

Any caller relying on ADCPClient(signing=...) over MCP transport gets zero signing with no error surfaced — a silent security gap for anyone who believes they've turned on RFC 9421 request signing for MCP-transport outbound calls.

Repro sketch

• Stand up a minimal FastMCP server that echoes the received headers.
• Construct ADCPClient(agent_url=..., protocol="mcp", signing=SigningConfig(...)).
• Call any tool via the client 5 times.
• Observe: signing hook invoked 5/5 times, current_operation is None on all 5, zero Signature header on the wire, zero get_adcp_capabilities fetch (which _sign_outgoing_request would trigger if it proceeded past the operation is None check).

Happy to share the exact repro script if useful — surfaced this while implementing outbound request signing for a downstream seller agent (prebid/salesagent, RFC 9421 adoption epic).

[bokelley]

Triage

Classification: Bug
Bucket(s): signing, client
Status: ready-for-human

What the experts said:

• security-reviewer: Sev-1 ship-blocker; real attack surfaces include MITM payload tampering (RFC 9421 Content-Digest is never bound), impersonation (bearer token is the only gate when signing no-ops), and replay of required_for operations; recommends parsing the MCP JSON-RPC request body in the signing hook as the concurrent-safe fix — each POST carries exactly one call's payload so no shared state is needed
• ad-tech-protocol-expert: per-adapter mutable cell approach has a genuine TOCTOU race — post_writer can dequeue a message after the caller has already overwritten the cell with the next call's operation name; copy_context() at enqueue time or body-parsing in the hook are the sound approaches; client should raise a typed SigningUnavailableError rather than silently skip when the seller's policy decision would be "required"
• code-reviewer: any mutable-cell fix also requires pre-fetching capabilities before session.call_tool — otherwise the hook's fetch_capabilities() call writes to write_stream while post_writer is blocked waiting for the hook to return (deadlock); existing test_autosign_mcp.py mocks call_tool in the caller's task and therefore cannot catch this class of bug

My take: Any caller relying on signing=SigningConfig(...) over MCP/streamable-HTTP has had zero RFC 9421 signing since this transport was introduced — silently, no error, no log. Flagging for @bokelley because the fix touches the RFC 9421 signing critical path and the right approach (body-parse vs. copy_context()) requires an expert familiar with how the mcp SDK's post_writer task interacts with httpx event hooks.

Implementation scope:

• src/adcp/client.py — _sign_outgoing_request: obtain operation name without the ContextVar; recommended path: json.loads(request.content)["params"]["name"] (MCP JSON-RPC body), which is concurrent-safe and requires no shared mutable state
• Match SSE transport's warn-and-skip pattern at minimum, then fix properly
• Required: wire-level integration test with a real StreamableHTTPTransport + ASGI header spy asserting Signature and Signature-Input headers appear on the wire; existing mocked tests do not prove this
• Non-breaking patch bump (signing was silently broken; making it work changes no public API)

Label gaps: signing and client bucket labels are not in the repo label list — applying bug only.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_019972UkMg9rEbuaVqWBqpWQ

---

Generated by Claude Code