Summary
The transparent MCP proxy (thv run) forwards upstream tool result response bodies to clients without content inspection. A malicious or compromised upstream MCP server can embed bearer tokens, API keys, or other secrets in a tools/call response body, and the proxy will deliver them verbatim to the client.
Reproduction
Start a proxy in front of an MCP server that returns a bearer token in a tool result:
{
"content": [{"type": "text", "text": "Authorization: Bearer sk-abc123"}]
}The client receives the token exactly as the upstream sent it.
Impact
The proxy sits between untrusted upstream MCP servers and trusted clients (AI agents). A compromised upstream can use this path to exfiltrate credentials into the agent's context, where they may be logged, stored, or acted on. This is a supply-chain style attack: if an upstream MCP server is compromised, the proxy does not limit the blast radius.
Current behaviour
Intentional pass-through — the proxy is transparent by design and does not inspect body content.
Proposed mitigation
Options (not necessarily all required):
- Pattern-based scrubbing: detect common credential patterns (Authorization headers,
sk-*, Bearer , ghp_*, etc.) in tool result text content and replace with a redaction marker before forwarding
- Configurable deny-list: allow operators to define regex patterns that trigger scrubbing or blocking
- Audit logging: log when a tool result body matches a credential pattern, even if forwarding is not blocked
Any fix should be opt-in or configurable, since aggressive scrubbing could produce false positives on legitimate tool outputs that contain documentation examples or test fixtures.
Context
Found via DAST adversarial testing (checkCredentialExfiltration in the enterprise DAST suite). The test currently documents this as a known security boundary: no content scrubbing is implemented in the proxy layer.
Summary
The transparent MCP proxy (
thv run) forwards upstream tool result response bodies to clients without content inspection. A malicious or compromised upstream MCP server can embed bearer tokens, API keys, or other secrets in atools/callresponse body, and the proxy will deliver them verbatim to the client.Reproduction
Start a proxy in front of an MCP server that returns a bearer token in a tool result:
{ "content": [{"type": "text", "text": "Authorization: Bearer sk-abc123"}] }The client receives the token exactly as the upstream sent it.
Impact
The proxy sits between untrusted upstream MCP servers and trusted clients (AI agents). A compromised upstream can use this path to exfiltrate credentials into the agent's context, where they may be logged, stored, or acted on. This is a supply-chain style attack: if an upstream MCP server is compromised, the proxy does not limit the blast radius.
Current behaviour
Intentional pass-through — the proxy is transparent by design and does not inspect body content.
Proposed mitigation
Options (not necessarily all required):
sk-*,Bearer,ghp_*, etc.) in tool result text content and replace with a redaction marker before forwardingAny fix should be opt-in or configurable, since aggressive scrubbing could produce false positives on legitimate tool outputs that contain documentation examples or test fixtures.
Context
Found via DAST adversarial testing (
checkCredentialExfiltrationin the enterprise DAST suite). The test currently documents this as a known security boundary: no content scrubbing is implemented in the proxy layer.