The 88 Percent: AI Agent Security Incidents Are Now the Norm

A 2026 enterprise survey found that the large majority of organisations reported a confirmed or suspected AI agent security incident in the past year. When a figure climbs toward nine in ten, it stops describing an unlucky few and starts describing the baseline. An incident is no longer the exception that proves a control worked. It is the expected condition of running autonomous software that reads, decides and acts on behalf of a business.

This matters now because the regulatory floor has risen to meet the risk. The EU AI Act's Annex III high-risk obligations, once due on 2 August 2026 and drawing many enterprise agents into scope, now apply from 2 December 2027 after the Digital Omnibus deferral, yet the proof requirements survive the move, so the sensible response is to build now. DORA has bound financial entities to operational resilience obligations since January 2025, NIS2 has widened the definition of essential and important entities, and ISO/IEC 42001 has given auditors a management-system standard to test against. The question a serious buyer now asks is not whether agents fail, but whether an organisation can prove what its agents did when they did fail.

What the 88 percent actually measures

A high incident rate is easy to misread as a maturity problem, as though the answer were more training or a tighter prompt. It is better read as a structural signal. The dominant pattern of agent deployment sends sensitive context out to a remote model, receives an instruction back, and executes it against internal systems with credentials the agent was handed at setup. Every one of those legs is an attack surface, and most of them sit outside the organisation's own boundary.

The recognised failure modes are now catalogued. The OWASP work on large language model and agentic risks names prompt injection, insecure output handling, excessive agency and supply-chain exposure as recurring classes rather than novelties. What the survey figure adds is scale. When a control class fails across most of a market, the reasonable inference is that the control was never architectural in the first place. It was advisory, sitting above a system that could ignore it.

We treat the number as a design verdict. The incidents are not a training gap to be closed by degrees. They are the predictable output of a model where the agent's identity, its reasoning and its record all live somewhere the operator does not control.

The perimeter is the wrong shape

Classical security assumes a boundary you defend at the edge, with data flowing out through monitored gates. Agentic systems invert this. The agent's value comes from egress, from reaching a distant model with whatever context the task requires, which means the sensitive material leaves before any local control can bind it. Once context has crossed a jurisdictional boundary it is subject to that jurisdiction. Under instruments such as the US CLOUD Act, data held by a provider can be compelled irrespective of where the customer sits.

The design response is to invert the inversion. A zero-egress inbound perimeter keeps the model, the context and the execution on operator-owned hardware, and admits work rather than exporting it. Requests come in, are evaluated against policy locally, and are answered without the underlying data ever leaving the boundary. This is not a stricter firewall. It is a different topology, in which there is no outbound leg to intercept because there is no outbound leg at all.

Mickai is a Sovereign Intelligence Operating System, a SIOS, built on exactly this shape. It runs offline on hardware the operator owns, and it treats egress as the exception a policy must explicitly permit rather than the default the architecture assumes.

An agent you cannot identify is an agent you cannot govern

Most incident investigations stall at the same wall. The organisation cannot say with confidence which agent, running which code, on which machine, took the action under review. Software identity in agentic systems is usually a bearer token or an API key, which answers the question of who holds the credential and not the question of what is actually running.

Hardware-attested identity closes that gap. When an agent's identity is rooted in a hardware security element rather than a copyable secret, the operator can verify that a specific agent, with a specific configuration, on a specific attested device, is the party requesting an action. An identity bound to silicon cannot be lifted and replayed the way a token can. This is the difference between trusting a claim and verifying a fact, and it is the precondition for any meaningful least-privilege model, because you cannot scope a privilege to an actor you cannot pin down.

“An agent becomes governable only when its identity, its reasoning and its record are things the operator can verify offline rather than things the operator is asked to trust.”

The audit trail has to be unforgeable, not merely present

Every serious framework now demands an audit trail. DORA expects reconstructable incident timelines, ISO/IEC 42001 expects records that survive scrutiny, and the EU AI Act expects logging for high-risk systems. The weakness is that most audit logs are mutable. They are written to storage the same operator can alter, which means at the moment of dispute the log proves only that someone with write access chose to leave it intact.

A cryptographically sealed audit chain answers a different standard. Each action is signed and linked to the one before it, so any later edit breaks the chain and is detectable. Because the threat model now includes adversaries who will eventually hold quantum capability, the signatures should be post-quantum, so that a record sealed today cannot be forged by a machine that does not yet exist. In Mickai every action is sealed this way, and the record can be checked without contacting any external service.

The practical effect is that an audit stops being an act of faith. A regulator, an insurer or an acquirer's diligence team can verify the chain themselves, offline, and reach their own conclusion about what happened rather than accepting the operator's account of it.

One model is a single point of failure

A lone model is confidently wrong at a rate no amount of prompting removes, and prompt injection succeeds precisely because a single model has no second opinion to contradict a poisoned instruction. Reliability improves when a decision must survive more than one independent reasoner before it is allowed to act.

Cross-model consensus routes a consequential judgement through several sovereign models and compares their outputs, so that an injected instruction which fools one path is caught by disagreement with the others. This is a design choice about where to spend redundancy: not on uptime, which most systems already buy, but on correctness, which most systems leave to a single fallible component. The consensus itself is recorded in the sealed chain, so the reasoning behind an action is auditable alongside the action.

From liability to governed capability

Put the mechanisms together and the incident that defines the 88 percent changes character. A zero-egress inbound perimeter removes the exposure that comes from exporting context. Hardware-attested identity means every action traces to a verified actor. A post-quantum sealed audit chain means the record cannot be quietly rewritten. Cross-model consensus means a single poisoned input does not become a single catastrophic act. None of this makes an agent infallible. It makes an agent accountable, which is the property a security team can actually work with.

This is the substrate we build. The architecture is the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented. We describe it as design and mechanism rather than as a claim of settled ground.

What a security team should ask next

The survey figure is not a reason to slow adoption, and treating agents as too dangerous to deploy simply cedes the capability to less careful competitors. It is a reason to change the questions asked before deployment. Can we identify the agent that acted, cryptographically and to a specific device. Can we reconstruct what it did from a record that cannot have been altered. Did the sensitive context ever leave our boundary, and can we prove that it did not.

As the EU AI Act's high-risk obligations arrive in August 2026 and resilience regimes like DORA and NIS2 continue to bite, these questions move from good practice to evidence a buyer will be asked to produce. An organisation that can answer them holds a governed capability. One that cannot holds a liability that a survey has already priced at nearly nine in ten. We would rather help build the first kind, and we think the coming year will make the distinction between the two the whole of the argument.