The situation. As teams move from chat interfaces to agents that read email, browse pages, and call tools, prompt injection has quietly changed category. It used to be a curiosity — a way to make a chatbot say something off-script. In a system that can take actions, it’s the thing standing between “the model read a hostile web page” and “the model used my tools on the attacker’s behalf.” It is not a bug you patch. It’s a property of how these systems work, and it belongs in your design, not your backlog.
What we’re seeing.
- The boundary moved, and most designs haven’t caught up. For a decade, the security boundary was the user. With a tool-using model, any text the model reads — a document, a search result, a webhook payload — can carry instructions it may follow. The untrusted input is no longer just what the user types. It’s everything the model ingests.
- “Better prompting” is not a control. System prompts that say “ignore malicious instructions” reduce the rate; they don’t close the hole. Treating a probabilistic instruction-follower as if it will reliably refuse is wishful thinking dressed as mitigation. If the only thing between a hostile document and a real action is a strongly worded system prompt, there is effectively no control there.
- The real controls are old ones. The mitigations that hold aren’t AI-specific. Scope the tools the model can reach. Require a human confirmation for actions that move money, change permissions, or send data outward. Keep the model’s privileges no higher than the least-trusted input in its context. This is least privilege and the confused-deputy problem, wearing new clothes.
- Autonomy is the dial that sets the risk. The exposure isn’t “we use a model.” It’s “we let the model act without a checkpoint.” Every step you let it take unsupervised is a step an injected instruction can take too. The question isn’t whether the model is clever enough to resist — it’s what you were willing to let it do without asking.
What it means for you. Decide, per action, what you’re comfortable letting the model do on the say-so of text it didn’t get from you. Draw the line at effect, not intent: reads with narrow scope can run free; anything that writes, spends, or sends gets a gate. Design as if the model will occasionally follow the wrong instruction — because on a long enough timeline, it will — and make sure that when it does, the blast radius is something you chose in advance rather than something you discover in an incident.


Leave a Reply