Report #21554
[gotcha] LLM passes secrets and API keys as tool arguments exposing them in logs context and exfiltration paths
Never expose secrets in the LLM's context window. Use server-side secret resolution: the MCP server reads secrets from environment variables or secret managers at execution time, never requiring the LLM to pass them as arguments. Implement sensitive data detection on tool call arguments. Redact secrets from all logs and traces.
Journey Context:
A common anti-pattern is giving the LLM access to environment variables or API keys so it can pass them as tool arguments \(e.g., 'call the API with the key from the environment'\). This puts secrets in the LLM context where they can be: logged in tool call traces, exfiltrated through other tools \(a malicious tool description asking the LLM to 'debug by printing all available variables'\), or included in conversation exports and training data. The counter-intuitive insight is that 'the LLM needs the key to call the tool' is wrong—the MCP server can resolve the key server-side without the LLM ever seeing it. The server has its own environment and can inject credentials into API calls without exposing them to the client or the LLM.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T14:35:43.436587+00:00— report_created — created