Agent Identity Should Be Issued, Not Federated

An AI agent's identity should be issued by the organisation that carries the consequences of its actions, not borrowed from an outside issuer. In Mickai, each organisation holds its own signing key and its own ledger, so every agent action is attributed to a named seat and sealed into the Open Audit Record, an append-only, hash-chained, tamper-evident log. Anyone can verify that record cold and offline with the operator public key alone. Revocation is decided and applied locally, so it takes effect on the machine itself instead of propagating from an outside issuer on somebody else's schedule.

• Federated identity means the proof of who acted rests on an assertion made by somebody else's infrastructure.
• Issued identity keeps the signing key, the seat register and the ledger inside the organisation that bears the liability.
• Seats grant or revoke studios individually, so access narrows precisely instead of the whole system going dark.
• Licences bind to hardware, so a copied credential is inert on a machine that was never entitled to it.
• Every consequential action is staged for a human to approve or refuse before it runs.
• Each Open Audit Record entry carries index, timestamp, actor, typed action, target and a SHA-256 of its payload, signed with FIPS 204 ML-DSA.

What is the difference between issued identity and federated identity?

Federated identity means an outside issuer vouches for who acted. Your log does not hold the fact of the action; it holds a claim a third party made about it, and that claim is only as good as that party's key hygiene, availability and controls. When the issuer is compromised, every downstream assertion inherits the compromise.

Issued identity inverts that. The organisation mints identity itself, holds the signing key on hardware it owns and writes attribution into its own ledger, so the proof lives in the same place as the liability. Nothing outside the building is reached or trusted to establish who did what, which is why Mickai runs fully offline over loopback only, with no outbound path by default.

Why isn't a shared service account enough for an AI agent?

Agents act without the pauses a human workflow imposes: no handover, no queue, no colleague glancing at the screen on the way past. The shortcut is to let them act under a pooled service account or a human's borrowed session. Both produce a log that is technically complete and evidentially useless: it names a credential nobody owns, or a person who was asleep when the change landed.

Attribution has to be typed and per action. Every Open Audit Record entry carries an actor field that names the seat under which the agent acted, alongside the typed action, the target and a SHA-256 of the payload. An incident review asks which agent, under whose authority, changed this record and when. An identity that cannot answer that is not an identity. It is a login.

How do you revoke an agent's access without shutting the whole system down?

Through seats. Mickai runs 63 studios in total, 14 production-ready and 49 in development, and a seat grants or revokes each of them individually, rather than through one blunt switch attached to a directory group. An agent can hold exactly the studios its work requires, and lose one of them without losing the rest.

Revocation is itself a consequential action, so it is staged for a human to approve and then written into the ledger as an entry like any other. The authority never left the organisation, so the change is applied on the machine rather than requested from an outside issuer and waited on. What remains is a signed, ordered trace of who removed what and when.

What proves an agent did exactly what the record says?

The chain does, as far as key custody allows. Each Open Audit Record entry is hashed and linked to the one before it, and the record is signed with FIPS 204 ML-DSA, the post-quantum signature standard. FIPS 203 ML-KEM is key encapsulation and never signs anything, a distinction that matters because an audit claim built on the wrong primitive is not an audit claim. The record is append-only and tamper-evident: it does not stop an attempt, it makes the attempt visible to anyone who verifies. An alteration that is not re-signed with the operator key breaks the chain and fails verification against the operator public key.

That is why the property rests on key custody, and why no honest supplier claims a log is beyond alteration. Someone holding the operator signing key could rewrite entries and re-sign them, which is why signed checkpoints written off the box, together with anti-rollback, are what make truncation and wholesale replacement detectable. Defend the key, and the record carries the rest.

Determinism closes the loop. Deterministic engines produce every number, so identical inputs give identical results and a reviewer can rerun what the record names rather than take an output on trust. Verification is deliberately unglamorous: the record and the operator public key, cold and offline.

What happens when the issuer is unreachable, or a credential is copied?

In a federated model an issuer outage is an authority outage. Work stops, or someone widens a fallback path to keep going and the audit trail quietly degrades. Because Mickai issues identity locally and runs offline over loopback only, there is no external issuer to be unreachable and that failure mode does not arise.

Copied credentials are handled by binding. Licences bind to hardware, so an entitlement lifted from one machine does not activate on another. Combined with staged approval, an attacker holding a stolen secret still faces a machine that will not recognise it and a human who has to press approve.

Frequently asked questions

Can I keep my existing single sign-on for people?

Yes. Single sign-on can carry on handling people signing in. What it should not do is stand as the proof of who acted when an agent changes a record. That attribution is issued by the organisation itself and written into its own ledger, so it never depends on an outside issuer at the moment of the action.

How do I revoke one agent without disrupting my team?

Revoke the studios on that seat. Entitlement is per seat and per studio, so the change is surgical rather than organisation-wide. A human approves it and it is written into the Open Audit Record, so the removal is as auditable as the original grant.

What can an external auditor check without access to my systems?

Given an exported Open Audit Record and the operator public key, an auditor can verify the hash chain and the signatures entirely offline, and confirm the order and integrity of every entry against that key. No connection to Mickai and no credential from us is required at any point.

Are the Mickai patents granted?

No. Mickai LTD owns 104 filed UK patent applications covering approximately 2,340 claims, and those applications are working towards examination. We say so plainly because the difference between filed and granted is exactly the kind of claim a buyer should be able to check.

How do I see this working in my own environment?

Mickai is in selective closed beta and applications are open at mickai.co.uk/beta. Selection is deliberate rather than first come first served, because early deployments are chosen where the identity, attribution and revocation questions above genuinely bite.