Non-human identities now outnumber humans 50 to 1: how do you make an AI agent an accountable identity?

How do you make an AI agent an accountable identity?

You give each agent its own named identity, scope it to the narrowest set of permissions it needs, and record every consequential action it takes in a tamper-evident audit trail. An agent that has a name you can look up, a boundary it cannot cross, and a log you can read after the fact is an accountable identity. An agent that shares a service account, inherits a human's broad access, and leaves no reviewable record is not. Everything else in agent governance sits on top of those three foundations: name, scope, audit.

This matters now because the machines have quietly outvoted us. 2026 research shows non-human identities outnumber humans by roughly 50 to 1, and by 144 to 1 in cloud-native environments. These are service accounts, API keys, bots and now autonomous agents, each of which can act, spend, move data and change state. The population you actually manage is no longer your staff. It is a crowd of automated actors, most of which you did not consciously enrol.

Why is this suddenly a governance problem?

Because the agents are misbehaving and you cannot tell who is who. In the same body of 2026 research, 80 percent of IT leaders report agents acting outside their expected behaviour, and a Cloud Security Alliance survey finds 68 percent of organisations cannot reliably distinguish AI-agent activity from human activity. Put those two figures together and you have the core failure: agents are doing unexpected things, and most organisations cannot even attribute the action to an agent versus a person.

That is not a tuning problem. It is an identity problem. If four in five leaders see agents stepping outside their lane, and two in three teams cannot separate agent traffic from human traffic in their logs, then the standard tools of accountability, who did this and were they allowed to, have already broken down. You cannot investigate an incident you cannot attribute. You cannot revoke access from an actor you cannot name.

Why is a shared service account not good enough?

Because a shared account destroys attribution the moment more than one thing uses it. When ten agents and three integrations all authenticate as the same service identity, the log tells you the account acted, not which agent, under whose instruction, with what intent. When something goes wrong, you have a single suspect wearing ten masks. You cannot scope permissions to one agent's job, you cannot rotate a credential without breaking everything that shares it, and you cannot prove which agent touched a regulated record.

The 144 to 1 ratio in cloud-native environments is largely a story of shared, over-permissioned, poorly tracked machine identities. Agents make this worse because they act with initiative. A static script does one predictable thing. An agent reasons, chains actions and reaches for tools. Handing that behaviour a broad shared credential is how you get the 80 percent figure.

What does an accountable agent identity actually require?

Three things, in order.

First, a distinct identity per agent. Each agent gets its own credential, its own name in the directory, its own place in the log. No shared service accounts standing in for a swarm.

Second, a bounded scope. The identity carries only the permissions that agent's task needs, and only for as long as it needs them. Scope is the difference between an agent that can read one folder and an agent that can exfiltrate a database because it inherited a human admin's rights.

Third, a durable audit record. Every consequential action, the ones that move money, change access, touch regulated data or leave your walls, is written to a log that cannot be quietly edited after the fact. Attribution is only worth something if the record survives the incident.

How does Mickai make agent activity attributable?

We treat every agent as an identity, not a feature. Inside Mickai, an agent is issued a bounded identity with an explicit scope, and every consequential action it takes is sealed into a post-quantum signed audit ledger using ML-DSA-65 (FIPS 204). Because the ledger is signed and effectively append-only, agent activity is attributable and reviewable after the fact, and a later tamper shows up rather than passing silently. When an auditor or investigator asks which agent did this, under what scope, and when, the answer is in the record rather than in guesswork.

Because Mickai runs inside your own walls, on hardware you control and offline where you need it, that record stays yours. The 68 percent who cannot separate agent activity from human activity usually cannot because their logs live in someone else's cloud, in a format they cannot fully trust or query. A sovereign, operator-owned ledger closes that gap: your agents, your identities, your signed record.

Here is the honest limit. Identity and audit are the foundation of agent governance, not the whole of it. Naming and sealing an agent's actions makes them attributable and reviewable. It does not, by itself, stop an agent forming a bad plan, prevent every misuse of a permission you granted, or replace human judgement over what agents should be allowed to do. You still need scoping discipline, monitoring, kill switches and review. What Mickai gives you is the thing all of those depend on: a world where every agent has a name, a boundary and a record. You cannot govern what you cannot attribute, and attribution is exactly what we build in.

What should a buyer do about it now?

Start by counting your non-human identities and asking a blunt question of each: does it have its own name, a scope it cannot exceed, and a log I could hand an auditor. Most will fail on at least one. Fix the shared service accounts first, because they poison attribution for everything behind them. Then insist that any agent platform you adopt issues bounded identities and seals consequential actions into a record you own and can verify. That is the bar we hold ourselves to, and it is the bar the 50 to 1 world now demands.

“Non-human identities outnumber humans roughly 50 to 1, and 144 to 1 in cloud-native environments, so identity governance can no longer be built around people alone.”

Frequently asked questions

What does it mean that non-human identities outnumber humans 50 to 1?

2026 research finds that service accounts, API keys, bots and AI agents together outnumber human users by roughly 50 to 1 across environments, and 144 to 1 in cloud-native ones. In practice most of the actors touching your systems are automated, so identity governance can no longer be built around people alone.

Why can most organisations not tell agent activity apart from human activity?

A Cloud Security Alliance survey found 68 percent of organisations cannot reliably distinguish AI-agent activity from human activity, usually because agents share service accounts, inherit human permissions, and log to systems that do not attribute actions to a specific agent. Without a distinct identity per agent, the log cannot separate them.

What makes an AI agent an accountable identity rather than an ungoverned account?

Three things: a distinct named identity per agent, a bounded scope limited to what its task needs, and a durable audit record of every consequential action. An agent missing any of these cannot be reliably investigated, scoped or revoked.

How does Mickai make an agent's actions attributable?

Mickai issues each agent a bounded identity and seals every consequential action into a post-quantum signed audit ledger using ML-DSA-65 (FIPS 204). The record is signed and effectively append-only, so agent activity stays attributable and reviewable, and later tampering is detectable.

Does giving an agent an identity and audit trail make it safe?

No. Identity and audit are the foundation of agent governance, not the whole of it. They make actions attributable and reviewable, but you still need scoping discipline, monitoring, kill switches and human review to decide what agents may do and to catch bad behaviour in the moment.

Where does the 80 percent misbehaviour figure come from and what does it imply?

2026 research reports that 80 percent of IT leaders have seen agents act outside expected behaviour. Combined with the inability to attribute that behaviour, it implies the priority is not just better models but better identity: you cannot investigate or contain an actor you cannot name.