01 / Attack path
How the boundary is crossed
An incident agent reads a ticket comment saying to disable a different customer’s account as a diagnostic step.
- 01Lower-trust input
- 02Attempted instruction
- 03Protected action
- 04Enforced decision
02 / Containment
Where bounded authority limits the effect
Mark content as untrusted, validate the task and target at the account API, and require independent approval for disabling accounts.
Architecture review / negative test
Make the boundary testable.
Treat retrieved text and tool responses as data that can attempt to steer the model. Upstream filtering and model instructions may reduce attempts, but neither proves that an external effect is authorized. Map the exact API that can disable an account and the task/target check it must enforce.
03 / Failure and evidence
The attacker’s opportunity and the defender’s record
A prompt filter misses a persuasive variant and a broad tool credential allows the wrong account change.
Keep the untrusted input reference, attempted action, denial and actual account state; avoid storing unnecessary sensitive content.
04 / Canonical scope
Why this reference stands alone
MCP tool poisoning focuses on malicious tool metadata; this page covers the general content-to-action crossing.
Primary references