Singapore Wrote the First Rulebook for AI Agents. It Asks the Question We Already Answer

By Micky Irons

In January 2026, Singapore's Infocomm Media Development Authority did something no other regulator had done cleanly. It published the first comprehensive governance framework written specifically for agentic AI. Not chatbots. Not model risk in the abstract. Agents. Software that plans, decides, and acts on its own initiative inside real workflows, often without a human reading each step before it happens.

The framework is worth reading in full, but one requirement cuts to the centre of everything. Every agent must carry a verifiable digital identity, and every deployment must keep an audit trail of which agent acted and under whose authorisation. That is the question. Who is this agent, and who told it it could do that?

Most of the industry cannot answer it. We can, because we built Mickai around answering it before anyone asked.

Why agent identity is the whole game

For a decade, enterprise identity meant human identity. A person logs in, a system checks who they are, and their actions get attributed to a name. That model quietly assumed the actor at the end of the chain was a person accountable to an employment contract and a legal system.

Agents break that assumption. An autonomous agent can open a ticket, move money, query a patient record, or reconfigure a firewall in the time it takes a human to blink. When something goes wrong, and in regulated workflows something eventually does, the first question is never "what happened". It is "who did this, and were they allowed to". If the answer is a shrug, a log file that anyone with admin rights could have edited, or a vendor's assurance that their platform is trustworthy, you do not have accountability. You have a story.

IMDA's framework refuses the story. It asks for a verifiable identity per agent and a record of the authorisation chain. That is a materially higher bar than "we keep logs". Verifiable means you can prove it to a third party who does not trust you. Authorisation chain means you can show not just what the agent did, but the human or policy that granted it the standing to do it.

Asserted identity versus enforced identity

Here is the distinction that most agentic platforms blur, and the one that decides whether an IMDA-style requirement is actually met.

Asserted identity is when a system tells you an agent's identity. The platform says "this was Agent 7, acting for user Jane, under policy X". You either believe it or you do not, because the same platform that ran the agent also wrote the record, controls the storage, and can change both. In a cloud service you do not own, asserted identity is the ceiling. The provider can give you a beautiful dashboard, and you still cannot prove to your regulator that the record was not touched.

Enforced identity is when the identity and the authorisation are bound cryptographically to the action at the moment it happens, and the record is signed so that any later alteration is detectable. You are no longer asking anyone to be trusted. You are checking a signature. That is the difference between a framework requirement you can gesture at in a policy document and one you can defend in an audit.

The uncomfortable truth for the industry is that you cannot enforce identity on infrastructure you do not control. If the substrate belongs to someone else, your attestations are only as strong as their goodwill and their access controls.

What we built, and why it sits inside your walls

Mickai is a Sovereign Intelligence Operating System. Regulated organisations own it and run it inside their own perimeter, air-gapped where the workload demands it, with a cryptographically-signed audit record written on every action the system takes. That last clause is not a feature we bolted on for this article. It is the design premise. Every action carries the actor, the authorisation, and a signature, and the record is built to make tampering evident rather than convenient.

When an agent inside Mickai acts, the record answers IMDA's question directly. Which agent. Under whose authorisation. With a signature that a party who trusts neither you nor us can verify independently. On-chain attestation is available as a supporting capability where an external anchor helps, but the substance lives in the signed record itself, on infrastructure you own.

This is not just how the product behaves. It is what our intellectual property describes. We have 104 UK patent applications on file, roughly 2,340 claims across 13 families, with Mickarle Wagstaff-Irons named as inventor, and the signed record of actor and authorisation on every action sits at the heart of what those filings cover. We are building toward examination and grant, and the substance we filed is exactly the mechanism a framework like Singapore's now asks every deployment to demonstrate.

Ownership is the part that makes the guarantee real. When you run the system, you hold the keys, you hold the logs, and no vendor sits between you and your own evidence. A regulator asking Singapore's question does not get a vendor's assurance. It gets your record, signed, and independently checkable. That is what enforceable looks like.

This is a preference the whole market is moving toward

I want to be honest about the regulatory landscape, because over-claiming helps no one. Almost every major regime, DORA, the FCA and PRA regimes, EBA guidance, the NHS Data Security and Protection Toolkit, GDPR, permits cloud with the right controls. There is no blanket legal bar on running AI in someone else's data centre. The genuine no-cloud line is workload-level. It covers classified material, ITAR-controlled data, isolated operational technology, and cases where a data protection impact assessment comes back negative. Everywhere else, the choice is yours.

What is moving, and moving fast, is preference. Organisations increasingly want control over their data, defence against exfiltration, and predictable cost, and they are choosing sovereignty for reasons that have nothing to do with prohibition. The register-backed sovereign market we serve is roughly 16,092 institutions across the UK and EU, made up of 7,933 regulated core organisations plus 8,159 large private adjacent ones. Verdantix sizes the enterprise AI platform software market at USD 13bn in 2024, rising to USD 50.3bn by 2030, which is roughly £11.7bn to £39.7bn. Agentic governance requirements like IMDA's accelerate that shift, because the moment a regulator asks you to prove agent identity, owned infrastructure stops being a philosophical stance and becomes the practical way to answer.

The takeaway

Singapore did not invent a new problem. It named an existing one precisely and asked everyone deploying agents to solve it. Every agent needs a verifiable identity. Every action needs a traceable, provable line back to the authority that permitted it. Frameworks in other jurisdictions will converge on the same requirement, because it is the only version of accountability that survives contact with autonomous software.

We did not scramble to meet this. We built Mickai so that a signed record of every action and every actor is what the system does at rest. When the question is "which agent acted, and under whose authorisation", the honest answer for most platforms is a promise. Ours is a signature, on infrastructure you own, that a regulator can check without trusting anyone in the room.

Frequently asked questions

Does the IMDA framework legally require sovereign or on-premises AI?

No, and we will not pretend otherwise. IMDA's framework requires verifiable agent identity and an authorisation audit trail. It does not mandate where the system runs. Our argument is narrower and, we think, harder to dispute. Identity you can enforce and prove to a third party is far easier to guarantee on infrastructure you own than on a service you rent. Ownership is how a preference becomes a proof.

How is a signed audit record different from ordinary logging?

Ordinary logs record what happened and can usually be edited by anyone with sufficient access, which is exactly the wrong property when the log is your evidence. A signed record binds the actor and authorisation to the action cryptographically, so any later alteration is detectable. Logs tell a story. Signed records let a party who does not trust you verify it.

Can you attach identity to agents built on models we already use?

Yes. Identity and authorisation are enforced at the substrate level, around the action, not inside any particular model. Agents you deploy inside Mickai inherit the signed record regardless of which underlying capability they call, which is what lets the accountability guarantee hold across a mixed fleet.

Where does on-chain attestation fit?

It is a supporting capability, not the foundation. The core guarantee is the signed record on infrastructure you own. Where an external anchor adds value, on-chain attestation provides one, but the accountability stands on its own without it.

---

If this is the problem in front of you, three related pieces go deeper. Read our writing on why the signed audit record is the load-bearing part of sovereign AI, our take on air-gapped deployment for regulated workflows, and our analysis of why owned infrastructure changes what enterprises can promise their regulators. Mickai is built, it is live, and it already answers the question Singapore just made everyone ask.