What is prompt injection? A plain guide for people who run AI agents
Text your agent reads can carry instructions it will follow, and no model reliably tells data from commands. Direct vs indirect injection, the lethal trifecta, and the defenses that actually hold.
Prompt injection is when text an AI reads (a message, a web page, an email) carries instructions the AI then follows as if they came from you. Models have no reliable way to tell data from commands: under the hood there is only “next token.” For a chatbot that means embarrassing output. For an agent with a shell, a browser, and your inbox, it means an attacker who can get text in front of your agent can try to act as your agent. It sits at #1 in OWASP’s Top 10 for LLM applications, and nobody claims a full fix exists: not OWASP, not NIST, not the model vendors. The workable defense is architecture: limit what the agent can do, not what it’s told.
Why this isn’t just SQL injection again
The name was coined by Simon Willison in September 2022 (“the obvious parallel here is SQL injection”), building on attack demonstrations by Riley Goodside. But the parallel breaks in the way that matters: SQL injection has a complete fix: parameterized queries separate code from data. A language model has no such separation to enforce. The UK NCSC put it plainly in a December 2025 advisory: under the hood “there’s no distinction made between ‘data’ or ‘instructions’; there is only ever ‘next token’”, and prompt injection “may never be totally mitigated in the way that SQL injection attacks can be.” NIST’s 2025 adversarial-ML taxonomy says the quiet part too: design systems on “the assumption that prompt injection attacks are possible if a model is exposed to untrusted input sources.”
Direct vs indirect, and why indirect is the one operators lose sleep over
Direct injection is the user themselves steering the model against its instructions (“ignore your system prompt and…”). If you run a personal agent that only you can message, direct injection is mostly a you-problem. Indirect injection is the sharp one: instructions hidden in content the agent reads while working: a web page it fetches, a README in a repo, an email it summarizes, a PDF attachment, a pasted log. OpenClaw’s own security docs state the operator’s reality exactly: “even if only you can message the bot, any untrusted content it reads (web search/fetch results, browser pages, emails, docs, attachments, pasted logs/code) can carry adversarial instructions.” NIST’s taxonomy even sketches the worm case: a malicious email that instructs the agent reading it to forward itself to every contact.
The lethal trifecta
Willison’s 2025 framing of when injection becomes an actual breach is the cleanest threat model an agent operator can carry around. Three capabilities: access to your private data, exposure to untrusted content, and the ability to communicate externally. Any two are survivable. All three together mean an attacker can trick the agent into reading your secrets and sending them out: “LLMs are unable to reliably distinguish the importance of instructions based on where they came from.” Most useful personal agents want all three, which is why the answer is rarely “remove a leg” and usually “put boundaries around each one.”
What actually helps
Every serious source lands on the same shape: assume the model can be fooled, and make the system around it refuse to amplify the mistake. Concretely, in rough order of value for a personal-agent setup:
- Least privilege, enforced outside the model. Scoped API tokens, single-repo deploy keys, per-purpose accounts. NCSC’s framing: when an agent processes content from a party, its effective privileges should drop to that party’s. Deterministic controls (allowlists, tool policy, approvals) bind where system-prompt rules don’t.
- Human approval on high-risk actions. OWASP lists it as a first-class mitigation, not a cop-out. Money, deletion, and outbound email deserve a confirmation tap.
- Isolation. Run the agent where a bad day is containable: a sandbox for risky tool calls, and a machine that isn’t your laptop, so “the agent got fooled” never equals “my browser sessions, password manager, and tax folder were in reach.”
- Don’t run tool-wielding agents on weak models. OpenClaw’s docs are blunt: injection resistance is not uniform across model tiers, and for agents that read untrusted content the risk with older or smaller models “is often too high.”
- Logs you actually keep. Injection that half-works looks like weird agent behavior; a transcript is how you find out which page did it.
Vendor progress is real but partial: Anthropic’s published red-team numbers for its browser agent went from a 23.6% attack success rate to 11.2% with mitigations, which is both a big improvement and very far from zero. Treat guardrail products claiming “95% of attacks blocked” accordingly: in security, 95% is a failing grade.
If you run OpenClaw
The controls above have concrete names: pairing and allowlists keep strangers from messaging the agent at all, mention-gating tames group rooms, and the three enforcement layers (tool policy, exec approvals, and the Docker sandbox) decide what a fooled agent can actually touch. The working posture: you can’t make your agent un-foolable, so decide in advance what a fooled agent is allowed to do, and where it’s allowed to be when it happens.