The Unpatchable Boundary

Most teams still treat prompt injection as a bug. They expect a patch, a filter, or a model update to close it the way a vendor closes a buffer overflow. That expectation is the mistake. Prompt injection is not a defect in a particular model or framework. It is a property of how every current language model reads its input, and no patch on the roadmap removes it.

The reason is simple enough to state in one sentence. A language model receives the system prompt, the user's request, and any text it retrieves from a web page, a document, or an API response as one undivided stream of tokens. The model has no reliable way to mark some of those tokens as trusted commands and others as mere data. A sentence buried in a fetched web page can carry instructions, and the model may follow them with the same willingness it follows yours.

Think of it as hiring a brilliant but very literal assistant. They read every document you hand them, and they treat any sentence that sounds like an order as an order from you. A vendor hides a line in the footer of an invoice that reads pay this account first, and the assistant pays it, because nothing in the page tells them it did not come from your desk. The assistant is not careless. They simply have no way to see where your authority ends and the paper's content begins.

An agent cannot enforce a privilege boundary inside a single token stream. Everything it reads is, at some level, a candidate instruction. That is the boundary problem, and it is not a filter problem.

Operating systems solved this decades ago by separating code from data and giving the kernel a privilege level that user programs cannot reach. A language model has no kernel. The instruction to summarize a document and the malicious line hidden in that document arrive at the same address, in the same format, with the same authority. We keep trying to bolt a privilege boundary onto a system that was never built to hold one.

Why a filter cannot win

The common defense is a classifier that scans input for injection attempts and blocks the suspicious ones. This helps at the margin, and it should be used. It does not solve the problem, because the defender has to catch every phrasing of a malicious instruction while the attacker needs only one that slips through. Natural language has unlimited ways to say the same thing, so the attacker's search space is effectively infinite and the filter's coverage is always finite.

Indirect injection makes this worse. The dangerous text does not come from the user at all. It hides in the content the agent was told to read: a product review, a calendar invite, a code comment, a page the agent fetched on its own. The attack surface becomes the entire information environment the agent touches, which no allowlist can fully describe. The 2026 edition of the OWASP report on agentic security maps prompt injection to six of its ten threat categories, which is a polite way of saying it underlies most of the ways these systems fail.

From content problem to execution risk

For a while the worst case looked like bad output: a chatbot tricked into saying something off policy. Agents changed the stakes, because an agent does not just speak. It calls tools. It runs code, writes files, sends mail, and touches internal systems. When an injected instruction reaches a tool call, a content problem becomes an execution problem.

Microsoft made this concrete in May 2026. Its researchers showed prompt injection escalating into remote code execution inside mainstream agent frameworks. One flaw, tracked as CVE-2026-26030, let a single crafted prompt traverse Python's class hierarchy through unsafe string handling and launch an arbitrary executable. A second, CVE-2026-25592, exposed a file-download function to the model without path validation, so an attacker could write to sensitive locations such as a Windows startup folder and escape the sandbox. The models behaved exactly as designed. The failure lived in how the frameworks wired untrusted model output to powerful tools without a guard in between.

That is the part worth sitting with. The vulnerability was not in the model's intelligence. It was in the assumption that the model's output could be trusted enough to drive a system call. Strip that assumption and the architecture of most agent stacks needs a rethink.

The lethal trifecta and the rule of two

Two framings turn this from a worry into a design discipline. The first is the lethal trifecta, named by Simon Willison. An agent becomes a data exfiltration tool when it combines three capabilities: access to private data, exposure to untrusted content, and the ability to communicate externally. Hold all three and a single injected instruction can read your secrets and ship them out. Drop any one and that specific attack path closes.

Meta turned the same observation into a rule that an architect can apply at design time. Its Agents Rule of Two states that, until research can reliably detect and refuse injection, an agent should satisfy at most two of these three properties in a single session: it processes untrusted input, it can reach sensitive data or systems, or it can change state or communicate outside. An agent that needs all three to do its job should not run autonomously. It needs a human approval step or another reliable check before it acts.

This is not a cure. It is a containment strategy that assumes the boundary will be crossed and limits the blast radius when it is. That is the right posture for a flaw you cannot patch.

Designing for a boundary you cannot enforce

The practical move is to stop asking the model to police itself and to put the controls in the architecture around it. A few patterns carry most of the weight:

• Scope each agent so it holds at most two legs of the trifecta. If a workflow truly needs all three, split it into separate agents with a human or a deterministic check at the handoff.
• Treat every tool call driven by model output as untrusted by default. Validate arguments, constrain file paths, and allowlist the operations a tool can perform before it runs, not after.
• Put the dangerous, irreversible actions behind human approval. Sending mail, moving money, deleting data, and changing access should not be fully autonomous in a system exposed to untrusted content.
• Run agents in disposable sandboxes with the narrowest credentials that still let the task finish, so a successful injection reaches very little.

None of these depends on the model getting better at spotting bad instructions. They work because they assume it never will.

The takeaway

Prompt injection is the agentic era's version of a fact every security engineer already knows: you do not trust input, and you design as if your controls will be tested. The uncomfortable twist is that the model itself is now part of the untrusted path. The leaders who internalize this will stop waiting for a patch that is not coming and start building boundaries the model cannot dissolve.

The capability curve is climbing fast, and the pressure to grant agents more reach will only grow. The teams that move first on containment will ship autonomy that holds up under attack. The teams that keep treating this as a bug will keep shipping the next CVE.

What leaders should do

1. Audit every deployed agent against the Rule of Two this quarter, and flag any that hold all three capabilities (untrusted input, sensitive access, external communication) for redesign or a human approval gate.
2. Require that any tool callable by an agent validates and constrains its own inputs, and review the highest-risk tools (code execution, file writes, network calls) first.
3. Put irreversible actions behind a human-in-the-loop step, and measure how often agents request them so you can right-size the gate rather than block everything.
4. Fund injection red-teaming as a standing function, not a one-off audit, because the attacker's phrasing space keeps growing and yesterday's filter coverage decays.