The hidden cost of prompt injection: it's the spend, not the prompt
Prompt injection isn't just a data-safety problem — it's a money problem. The documented attacks that ended in spend, and the deterministic defense that can't be injected.
Most writing about prompt injection focuses on data exfiltration and model behavior. The angle that gets less attention is the one that actually shows up on invoices: injection as a spending attack. An injected instruction in tool output can push an agent to purchase, subscribe, or pay — and the agent will do it, because that's what it's built to do.
The documented shapes
The incident database records the patterns: agents that followed instructions embedded in content and spent against an operator's intent — purchases from unknown vendors, subscription triggers, payment-rail activity. The common thread isn't model quality; it's that nothing sat between the agent and the money.
Why detection isn't the answer
Injection detection is probabilistic — a bypass is always possible. Even a detected injection still needs something to stop the money from moving. The reliable defense is a deterministic gate on the spend path: rules that can't be injected. An injected instruction can't add a merchant to the allowlist or raise a cap — approvals come from rules, not from model output.
The layered answer
Keep detection tools for the content layer. Add the firewall for the money layer. Defense in depth: detect the attack, and make the damage impossible regardless.