92 Percent of Security Leaders Cannot See Their AI Identities. That Is a Governance Emergency

!A cinematic Greek figure of Chronos, keeper of the audit trail, rendered in gold against a void-black field, holding an unbroken ledger of time

Ask a room of CISOs how many human employees they can name, deprovision, and audit on demand, and nearly every hand goes up. Ask the same room how many of the AI identities running inside their estate they can see in full, and the room goes quiet. A 2026 survey of 235 large-enterprise security leaders put a number on that silence: 92 percent lack full visibility into their AI identities. Eighty-six percent do not enforce access policies for them. Seventy-one percent say AI already reaches into core ERP, CRM, and financial systems. And only 16 percent believe they govern that access effectively.

We build for regulated organisations, and we read those figures as one thing above all others. This is not primarily an access-control gap. It is an audit gap. And an audit gap is a governance emergency wearing a convenience costume.

The blind spot is an audit problem before it is an access problem

Most of the coverage of these numbers reaches for the obvious lever: tighten access, enforce least privilege for agents the way you do for people. That is correct and it is not enough. Access policy tells you what an identity is allowed to do. It does not tell you, after the fact, what it actually did, in what order, on whose authority, against which record. When an agent with standing access to your general ledger posts a journal entry at 03:14, the question your auditor, your regulator, and your board will ask is not "was it permitted." It is "prove exactly what happened, and prove the proof has not been altered."

That is the layer 92 percent of the market cannot produce. Human identities leave a reviewable trail because decades of tooling grew up around them: SIEM, IAM, privileged-access logs, ticket references. AI identities were bolted onto that world at machine speed and machine volume, and the trail thinned out to almost nothing. You end up with an actor that can touch financial systems, act thousands of times an hour, and leave behind a log you cannot fully attribute or fully trust.

Why the usual logging does not close it

Enterprises are not doing nothing. They have application logs, cloud audit trails, model-gateway records. The problem is that these records are descriptive, not evidential. A conventional log says an event was written; it does not, by itself, prove who authorised the action, that the record is complete, or that no one with database access edited it afterward. In a shared third-party environment the person able to alter the log may be someone you cannot see and cannot vet.

This is the residual-risk line that our founder keeps returning to, because it is the part conventional controls cannot answer:

> "If you are a multibillion-dollar company running on Anthropic or OpenAI, and your direct competitor of comparable scale sits on the same vendor stack, what stops them paying a vendor insider to leak your data, your tactics, your leads, your sales strategy? Inside a third-party cloud, there is no safeguard you can verify from the outside. The only answer is a sovereign system where you hold the keys, with no third-party cloud data path." > > Micky Irons, founder and CEO, Mickai LTD.

SOC 2 and ISO 27001 attestations describe a provider's controls. They do not hand a multibillion-pound customer a verifiable answer to "what stops your engineer, or a rival's money, from touching my agent's audit record." That is not an argument against hyperscalers, whose products remain valuable for most workloads. It is a boundary: for the slice of activity where an AI identity acts on regulated, competitive, or financially material data, the safeguard has to be one the operator can verify from the inside.

The missing layer: a signed record on every action

The fix we designed for is not a better dashboard. It is a per-action, cryptographically-signed audit record, generated at the moment the AI identity acts and bound to that action so it cannot be silently altered afterward. Every step an agent takes, the read, the tool call, the write, the approval it relied on, produces its own signed attestation. The record is tamper-evident by construction: change one entry and the signature no longer verifies.

That turns the 92 percent blind spot into something a governance function can actually stand behind. You move from "we log agent activity" to "we can produce a verifiable, non-repudiable account of every action any AI identity took, and demonstrate the account is intact." That is the difference between a story and evidence. It is what a DORA operational-resilience review, an FCA or PRA supervisor, an internal-audit committee, or a breach investigation actually needs, and it is the layer almost no one currently has for their agents.

!A gold figure of Hades enthroned before a sealed vault, evoking permanence and an audit record that cannot be quietly rewritten

Why it only holds inside owned walls

Here is the part the market keeps skipping. A signed audit record is only as trustworthy as the walls it lives in. If the signing keys, the record store, and the runtime all sit inside a shared third-party environment, you are back to trusting a party you cannot fully see. The attestation proves the record was not altered by someone without the key. It cannot protect you from whoever holds the key on infrastructure you do not control.

That is why we built Mickai as a Sovereign Intelligence Operating System, a SIOS the regulated organisation owns and runs inside its own walls, air-gapped where the workload demands it, with operator-held keys and the signed audit record generated on the operator's own substrate. The attestation and the keys never leave your control. The audit record answers to you, not to a vendor.

We want to be precise and honest about the market, because over-claiming helps no one. Almost every regime, DORA, the FCA and PRA, the EBA, the NHS Data Security and Protection Toolkit, GDPR, permits cloud with the right controls. The genuine no-cloud bar is workload-level: classified material, ITAR-controlled data, isolated OT and SCADA, a DPIA that comes back negative. The far larger driver is preference, the desire for verifiable control, for cost predictability, and for a hard answer to data-exfiltration risk. On a register-backed view that sovereign-leaning market is roughly 16,092 UK and EU institutions, and the enterprise-AI-platform software TAM runs from about USD 13bn in 2024 toward USD 50.3bn by 2030 on Verdantix figures, roughly £11.7bn to £39.7bn. The point is not that everyone is barred from cloud. It is that a governance-grade audit record for AI identities is only fully trustworthy when the operator holds the keys, and that is a design choice, made once, that the survey shows almost no one has made.

The takeaway for identity-governance leads

If you own identity governance and you are scaling agentic AI, treat these four numbers as a single finding: your AI identities can act on your most sensitive systems, and you cannot yet produce a verifiable account of what they did. Closing it does not start with buying another log aggregator. It starts with deciding that every AI identity's every action must produce a signed, tamper-evident record, and that the keys and the substrate behind that record sit inside your own walls. That is the layer that turns 92 percent blind into governed, and it is the layer we built the SIOS around.

Frequently asked questions

What is an AI identity, and why can it not be governed like a service account?

An AI identity is an autonomous or semi-autonomous agent that authenticates, holds permissions, and acts across your systems. Unlike a static service account it reasons, chains tool calls, and can take thousands of context-dependent actions an hour. Static allow-lists and quarterly access reviews were built for predictable, low-volume actors; they neither constrain nor evidence what an agent actually does in the moment, which is why visibility and audit break down at agent scale.

Does a signed audit record slow the agent down?

No, in the sense that matters. The attestation is generated inline as each action executes and is designed to run at machine speed on the operator's own substrate. You are adding an evidential layer to activity that is already happening, not inserting a human approval gate. The cost is storage and key management, both of which the operator controls, in exchange for a non-repudiable record you can hand to an auditor.

How is this different from our existing SIEM or cloud audit logs?

Those systems record that events occurred, but the records are descriptive and, in a shared environment, alterable by parties you may not be able to see or vet. A per-action signed attestation is evidential: it binds authorship and integrity to each action so that any later change breaks the signature. Held on operator-owned infrastructure with operator-held keys, it answers the "prove it, and prove the proof is intact" question that conventional logs cannot.

We are permitted to run agents in the cloud. Why move the audit layer on-premises?

Because permission and verifiability are different things. Most regulators do permit cloud with controls, so this is rarely about a legal bar. It is about whether you can verify, from the inside, that no one outside your control can read the keys or alter the record. For AI identities acting on regulated, competitive, or financially material data, holding the substrate and the keys yourself is the only way to make the audit record answer to you alone.

For related reading, see our work on Auditable AI and the operator-held audit record, the sovereign-substrate case in Giants as Allies, Not Competitors, and how the SIOS seals the runtime end to end.

---

By Micky Irons, founder and CEO, Mickai. Mickai is a Sovereign Intelligence Operating System that regulated organisations own and run inside their own walls, with a cryptographically-signed audit record on every action. Our patent portfolio stands at 104 filed UK applications spanning roughly 2,340 claims across 13 families, building toward examination and grant.

!The MICKAI wordmark with the gold M lockup on a void-black field