By Micky Irons, founder and CEO of Mickai.
By the middle of 2026 the security community has settled on an uncomfortable consensus: the most serious weakness in a language model is not the model itself but the instructions it reads. Indirect prompt injection, where hostile text is planted inside a document, a web page, an email or a support ticket and then acted upon by a model that treats it as a command, now sits at the top of the recognised AI risk rankings. It is not a theoretical concern. Through 2026 it has been documented in the wild, in the ordinary places that models are pointed at every day.
What makes this the defining threat of the year is its ordinariness. There is no exploit, no memory corruption, no privilege escalation in the classic sense. An attacker simply writes plausible words into content the model will later summarise or answer questions about, and the model, doing exactly what it was designed to do, follows them. For a regulated buyer weighing the EU AI Act, whose Annex III high-risk obligations were once due on 2 August 2026 and now apply from 2 December 2027 after the Digital Omnibus deferral, alongside DORA already in force and NIS2 obligations biting, the pressing question is no longer whether a model can be tricked. The proof requirements survive the move unchanged, so we read the later date as a build window and not a reprieve, which is why the sensible response is to build now. It is what happens next when one is.
Why the attack works, and why cleverness will not close it
A language model does not have a stable notion of who is speaking. Trusted system guidance, the operator's own prompt and untrusted content pulled from a file or a webpage all arrive as the same kind of thing: text. The model weighs them together and produces a continuation. That is the source of its usefulness and, in the same breath, the source of the injection problem.
Defensive filters, guard prompts and input sanitisation raise the cost of an attack, and they are worth deploying. They do not resolve it. Every published detection heuristic becomes the next attacker's test suite, and natural language offers an unbounded supply of paraphrase. Input filtering is best treated as one layer among several, never as the wall. The honest design assumption is that a determined injection will eventually land.
Once that assumption is accepted, the security conversation changes shape. The useful question stops being how to make a model impossible to deceive, and becomes how to make a deceived model incapable of doing much harm. That is a question about architecture, not about prompting.
The blast radius is decided by what the model can reach
An injected instruction is only as dangerous as the actions and destinations available to the model executing it. Tell a purely conversational assistant to exfiltrate a customer database and nothing happens, because it has no path to one. Give a model live network access, broad tool permissions and standing credentials, and the same sentence becomes an incident.
This is why the design works from the reachable surface inward. Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs offline on operator-owned hardware. There is no default route by which a manipulated model can send data to an outside address, because the perimeter is built to have no such route. Containment is not a setting to be switched on. It is the shape of the thing.
A model that cannot phone home cannot be turned into a courier, no matter how convincingly it is told to become one.
A zero-egress inbound perimeter as the primary control
The common cloud model of security assumes a live model that constantly reaches outward: to hosted inference, to retrieval services, to logging and telemetry endpoints. Each of those outbound paths is a channel an injection can attempt to abuse, because the machinery to reach the outside world is already present and trusted. This is a design choice with consequences, not an accusation against any named provider.
The SIOS takes the opposite default. It operates with a zero-egress inbound perimeter: content and requests come in, results stay on the operator's own hardware, and there is no standing outbound channel for a model to reach an arbitrary destination. When there is no line out, the classic injection payoff, quietly shipping secrets somewhere else, has nowhere to complete. The most valuable outcome of an attack is removed before the attack is written.
This also reframes exposure to instruments such as the US CLOUD Act. Data that never leaves operator-controlled infrastructure is not sitting in a third party's jurisdiction waiting to be compelled. Sovereignty here is a security property, not a slogan.
Cross-model consensus so no single deceived model acts alone
Even contained, a manipulated model can still return a wrong or hostile answer to the operator. To reduce that, consequential outputs are not the verdict of one model. The SIOS runs cross-model consensus, in which several independent sovereign models, drawing on different training and different reasoning paths, must agree before an action of weight proceeds.
An injection crafted to steer one model rarely steers all of them the same way. When answers diverge, that divergence is itself a signal: the disagreement is surfaced and escalated rather than silently resolved in the attacker's favour. Consensus does not make deception impossible. It raises the bar from fooling one reader to fooling several dissimilar ones at once, and it turns a silent compromise into a visible flag.
Hardware-attested identity and post-quantum signed audit chains
Containment answers what a model can do. Accountability answers what actually happened. In the SIOS, every action is cryptographically sealed. Identity is hardware-attested, so an instruction is bound to a specific, verifiable machine and operator rather than to a claim that can be forged in text. A model cannot assert its way into an authority it was never granted.
Each action is written to a post-quantum signed audit chain: an append-only, tamper-evident record whose signatures are chosen to withstand adversaries with future computing power. If an injection ever does induce an unexpected action, the record of it cannot be quietly edited away after the fact. For a regulator or an auditor, this is the difference between a plausible story and offline verifiability, evidence that can be checked without trusting a vendor's live service to be honest at the moment of the query.
This is also where standards work becomes concrete rather than aspirational. ISO/IEC 42001 asks organisations to manage AI risk in a governed, auditable way. A sealed, verifiable action chain is a direct instrument for that duty, not paperwork bolted on beside the system.
What the 2026 regulatory picture actually demands
The regulations converging this year do not ask whether a model can be attacked. They assume it can be, and they ask what controls, records and continuity an operator has in place. The EU AI Act's high-risk obligations, DORA's operational-resilience regime for financial entities, and NIS2's duties across essential sectors all point in the same direction: demonstrable containment and demonstrable evidence.
An architecture that keeps data on operator hardware, denies a manipulated model an outbound channel, requires agreement across independent models for weighty actions and seals every action into a verifiable chain speaks to each of these regimes in the language they use. It is a set of engineering commitments a buyer can inspect, not a set of assurances they must take on trust. The Mickai patent position, 104 filed UK patent applications and approximately 2,340 claims owned by Mickai LTD, all filed and patent pending, covers a good deal of this mechanism, though the relevant point for a buyer is that the controls are real and testable today.
Designing for the attack that lands
The mature response to prompt injection topping the risk charts is not to promise a model that can never be fooled. No serious engineer can promise that, and 2026 has shown why. The response is to build so that a fooled model is a contained event with a complete record, rather than an open door.
That is the standard the SIOS is held to: offline operation on owned hardware, a zero-egress inbound perimeter, cross-model consensus before consequential action, hardware-attested identity and a post-quantum signed audit chain underneath all of it. Each layer assumes the one above it may fail. As indirect injection grows more inventive, and it will, the systems that endure are likely to be the ones that were never asked to phone home in the first place. The reader is invited to test that claim against their own threat model, which is exactly the scrutiny it is built to withstand.
Written by Micky Irons. Originally published at https://mickai.co.uk/articles/prompt-injection-owasp-number-one-defending-ai-that-cannot-phone-home. More from Micky Irons and Mickai at mickai.co.uk.
Top comments (0)