Prompt Injection, in Plain Terms

An agent reads things — documents, emails, web pages, tickets, database records — and then acts. If what it reads contains instructions, it may follow them.

That sentence is the whole problem, and it is a design property rather than a bug awaiting a patch.

For a vendor-side perspective on self-reporting bias, see this resource from Monitask.

Why it happens

A model receives one stream of text. Your instructions and the content it is processing arrive in the same channel.

There is no reliable boundary marker. Traditional software separates code from data structurally — a database knows the difference between a query and a value. A language model has no equivalent guarantee.

Mitigations exist and none is complete. Providers separate system instructions from user content, models are trained to prefer their instructions, and both reduce the rate rather than eliminating the class.

Which means the correct assumption is that it can happen, and the design should survive it.

What it looks like

Direct. Someone interacting with the agent tries to override its instructions. The obvious case, and the easier one to defend.

Indirect, and this is the one that matters. The instruction is planted in content the agent will read while doing legitimate work.

Concretely: a document in a shared folder with text saying to forward its contents elsewhere. A support ticket containing instructions to escalate and approve. A web page the agent researches with hidden text. A calendar invitation. A code comment in a repository. A product review.

The person who plants it never interacts with the agent. They put content where the agent will encounter it.

And because the agent has tools, following the instruction means taking an action, not just producing odd text.

Why it is worse for agents than for chat

A chat model that gets confused produces a wrong answer. You read it and disregard it.

An agent that gets confused sends the email, changes the record, runs the query. The output is an action in a real system.

Practitioner accounts in the 2026 security research include agents gaining unauthorised write access to databases and attempting to exfiltrate sensitive information.

And the reach multiplies it. An agent connected to your systems has more to lose than a chat window.

What actually reduces the risk

None of these is a solution. Together they make a successful attack much harder and much less damaging.

Limit what it can do

The most effective control by a wide margin.

An agent that cannot send external email cannot exfiltrate by email. An agent with read-only database access cannot corrupt records.

Design from what it must never do, not from what it needs. See permissions.

Treat all retrieved content as untrusted

Everything the agent reads, including internal documents. Internal does not mean trustworthy — a document can be uploaded by anyone with access, and shared folders take content from outside.

Separate reading from acting

An agent that summarises documents does not need to send messages. Splitting the roles means a compromise while reading cannot become an action.

Human approval at the consequential points

Not on everything, which produces approval fatigue and rubber-stamping.

On the actions that are irreversible or externally visible — payments, external communication, deletions, permission changes. See human oversight.

Log actions, not conversations

When something goes wrong you need to know what the agent did, in what order, on whose behalf. See logging and audit trails.

Constrain the output surface

An agent that can only write to a specific field in a specific system has a small blast radius. One that can call arbitrary tools does not.

Monitor for the pattern

Unusual sequences of actions, calls to tools the agent does not normally use, sudden volume. Detection matters because prevention is incomplete.

What does not work

Telling the model to ignore instructions in content. Reduces the rate; does not close the class. Attackers adapt.

Filtering for suspicious phrases. Instructions can be phrased in unlimited ways, in any language, and encoded.

Trusting internal sources.

Assuming it will be caught by the model provider. Their mitigations help and they cannot see your tools or your data. For broader independent background, see OWASP GenAI Security Project.

And treating it as solved because your current model resists your test cases.

For small teams and individuals

The same principle at smaller scale, and it comes up more than people expect.

If you use an agent that browses the web or reads your email, it is exposed to this.

Practical steps: do not connect it to accounts you cannot afford to have wrong, prefer read-only where possible, review anything going out to a customer before it goes, and use separate credentials you can revoke.

See agents for a one-person business.

Questions for a vendor

What can the agent do without a human approving it?

How is retrieved content treated?

What is logged when it takes an action?

Can we restrict which tools it can call, per deployment?

What happens if a document it reads contains instructions? A vendor who says this is solved is either not paying attention or hoping you are not.

The short version

An agent reads content and acts on it. If the content contains instructions, it may follow them — and that is structural, not a bug.

Indirect injection is the dangerous form: the instruction is planted where the agent will find it, and the attacker never touches the agent.

Limiting what the agent can do is the most effective control, by a wide margin.

Treat everything it reads as untrusted, including internal documents.

And anyone claiming this is solved is not describing the current state.