VERIK / V025 / 18 JUN 2026
Mythos AsymmetryGovernance

The Confusion That Cannot Be Patched

A June 17, 2026 NCSC post argues that prompt injection cannot be stopped the way SQL injection can. The argument is structural. The standards posture that follows from it has not been written. The shape of the procurement clause that would follow from it is now visible.

On June 17, 2026, the UK National Cyber Security Centre, a part of GCHQ, published Mistaking AI vulnerability could lead to large-scale breaches. The post is short. The structural argument inside it is not.

The argument is direct. SQL injection was mitigated, the NCSC notes, because the SQL execution boundary can enforce a clean separation between data and instructions. Parameterized queries, escaped inputs, prepared statements: each one rests on the same architectural property. A SQL engine can be made to treat user-supplied bytes as data only. The instruction surface and the data surface are mechanically separable.

A large language model has no such separability. Instructions and data arrive on the same channel, in the same token stream, drawn from the same vocabulary, parsed by the same forward pass. The NCSC names this with one phrase: LLM systems are "inherently confusable." The phrase does work. It rejects the comparison to SQL injection as a category error. It rejects the framing that the right defense is more careful input validation. It rejects the claim, the NCSC writes, that prompt injections can be "stopped."

What the NCSC asks for in place of the stopping framing is "reducing the risk and impact of prompt injection and driving up resilience across AI supply chains." The phrasing is institutional. The implication, read against the post's structural claim, is concrete. A defense surface that assumes prompt injection is preventable will be built differently from a defense surface that assumes prompt injection is permanent. The two postures do not produce the same controls, the same audit obligations, or the same procurement clauses.

What the post makes legible at the governance layer

The institutional record on AI risk now contains several artifacts that, read alongside the NCSC post, sharpen rather than resolve the question.

The NIST AI Risk Management Framework Generative AI Profile names prompt injection as a risk and prescribes governance practices. The framework does not commit on whether the risk is mitigable in principle. The OWASP Top 10 for Large Language Model Applications lists prompt injection as the first item and recommends layered defenses without claiming any layer is sufficient. The NCSC post differs from both in that it states, in the position of a national cyber authority, that the comparison to a vulnerability class that was eventually closed is itself the error.

The post sits alongside two prior NCSC outputs that read as a sequence. The August 2023 NCSC blog on prompt injection and data poisoning named the issue early. The May 2026 NCSC briefing on Securing AI Systems named the practices. The June 17 post names the architectural ceiling. Read in order, the three pieces describe an institutional position that has moved from caution, to practice, to category.

The same week the NCSC published its post, the arXiv record produced a defense paper on indirect prompt injection in retrieval-augmented contexts and a routing-infrastructure paper that does not address prompt injection at all. The juxtaposition is informative. Defense research continues to treat prompt injection as a per-system mitigation problem. Infrastructure research continues to treat the routing surface as the higher-leverage governance question. The NCSC post argues that the first framing has a ceiling and the second framing is where the durable controls will sit.

What the construction demands of the institutional record

If the NCSC argument is taken at face value, several existing instruments need to be re-read.

A procurement clause that requires a vendor to "prevent prompt injection" is, by the NCSC argument, asking for an artifact the vendor cannot produce. A compliance attestation that states a system is "hardened against prompt injection" is, by the same argument, asserting a property that cannot be verified. An audit posture that asks for evidence that no prompt injection has occurred is asking for a negative the system cannot produce on its own substrate.

What can be asked for, by the NCSC framing, is different. The shape resembles the posture taken for other categories of unstoppable phenomena. Side-channel attacks against cryptographic implementations are not eliminated; they are bounded by isolation, attestation, and monitoring. Insider threat is not eliminated; it is bounded by separation of duties, logging, and external review. Bit rot in archival storage is not eliminated; it is bounded by erasure codes, scrubbing, and integrity verification. In each case the institutional posture moved from "prevent" to "bound and detect" once the architectural ceiling was named.

The NCSC post performs that naming for prompt injection. The instruments that would follow from the naming are not yet in the public record.

What would close the gap

The NCSC post does not name the procurement clause it implies. The shape of the clause is visible from the post's own framing.

A clause that follows the NCSC framing would name three things. It would name the containment surface. A system in which prompt injection cannot be prevented can still be designed so that a successful prompt injection cannot reach the actions that matter. The boundary between "what the model says" and "what the system does" can be specified as a separate authorization step that does not consult the same token stream. The recent arXiv work on context-fractured decomposition attacks gives one concrete shape for that boundary. The Microsoft Agent Security work gives another.

It would name the detection surface. A system in which prompt injection cannot be prevented can still be designed so that successful prompt injection produces a detectable trace. The trace is not in the model's output token stream. The trace is in the routing record, the tool-call record, and the access-pattern record. Each of those records exists today as operational telemetry. None of them is currently specified as a regulated artifact.

It would name the recovery surface. A system in which prompt injection cannot be prevented can still be designed so that a successful injection can be revoked, traced, and remediated. The federal posture on cryptographic revocation is well-developed. The federal posture on agent-action revocation is not. The Heartbeat-Bound Hierarchical Credentials work provides one architectural primitive for time-bounded revocation. The procurement clause that would invoke it has not yet been written.

None of the three components requires a research advance. Each has institutional precedent in adjacent domains. Each has the same procurement-instrument shape that FIPS validation has for cryptographic modules, that Common Criteria evaluation has for security products, and that SBOM disclosure has for software supply chains. The move is to open the venue and name the artifact.

The federal authority that publishes working drafts for cryptographic algorithms has the standing to publish a working draft for an LLM containment-detection-recovery posture. The federal authority that requires FIPS-validated cryptographic modules has the standing to require evidence of containment, detection, and recovery for systems whose architectural ceiling has been named by a peer national authority. The NCSC post has named the ceiling. The procurement instruments that take the ceiling as given have not yet been published.

What remains on the table:

The policy instruments and the deployment tempo are not aligned. The architectural ceiling has been named in the voice of a national authority. The procurement clauses that would take the ceiling as given have not yet been written.