By Micky Irons, founder and CEO of Mickai.
Every autonomous agent needs a name and a set of keys. The name says who is acting; the keys let it prove that claim to a system that would otherwise refuse. In most artificial intelligence deployments those keys live in a file, or in an environment variable, or in a cloud key vault that some administrator can copy. That is the quiet weakness beneath a great deal of AI security architecture: the identity of the thing taking the action is portable, and anything portable can be stolen, cloned, or spun up on rented infrastructure a thousand miles from where anyone intended.
We build Mickai on a stricter premise. Identity and keys are bound to the operator's own hardware, so that only the right party, on the right machine, may cross into the systems that matter. In myth the crossing was governed by Charon, the ferryman who would not carry a soul across the river without the correct token in hand. Hardware-bound identity is our ferryman: no valid token, no passage, no matter how convincing the traveller appears. Mickai is a Sovereign Intelligence Operating System, a SIOS that is built and live, and this rule sits at its foundation.
The problem with portable machine identity
When an AI system authenticates itself, it usually presents a secret it holds in software. That secret can be read by whatever process has sufficient privilege, exfiltrated by malware, snapshotted along with a virtual machine, or lifted from a backup. The credential is a bearer token in the oldest sense: whoever holds it is treated as the rightful holder. For a regulated organisation running agents that can move money, alter records, or touch protected data, that assumption is untenable. An attacker who copies the key does not need to breach the agent at all. They simply become it, somewhere else.
The deeper issue is that software-held identity separates the actor from the place. A stolen key works equally well on the operator's server, on a compromised laptop, or on an anonymous cloud instance. There is no physical anchor, nothing that ties the act of authentication to a specific, attested piece of hardware the customer controls. Frameworks such as the European Union Artificial Intelligence Act (EU AI Act) and the Digital Operational Resilience Act (DORA) increasingly expect operators to demonstrate exactly where high-risk processing happens and who authorised it. A portable secret cannot answer that question honestly.
Like Cerberus at the gate, hardware-bound identity turns away every traveller who lacks the true credential.
Binding the key to the silicon
A Trusted Platform Module (TPM) is a dedicated security chip present in modern server and workstation hardware. It can generate a private key inside itself and, crucially, never let that private key leave the chip. Operations that need the key are performed by the TPM on request; the raw secret is never exposed to the operating system, to memory, or to backups. We anchor each Mickai identity in the operator's TPM, so the key that proves who an agent is cannot be copied off the machine it was born on.
This turns identity from a file into a property of the physical device. When a brain, a studio, or the runtime itself needs to sign an action, the signing happens inside the operator's silicon. Move the software to another box and the identity does not follow, because the key it depended on lives in a chip that stayed behind. An attacker who exfiltrates every byte of the deployment still cannot reconstitute the credential, because the one part they most need was never theirs to take. Identity stops being a thing you hold and becomes a thing the hardware performs on your behalf.
Only the right party may cross
Charon's rule was not about who was strong or clever. It was about who carried the correct token. Hardware-bound identity encodes the same logic. Before any subsystem in Mickai is permitted to reach a sensitive resource, it must prove its identity by exercising a key that only the operator's own TPM can wield. The proof is a live cryptographic operation, not a stored password, so it cannot be replayed from a captured copy.
Hephaestus forged in the mountain what could not be forged elsewhere, as a key born inside silicon can be born nowhere else.
We pair this with the Operation Attestation Record (OAR), which signs every action before it executes. The OAR names the acting identity, the intended operation, and the context, and it is committed to a tamper-evident, cryptographically-signed audit ledger. Because the identity in that record is anchored to hardware the customer holds, the ledger does not merely say that an action was authorised. It says which physical machine, under which attested identity, gave the order. That is the difference between a log an auditor must trust and a record an auditor can independently verify.
Post-quantum signatures for a longer horizon
Binding a key to hardware protects it from theft today. It does no good if the signature scheme itself is broken tomorrow. A signed audit ledger is meant to hold its meaning for years, sometimes decades, and an adversary who records signatures now may hope to forge them later once cryptography has moved on. We therefore sign with post-quantum algorithms: the Module-Lattice Digital Signature Algorithm, ML-DSA-65, standardised as Federal Information Processing Standard (FIPS) 204, over chains hash-linked with SHA-3-512.
The effect is that a hardware-anchored identity produces a signature expected to remain unforgeable against both classical and quantum attackers, and to be verifiable offline by anyone the operator chooses to show the ledger. A regulator, an insurer, or an internal audit team can confirm that a given action came from a given attested machine, without contacting us, without network access, and without trusting our word for it. The token Charon accepts is one nobody can counterfeit, now or later.
Argus of the hundred eyes never slept, as a signed ledger records and watches every crossing without rest.
High-stakes crossings demand more than one token
Not every action deserves the same scrutiny. Reading a document is not the same as approving a payment or exporting a controlled dataset. For the gravest operations we do not rely on a single hardware identity alone. Mickai can require multi-brain agreement combined with voice-biometric approval, so that a consequential act needs several independent attested identities and a living human voice before it will proceed. Any brain in that chain can be revoked the moment it is no longer trusted.
This layering matters for regimes such as the International Traffic in Arms Regulations (ITAR), the Health Insurance Portability and Accountability Act (HIPAA), and the Markets in Financial Instruments Directive II (MiFID II), where the question is rarely whether an action was possible and almost always whether it was properly authorised by the right combination of parties. Hardware binding gives each party a credential that cannot be borrowed. Multi-party approval ensures that no single stolen or coerced identity, even a hardware-bound one, can open the gate on its own. The ferryman, in effect, checks more than one token before the most dangerous passages.
Sovereignty by construction, not by policy
The public cloud giants are allies at a different layer, and we design to work alongside them. But there is a boundary they cannot cross on the customer's behalf: the regulated organisation that must keep its keys, its identities, and its most sensitive processing on hardware it physically owns, air-gapped or on-premise, with zero data egress. Mickai runs there by design. Because identity is bound to the operator's TPM, sovereignty is not a contractual promise that could be quietly renegotiated. It is a physical fact of where the keys live.
Atlas bore the weight on his own shoulders, as sovereign identity rests on hardware the operator alone holds.
That construction is reflected in our filings. Across 104 filed UK patent applications and about 2,340 claims owned by Mickai LTD, the capabilities described here, hardware-anchored identity, pre-execution attestation, post-quantum signed ledgers, and multi-party revocable approval, are set out as an integrated system rather than a collection of features. The intent is that sovereignty holds even under adversarial conditions, because it is enforced by cryptography and silicon rather than by trust in an operator's good behaviour.
The bottom line
An AI identity you can copy is an AI identity someone else can become. By binding keys to the operator's own TPM, signing every action with an Operation Attestation Record, and sealing the record in a post-quantum, offline-verifiable ledger, we make identity a property of the customer's hardware rather than a portable secret. Only the right party, on the right machine, may cross. Charon would recognise the arrangement: present the correct token, forged by no one, held by the chip that never lets it leave, or the passage simply does not open.
Written by Micky Irons. Originally published at https://mickai.co.uk/articles/tpm-bound-ai-identity. More from Micky Irons and Mickai at mickai.co.uk.
Top comments (0)