**Prompt injection** is when an attacker slips instructions into text the model reads, hoping the model follows them instead of the real user. In a chat only LLM, the worst outcome is usually a bad answer on screen. The model talks, but it cannot do anything in the outside world.
An agent is different because it has tools. It can call a function to delete a file, send an email, query a database, or make a payment. So a successful injection in an agent does not just change what the model says. It can change what the model does.
The key idea is blast radius, the most damage a single attack can cause. A chatbot's blast radius is one wrong reply. An agent's blast radius is every action its tools allow, scaled by how much access you gave it.
The scariest version is indirect injection. The malicious instruction is not typed by the user. It is hidden in a web page, a document, or an email the agent reads as part of its job. The agent fetches that content, treats the hidden text as a command, and acts on it. Nobody told it to, and the user may never see what happened.
In a chat only LLM, a successful **prompt injection** changes what the model writes. The harm is bounded by text. In an agent, the same trick can trigger real tool calls, so the model can act on the injected instruction.
The right mental model is blast radius. A chatbot's worst case is one misleading reply. An agent that holds a delete tool, an email tool, or a payment tool can be steered into deleting files, leaking data, or moving money. The damage scales directly with the permissions you granted.
The headline agent risk is indirect injection. The attacker does not type anything. They plant instructions inside content the agent will read, such as a web page, a PDF, a calendar invite, or a returned API payload. The agent ingests that untrusted text and cannot reliably tell data from commands.
The core defence is treating all tool output and fetched content as untrusted data, never as instructions. You pair that with least privilege on tools, human approval for irreversible actions, and sandboxing so a hijacked agent has little reach. Filtering helps, but it is not a primary control, because no classifier reliably separates trusted intent from injected text.
Quick reference
TL;DR
In a chat LLM, injection only changes what the model says. In an agent, it can trigger real tool calls, so the blast radius scales with the agent's permissions.
Imagine you hire an assistant who reads every letter that arrives and tends to do whatever the most recent instruction says. With a chat only assistant, the worst a forged letter can do is make the assistant say something silly back to you. But now imagine the assistant also holds the keys to your house, your bank app, and your email. If a forged letter slips in an instruction like "wire the money and unlock the door," the assistant might just do it, because it cannot tell your real wishes from text someone hid in the mail. The danger is not really that the assistant got tricked. The danger is what the assistant is allowed to touch once it is tricked. An agent reads untrusted pages and documents, and it can act, so a hidden instruction becomes a real action.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Relying on a single prompt injection classifier as the only line of defence for a high privilege agent. No classifier reliably separates trusted intent from injected text, so a filter only design will eventually be bypassed.
Granting an agent broad write or payment scopes when the task only needs read access. Over-provisioning permissions widens the blast radius for no functional benefit and turns a minor injection into a major incident.
Auto-approving every tool call to reduce user friction in a consumer product. Removing the human gate on irreversible actions lets an indirect injection act before anyone can intervene.
Letting an agent read fully untrusted open web content while holding live production credentials. Mixing untrusted input with high trust capabilities is the exact condition indirect injection exploits.
Quick scan · 2–4 min
Everything important, quickly.
Start by separating susceptibility from consequence, then define blast radius and tie it to tool permissions. Explain indirect injection as the headline agent risk and why the model cannot separate instructions from ingested data. Close with the systemic defences: treat tool output as data, least privilege, human approval, sandboxing, and tracing.
Real-world examples
Real products, models, and research that use this idea.
1Anthropic's computer use and Claude Code gate sensitive actions behind explicit approval, because a hijacked desktop or shell agent could otherwise run destructive commands from injected screen or file content.
2OWASP lists prompt injection as the number one risk in its LLM Top 10, and recent guidance stresses indirect injection through retrieved or browsed content as the headline agent threat.
3Browser and research agents like OpenAI Operator and Perplexity research mode read untrusted live web pages, the exact channel where indirect injection payloads are planted.
4Code execution sandboxes such as e2b microVMs and Modal containers isolate agent generated code, limiting blast radius when an injected instruction tries to run a malicious script.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you architect an agent so that reading an untrusted web page cannot trigger a destructive tool call?
Sign in or go Pro to see the approach for this follow-up.
QWhy can't you solve prompt injection purely with a better guardrail or classifier model?
Sign in or go Pro to see the approach for this follow-up.
QWhat signals would you trace and alert on to detect a hijacked agent in production?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating prompt injection as a content moderation problem rather than a privilege problem. The model cannot reliably separate trusted instructions from untrusted data, so defence lives in tool permissions and approval gates, not in a better filter.