Direct prompt injection — a user typing “ignore your instructions” — was always the easy version to reason about. The version that is now doing damage is indirect: the hostile text does not come from the person at the keyboard, it comes from the data the agent ingests on their behalf. A web page, a support ticket, a calendar invite, a code comment, an MCP tool result. The user asks an innocent question; the agent retrieves a document that carries instructions; the agent follows them. Between 2024 and 2026 this shifted from a chatbot party trick to enterprise risk, with public findings against Slack AI, Microsoft 365 Copilot, Cursor, GitHub MCP, and a string of AI coding assistants.
Between 2024 and 2026 indirect injection escalated from proof-of-concept to enterprise findings to live exploitation. A 2026 survey put confirmed-or-suspected AI-agent incidents at 88% of organizations.
Why it stays unsolved
At Infosecurity Europe in 2026, OWASP researchers said plainly that prompt injection remains unsolved, and Help Net Security reported OWASP's finding that it still drives most agentic AI failures in production. The reason is architectural, not a bug waiting for a patch. A language model processes its input as a single token sequence. There is no reliable mechanism inside the model to enforce a privilege boundary between the system prompt, the user's query, and content the agent retrieved from the world. Everything is just text, and any text can look like an instruction. You cannot RBAC a token stream.
Because the boundary cannot be enforced inside the model, it has to be enforced around it. That is the whole game. The Cloud Security Alliance's 2026 field research described indirect injection “in the wild,” and academic work formalized agent data-injection attacks as realistic threats — not because models got worse, but because agents got more connected, and every new connector is a new mouth through which untrusted text can arrive.
Indirect injection hides in retrieved context, so the inspection point has to see tool results and documents — not only the user's typed message — and decide before the model acts on them.
Most of the year's public incidents cluster in a handful of categories — prompt injection, sensitive-information disclosure, excessive agency, system-prompt leakage — with supply chain and improper output handling close behind.
What actually reduces the blast radius
No one honest is selling a solution. What responsible operators do is shrink the blast radius and make incidents visible. Concretely, four moves change the numbers, and none of them depend on the model choosing to behave.
- Treat all retrieved content as untrusted by default — tool results, RAG chunks, email, web pages — and classify it for injection before it reaches the model, the same way you would treat any external input in application security.
- Keep provenance attached: label which spans came from outside the trust boundary so downstream policy can refuse to let external text authorize privileged actions.
- Constrain what the agent can do after reading untrusted content — gate tool calls and data egress at authorize time, so a successful injection still cannot reach a dangerous action or an outbound channel.
- Instrument for detection: assume some injections get through, and make sure each one produces a finding you can see and review, rather than a silent success.
This is the posture behind Intertrace's gateway classification and runtime verification. We do not claim to end prompt injection — the field's own experts say that claim would be false. We aim to move the outcome from “undetected instruction executed with the agent's full authority” to “classified, constrained, and logged,” which is the difference between a breach and an alert.