Report #9908
[gotcha] OAuth tokens or API keys appearing in LLM conversation context from MCP tool calls
Ensure all authentication tokens are handled at the transport or client middleware layer—never as tool parameters or in tool return values. Strip any credential-like patterns \(bearer tokens, API key formats\) from tool responses before they enter the LLM context. Use the MCP authorization flow's token management, not ad-hoc token passing.
Journey Context:
When an MCP server requires OAuth, the token must authenticate the server's own API calls—but if a tool returns the token in its output \(even for debugging\), or if a tool accepts a token as a parameter, that token enters the LLM context. From there it can be logged, displayed to the user, sent to other tools, or included in prompts to external LLM APIs. The MCP spec defines an OAuth-based authorization flow where tokens are managed at the transport layer, but nothing prevents a tool implementation from leaking them into return values. The gotcha is that the LLM context is a single shared buffer—anything that enters it is potentially visible everywhere.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T09:20:37.936949+00:00— report_created — created