Prompt Injection Is Not a Bug You Can Patch

Security has a working assumption buried so deep that most of us never state it out loud: a vulnerability is a defect. Somebody made a mistake, the mistake gets found, a patch is written, and the window closes. Everything downstream of that assumption, from CVE tracking to patch SLAs to vulnerability management as a discipline, exists because it is usually true.

Prompt injection breaks the assumption. It is not a defect in any implementation. It is the mechanism working exactly as designed, and that is precisely why it does not go away.

The confusion is the capability

A language model receives its system prompt, the user's request, and any text retrieved from an external source as a single undifferentiated stream of tokens. There is no reliable mechanism to mark some of those tokens as instructions and others as data. The model does not have a privileged channel, because it does not have channels at all.

This is not an oversight awaiting a fix. As Simon Willison put it in his write-up of what he calls the lethal trifecta: "LLMs follow instructions in content. This is what makes them so useful." An agent that could not be instructed by the material it retrieves would be an agent that cannot read a ticket, summarise a document, or act on an alert. The property being exploited is the property being purchased.

Speaking at Infosecurity Europe in June 2026, Ariel Fogel of Pillar Security's office of the CTO, an OWASP contributor, called prompt injection an unresolved problem for exactly this reason. Models, he said, "process inputs as a single token sequence and there is no reliable mechanism to enforce privilege boundaries between system prompts, user queries and content retrieved by an agent."

Note what follows from that. There is no version number at which this is resolved. There is no patch Tuesday for it.

Every defense so far is a probability, and probabilities get retried

The reasonable response is that mitigations exist. They do. The question is how they perform against an attacker who knows they are there.

In October 2025, a fourteen-author team drawn from Anthropic, Google DeepMind, ETH Zürich and Northeastern published exactly that test. They took twelve published defenses across four families, prompting-based, training-based, filter models, and secret-knowledge approaches, and attacked each one adaptively rather than with a static test set.

The results are worth reading slowly. Spotlighting and prompt sandwiching, which measured as low as 1% attack success under the benchmark's static attacks, fell to over 95%. MetaSecAlign, reported at 2%, fell to 96% under a search-based attack. Commercial filtering models including Protect AI, PromptGuard and Model Armor were bypassed at rates above 90%. Circuit Breakers reached 100% on HarmBench. The paper's conclusion is unambiguous: none of the twelve defenses, across all four techniques, is robust to strong adaptive attacks.

The reason is not that these defenses are badly built. It is that they are statistical classifiers layered on a channel that carries no type information. They are guessing at intent, because intent is the only thing left to guess at once instruction and data are indistinguishable. And a control that works 95% of the time is a control an attacker simply runs again. As Willison notes of vendors advertising that number, 95% is a failing grade in security.

The conditions are the job description

Willison's lethal trifecta names the three properties that turn this from a curiosity into an incident: access to private data, exposure to untrusted content, and the ability to communicate externally.

Look at that list and try to design a useful enterprise agent that lacks one of them. An agent that cannot reach private data cannot answer questions about your business. One that never sees untrusted content is one nobody outside the company can interact with. One that cannot communicate externally cannot file the ticket, send the message, or call the API. The trifecta is not a misconfiguration. It is the specification.

Which is why the incident record reads the way it does. In June 2026, Tenet Security Threat Labs demonstrated that an attacker could poison Sentry error events using nothing more than a publicly discoverable DSN. When AI coding agents queried Sentry over MCP, they ingested the poisoned events and executed attacker instructions: an 85% success rate across Claude Code, Cursor and Codex, with 2,388 organisations found holding exposed, injectable DSNs. AWS credentials, GitHub and GitLab OAuth tokens, npm registry tokens, Kubernetes and CI/CD secrets were all recoverable. Sentry acknowledged the disclosure and conceded the issue was not defensible at the platform level.

It is not an isolated case. A hidden injection in a GitHub issue directed an agent to publish the contents of private repositories. A malicious support ticket led an agent to query an integration-tokens table and post the results back into the ticket thread. A counterfeit email MCP package functioned correctly while silently copying every message to an attacker. A malicious pull request merged into an AI coding extension's own repository shipped data-wiping instructions out to its users.

What is actually being exploited

Here is where this stops being an AI problem and becomes a security problem.

The thing on the other end of a prompt injection is not a chatbot producing an embarrassing sentence. It is an identity with credentials and permissions.

Entro Labs put the ratio of non-human to human identities, across the environments it analysed, at 144 to 1 in the first half of 2025, up from 92 to 1 a year earlier. GitGuardian, counting secrets committed to public GitHub repositories over roughly the same period, found 1,275,105 AI service secrets, an 81% year-over-year rise, with eight of its ten fastest-growing detectors tied to AI services. Secrets for LLM infrastructure specifically, meaning orchestration, RAG and vector storage, leaked around five times faster than those belonging to the model providers themselves.

Both of those are vendor research rather than independent measurement, and worth reading with that in mind. The direction is not really in dispute, though: the population of machine identities is growing faster than the humans nominally accountable for them, and credentials attached to AI infrastructure are leaking faster than any other category being tracked.

Why your existing stack stays quiet

The detail from the agentjacking research that deserves the most attention is not the success rate. It is what the security stack did while it happened, which was nothing.

EDR observed a trusted process running a legitimate package-manager command. IAM observed the developer's own authorised credentials being used for permitted operations. The WAF observed routine outbound package traffic. No control was misconfigured and no control failed. There was simply nothing anomalous to see, because the attack was composed entirely of authorised actions performed by an authorised identity.

This is the part that should worry a security leader more than the injection itself. There is no malware to catch, no exploit to signature, no unusual binary, no privilege escalation. The agent did exactly what it was permitted to do. It just did it on someone else's behalf.

What is left

If prevention at the boundary cannot be made reliable, and the research above is a fairly direct statement that it cannot, then the useful question is no longer how to stop the injection. It is how fast you find out that one worked.

We have written before about why that means moving the signal away from was this action permitted and toward did something touch what nothing legitimate touches. The reason that principle matters more here than anywhere else is the problem described two sections up: when every action in the chain is authorised, permission is no longer information. Something has to be true about the target rather than about the actor.

We build that as Synthetic Cognitive Agents: synthetic assets placed in an environment to be found by an intruder and by nobody else, because no legitimate process has any business reaching them. On a network, one takes the form of a service standing quietly with no real users. In an agent stack it takes a different form entirely. A Synthetic Cognitive Agent on the network traps a port scan. Inside an agent's tool surface, it traps a tool call.

The mechanics are plain. You advertise capabilities alongside the real ones that an attacker's agent would very much want to call and a legitimate workflow never would. get_admin_credentials. list_api_keys. dump_user_table. disable_tenant_isolation. Real workflows do not reach for these, so there is no baseline to learn, no threshold to tune, and no classifier to keep retraining as the attacks change. Any invocation is hostile. That is the entire detection logic, and its indifference to technique is the point: it does not matter whether the injection arrived through a poisoned Sentry event, a hidden line in a GitHub issue, or a phrasing nobody has published yet.

What the Synthetic Cognitive Agent hands back matters as much as the trap itself. The credentials it returns are fabricated and individually tracked. If one of those values ever appears anywhere else, in a SIEM, an authentication log, a paste site, that is not a suspicion. It is confirmed exfiltration, attributable to the exact agent session that took it. Which resolves the identity problem directly: you never have to distinguish a hijacked agent from a legitimate user, because the token it is carrying only ever existed inside a trap.

The trip is not the end of it. What the intruder reached for, in what order, and what it did with what it received becomes a Neural Echo: the behavioural record a Synthetic Cognitive Agent produces when something engages with it. A log entry tells you an action occurred. A Neural Echo tells you what the intruder was trying to accomplish, which is the thing you actually need when deciding how far the compromise has already run.

Then the part that tends to get overlooked. A trip like this should not land in a separate AI console to be triaged by whoever owns AI. It belongs in the same event store and the same attack chain as your IT and OT Synthetic Cognitive Agents, because an agent compromise is rarely the whole intrusion. It is a stage in one.

Be clear about what this is not. It does not fix prompt injection, and nothing does, which is the point of everything above. It does not prevent an agent from being hijacked, it does not inspect model reasoning, and it does not block. It detects that an agent has been turned, at the moment it reaches for something it was never supposed to touch, without depending on a distinction the architecture cannot draw.