Prompt Injection Is Not a Hypothetical: Guardrails for AI Agents That Have Tools
An agent with email, shell or payment access can be talked into doing the wrong thing by text inside a document. Here is the setup I actually use.
The demo everyone knows: an agent reads a web page that contains hidden instructions, and the agent starts following them instead of yours. It reads like a security conference talk, but the version I hit in practice was much duller - a shared document with a line of white text, and an agent that dutifully forwarded the contents to an address it should never have contacted.
The uncomfortable part is that no amount of careful prompting fixes this. If your agent reads text written by someone else, that text is input, and a model cannot reliably tell instructions from data. Telling the model to ignore instructions inside documents sounds like a fix; it is a suggestion, and suggestions lose to prompts that look like the real task.
So the guardrails have to live outside the model. Three things I insist on now: the agent gets the narrowest possible tool access, every consequential action needs a step that a human can interrupt, and there is a log that records what the agent did in plain language I can read later. The permission set is the actual security boundary; the prompt is a suggestion to the agent, not to the attacker.
Concretely: a tool that can send email should only be able to send to addresses already on the account, and only after a human confirms the recipient list. A tool that can run shell commands should run in a sandbox with no credentials, because the moment your agent has your production keys, the attacker does too. Read-only is the best default, and write access is the thing you earn rather than grant.
The other half is treating data as data. Anything the agent reads from outside your organization - web pages, incoming email, shared docs, even PDFs from customers - gets treated as untrusted input, the same way you would treat a stranger's email asking you to forward the contract. The agent should summarize it, quote it, and pass it to you - never obey it.
None of this makes agents safe in the abstract. It makes them safe enough to let loose on a task where the worst outcome is a wasted run instead of a wire transfer. I now start every automation with that sentence, because if the worst case is unacceptable, the tool choice is not the problem you should be solving.
Frequently asked questions:
Q: Can prompt injection be fixed with a better prompt?
A: No. It can be reduced, but not eliminated, because the model cannot reliably separate instructions from content it was asked to read. The reliable fix is limiting what the agent can do, not asking it to be careful.
Q: What is the single most important guardrail to add first?
A: Remove write access to anything outside the task. Most agent incidents become harmless the moment the agent cannot send, delete or spend without a human confirming. Read-only agents fail safe by default.
Q: Do I need this if I only use agents on my own files?
A: The risk is in anything the agent reads, not only what it writes. A document from a colleague or a customer can contain the same instructions, and your agent treats them the same way it treats your notes.