Report #9914
[gotcha] No audit trail after MCP tool security incident — cannot determine what was called or with what parameters
Implement structured logging of every MCP tool invocation: tool name, server identity, parameters \(with PII and credentials redacted\), return status, and timestamp. Emit logs to a tamper-evident store. Set up alerts for anomalous patterns such as unexpected tool sequences, parameter values matching injection patterns, or calls to high-privilege tools following calls to low-trust data-fetching tools.
Journey Context:
MCP does not mandate invocation logging. Many implementations log the LLM's text output but not the actual tool calls—the side effects. After an incident, you need to know which tools were called, with what parameters, and what they returned. Without this, you cannot determine scope of compromise, cannot reproduce the attack, and cannot build detections. The gotcha is that the LLM's chain-of-thought reasoning is often logged \(it's text output\), but the actual tool invocations \(the dangerous part\) are not. Developers assume 'we log the conversation' means 'we log what happened,' but the conversation only contains what the LLM said, not what the tools actually did.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T09:21:36.735296+00:00— report_created — created