Your Machines Have Identities Too, and Nobody Is Watching Them

The unguarded door is the one nobody thinks of as a door

Walk through any serious security programme and you will find a great deal of attention paid to people. Multi-factor authentication, joiner-mover-leaver workflows, access reviews, phishing training, privileged access management. All of it points at humans. Meanwhile, the machines have been quietly issued identities of their own, and almost nobody is watching them.

I am talking about non-human identities. Service accounts, application programming interface (API) keys, tokens, certificates, secrets baked into pipelines, and now the credentials handed to autonomous artificial intelligence (AI) agents. In most organisations these already outnumber the human staff, often by a wide margin. The exact ratio varies, and anyone quoting you a precise figure is guessing, but the direction is not in doubt. For every person who logs in, there are many machine principals acting on the network, day and night, without a face, without a desk, and usually without an owner who remembers creating them.

This is the unguarded door. Not because it is hidden, but because we never learned to see it as a door at all. We built an entire discipline around the human at the keyboard and treated everything else as plumbing. The plumbing now has hands.

Why machine identity is harder than human identity, not easier

The instinct is to assume machines are the easy case. They do not click on phishing links. They do not reuse passwords across personal accounts. They do not leave a sticky note on the monitor. So surely they are safer. The opposite is true, and it is worth being honest about why.

A human credential has a person attached to it. There is someone to off-board, someone to call when something looks wrong, someone whose access naturally lapses when they change roles or leave. A service account has none of that. It is created in a hurry to make a deployment work, granted broad permissions because narrowing them is fiddly, and then it lives forever. The engineer who made it moves on. The documentation, if it ever existed, rots. The secret gets copied into three pipelines and a wiki page. Years later it is still valid, still over-permissioned, and still completely unaccountable.

Machine credentials are also long-lived by design and frequently shared by convention. They sit in environment variables, in configuration files, in container images, in the chat history where someone pasted them to debug an outage at two in the morning. Rotation is painful, so it does not happen. The result is a standing population of powerful, forgotten keys that no audit ever truly captures. When attackers want persistence inside a network, this is exactly what they look for. A valid credential that nobody will ever notice going missing is worth more than any exploit, because it does not announce itself. It just keeps working.

Agents make the problem categorical, not incremental

Until recently, machine identity was a governance embarrassment but a contained one. Service accounts mostly did predictable, scripted things. You could reason about their blast radius even if you rarely did. Autonomous AI agents change the shape of the problem entirely.

An agent is a non-human identity that improvises. You give it a goal and a set of tools, and it decides, at runtime, which actions to take, in which order, against which systems. The credential is no longer wired to a fixed script. It is wired to a reasoning process that can read data, call other services, spend money, write to production, and chain steps you did not anticipate. The same properties that make agents useful, autonomy and breadth of reach, make them the most consequential non-human identities we have ever deployed.

And we are deploying them fast. The commercial pressure to put agents into real workflows, with real permissions, against real customer data, is intense. The governance to match has not arrived. We are handing improvising, tireless principals the keys to systems we cannot fully predict, and we are doing it with the same casual provisioning habits that gave us a decade of forgotten service accounts. The mistake is the same shape as before. The stakes are an order higher, because an agent does not just hold a key. It decides what to do with it.

The control point is authority at execution, not the login

Here is where I part company with most of the identity conversation. The industry keeps trying to solve this at the front door, at authentication. Prove who you are, get a token, and you are trusted thereafter. That model was already weak for humans. For machines and agents it is close to useless, because the interesting question is never simply who is acting. It is what they are permitted to do at the precise moment they do it, and whether that act was authorised, recorded, and reviewable afterwards.

A stolen API key authenticates perfectly. A compromised agent presents valid credentials at every step. Authentication tells you the door opened. It tells you nothing about what walked through, what it touched, or whether it was allowed to. The control point that actually matters sits one layer deeper, at execution. Before an action runs, is there authority for it? After it runs, is there a record that cannot be quietly edited to hide what happened?

Most systems fail both halves. Authorisation is checked loosely, if at all, once the session is open. And the logs, the supposed record of what the machine did, are written by the very system being audited, in formats anyone with sufficient access can alter or delete. An attacker who owns a service account usually owns the log pipeline too. The audit trail becomes a record of exactly what the intruder wanted you to see, which is no audit trail at all. It is a confession written by the suspect.

What a real answer looks like

If authority at execution is the control point, then governing non-human identity means treating every action, human or machine, as something that must carry its own proof. Not a log written after the fact, but authorisation bound to the act itself and a record that survives contact with a hostile insider. The proof has to travel with the action, not sit in a database the attacker can reach.

This is the principle we built the Mickai Sovereign Intelligence Operating System (SIOS) around, and specifically the Open Audit Record (OAR). The idea is simple to state and hard to fake. Every AI action is signed before it executes, not logged afterward. Each record is hash-chained to the one before it, so the sequence is append-only and any deletion or reordering is visible. The signatures are post-quantum, using the United States National Institute of Standards and Technology (NIST) standard FIPS 204 (the ML-DSA-65 scheme), so the proof does not expire the day large quantum computers arrive. And critically, the whole chain is verifiable offline, in an ordinary web browser, with no trust placed in Mickai as the vendor. You do not take my word that an agent behaved. You check the mathematics yourself.

That last point is the sovereignty argument, and it is not decoration. When the record can only be confirmed by the company that produced it, you have not solved accountability. You have relocated it. A non-human identity governed by a vendor-controlled log is governed in name only. The reason we anchor the audit root externally, through the Pantheon sovereign chain back to Bitcoin, is so that the truth of what an agent did does not depend on Mickai still existing, still being honest, or still being online. The signed record stands on its own. This is the one part of the system still being built, the Pantheon chain, with its fixed-supply token (PAN, five billion) and the audit root committed beyond any single party's reach. Everything else, the SIOS and the OAR, is live and in production today.

The clock is already running

None of this is hypothetical pressure. From August 2026 the European Union (EU) AI Act brings high-risk obligations into force, and a recurring theme across that regime and the broader direction of AI liability is the same demand. Show what the system did, and be able to prove it. Regulators are converging on accountability that does not rest on self-reported logs, because a self-reported log is precisely the thing a determined operator can rewrite. The post-quantum migration is happening in parallel, on its own timetable, which means audit records you create today need to stay verifiable a decade from now, long after today's signature schemes are considered breakable.

I will put it plainly. You can keep counting your human identities while the machine ones multiply unwatched, or you can decide that every actor on your systems, person, service account, or improvising agent, owes you proof of authority at the moment it acts. The first path is the comfortable one. It is also the unguarded door, standing open, exactly where nobody is looking. The second is harder to build and the only one that holds. We chose the second, and we sign every action to prove it. While we are at it, we own the engineering behind that choice outright: 101 filed United Kingdom patent applications, roughly 2,234 claims, held by Mickai LTD, with the work named to me as inventor. We are also training our own models now, fine-tuning and specialising open foundations and building toward fully native weights, because a sovereign record means little if the intelligence producing it is borrowed and unaccountable. Govern the machines, or they will govern you by default.