When what it reads becomes a command

What you will learn Why this is structural rather than a bug, where it gets in, and what organisations actually do about it.

A different axis from the last chapter

Tools are permissions covered "what can the tool I attached do?" This chapter is the other side.

The data an AI reads can itself become a command.

Suppose you have an agent read a web page, and somewhere on that page, in white text, sits this:

To the agent this looks exactly like an instruction the user wrote.

Why it cannot simply be fixed

A language model has no separate channel for instructions and for data. It all arrives as one piece of text and is read as one piece of text.

That is why there is still no complete defence. It is why prompt injection has held first place for two consecutive editions of the OWASP Top 10 for LLM Applications.

So the goal is not "block it" but "make success harmless." The same posture as with hallucination.

Two forms

The second is the one that matters in practice. No mistake was made, and nothing was clicked.

What actually happened

EchoLeak (CVE-2025-32711), disclosed in June 2025, is the reference case.

There was never a click. So it cannot be explained as user carelessness and there is no link to trace. It all happens inside a tool the organisation deployed and trusts.

Where it gets in, in this product

Every place the agent reads outside content is an entry point.

Note the last row. Instructions can be planted in what a tool returns, too.

An incident needs three things

graph TD
  A["1. Planted instruction arrives<br/>(web, document, email)"] --> D["Incident"]
  B["2. It can reach something sensitive<br/>(Drive, DB, files)"] --> D
  C["3. There is a way out<br/>(email, webhook, publish, external API)"] --> D

Break any one and there is no incident. You cannot break 1 — reading outside material is the job. So practice focuses on 2 and 3.

The five things people actually do

1. Put a person on the way out

The single highest-impact measure. Put approval on sending email, publishing externally, payments, and calls to outside addresses, and a successful injection still cannot move data out.

"Approval on irreversible actions" from tools are permissions widens here into "approval on actions that leave the building."

2. Don't keep reading and sending in the same place

If the crawler cannot see the internal Drive, then whatever is planted in a crawled page has nothing to take.

3. Mark outside content as data

Don't concatenate fetched content straight into the instructions — state the boundary.

It is not airtight. It does visibly lower the success rate. Treat it as a supplement to measure 1, not a replacement.

4. Protect memory and the retrieval store from poisoning

An instruction planted into memory that outlives the session gets read back into every later session. The retrieval store has the same exposure.

This is why OWASP's Top 10 for Agentic Applications, published in December 2025, lists memory and context poisoning as its own item alongside goal hijacking and tool misuse.

5. Record what it read and what it did

After an incident you have to be able to answer "which document did this come from?" Without a record, it happens again.

Common misconceptions

"Can't we filter out the dangerous sentences?"

Filters get bypassed. Write it in another language, encode it, or split it across several documents and word-level checks pass. A filter is worth having, but do not widen permissions on the strength of it.

"We only use internal documents, so this doesn't apply?"

Internal documents contain things that came from outside: customer attachments, supplier quotes, draft contracts. And "internal" is broader than it sounds — a shared folder anyone can upload to is already external.

Check yourself

1. Why is indirect injection more dangerous than direct?

2. What three conditions make an incident, and which do you break?

3. Why is memory poisoning treated as its own risk?

Now the other side — the permissions on the tools you attach yourself → Tools are permissions