Cryptographic agent identity: Ultra's separate authority plane

A financial regulator in Frankfurt knocked on a bank’s door in early 2026 asking a simple question: which of your agents approved that wire transfer? The bank had a perfectly reasonable agentic automation stack. Orchestration layer, vector store, a language model, a Python integration. The agent had done its job. The transfer had gone through. Somewhere in a pile of application logs was a line that said something like action: approve_transfer, status: ok. No agent identity. No signing key. No provable chain from that log entry back to a specific, registered, inspectable actor.

The regulator accepted the explanation and left. This time. The team spent the following month wondering what they would say if the question came again after something had gone wrong.

That is the scenario Ultra was built for.

The problem is structural, not cosmetic

When you bolt an agent onto an existing application, the agent inherits the application’s credentials. It acts as the application. Sometimes as a service account. Sometimes literally as the developer who set up the integration and whose personal OAuth token is buried in the configuration. The application’s audit log records an action, but the log was designed to track human sessions. It has no concept of an agent, no lifecycle for one, and no mechanism to verify that the identity attached to a log entry is what it claims to be.

This matters more than most teams realise until something goes wrong. The audit trail is not just a compliance checkbox. It is the thing you hand to a regulator, an auditor, or a court when you need to answer “who did this, when, under what authority, and can you prove the record has not been altered?” A log file with a service account name does not answer that question. Logs can be edited. Service accounts are shared. The identity attached to an action in most agent stacks today is not provable.

In a governed dark factory, the problem is more acute still. The whole premise of Substrate is that you declare a mission and a hard budget, a swarm of governed agents plans, writes, tests, reviews and ships it, and every action is signed and auditable by construction. That “signed and auditable by construction” claim is not something you can bolt on later. It requires a dedicated authority plane that exists separately from the application layer, that every agent in the swarm must pass through, and that cannot be bypassed.

That plane is Ultra.

What cryptographic identity actually means

The phrase gets thrown around. “Ed25519 signing” appears in a lot of product decks. It is worth being precise about what it means in practice, because the difference between doing it properly and doing it cosmetically is exactly the difference a regulator or an internal audit will find.

An Ed25519 keypair is an asymmetric cryptographic key. The private key lives with the agent. The public key is registered with the authority. When an agent acts, it signs the action with its private key. Anyone with the corresponding public key can verify that signature, and no-one without the private key can produce a valid one. The signature covers the content of the action, so altering the record after the fact breaks the signature.

That is the primitive. What Ultra builds on top of it is an identity lifecycle.

Every agent in the factory begins its existence with a registration event. Ultra issues a unique identity. That identity has a state machine: registered, active, suspended, revoked. State transitions are themselves signed events in the log. If an agent’s private key is compromised, the identity is revoked, and any subsequent action claiming to originate from that agent fails verification at the boundary. Fake identities, agents presenting keypairs that are not in the pre-registered set, are rejected before they reach the factory floor.

The lifecycle matters as much as the signing. A system that signs actions but never revokes identities has a large hole: a compromised agent key can act indefinitely. A system that revokes identities but cannot prove the revocation was not backdated has a different hole. Ultra’s append-only log covers both: the revocation event is in the chain, timestamped, signed by the authority, and any subsequent action signed by the revoked key is verifiable as post-revocation. No revision is possible without breaking the chain.

Interactive: hover each block to inspect the signed fields. Toggle “simulate tamper” to see how altering one block immediately breaks verification for every downstream block in the chain.

How the log is constructed

The log is not a table in a database. A table can be edited by anyone with the right database credentials. An append-only, tamper-evident log has a specific construction: each entry’s signature covers not just the content of that entry but the hash of the previous entry. This is a hash chain, the same structure that underpins Bitcoin’s ledger and the W3C’s linked data proofs, though Ultra’s implementation is oriented toward agent action provenance rather than financial settlement.

The consequence is precise. To tamper with any entry in the chain, you must also update every entry that follows it, recomputing the hash chain and re-signing each entry with the original private key. Without the private key, you cannot produce a valid chain. With the private key, you can, but the signing key’s usage is itself logged in the authority plane. A forensic investigator looking at the log does not need to trust that nobody tampered with it. They can verify the chain from first principles and detect any break.

Each entry in the Ultra log covers the agent identity, the action taken, the tool or capability invoked, the policy in effect at the time of the action, the input hash, the output hash, and whether a human gate was present. This is not aspirational. These are the fields required by Article 12 of the EU AI Act for high-risk systems, which mandates automatic logging of events over the lifetime of the system with a minimum six-month retention period and extended retention for some categories. The August 2026 enforcement deadline is drawing close, and most current agent stacks will not produce a log that satisfies these requirements (source: EU AI Act, Regulation (EU) 2024/1689, Article 12 and Annex III).

The DORA operational resilience framework imposes its own logging demands on financial services: detailed records of ICT-related incidents, testing results, and the decision chains that led to changes in critical systems. An agent that changes a financial record and leaves only an application log entry is not DORA-compliant. An agent with a cryptographic identity, acting under a signed policy, with its action committed to a hash-chained log that can be replayed to reconstruct the decision, is.

Where Ultra sits in the factory

The name “authority plane” is deliberate. Ultra does not sit inside the application or inside the agent runtime. It is a separate layer, and every agent in the factory must pass through it to act. The analogy is a passport control rather than a security camera: the camera records who was present, but the passport control enforces identity at the boundary before anyone enters.

Interactive: click each layer to inspect its role. Toggle “air-gap mode” to see which layers continue running when external providers are offline. Ultra operates entirely within the walls and is never affected by external outages.

When Ninmu, the swarm conductor, dispatches a task to an agent, Ultra is in the path. The agent presents its identity. Ultra verifies against the registry. If the identity is active and authorised for the requested capability, the action proceeds and is logged. If the identity is revoked, suspended, or simply not registered, the action is rejected at the boundary. The agent never reaches the tool, the data, or the external system it was trying to contact.

This separation is why Ultra can provide guarantees that a monitoring layer bolted onto the outside of an existing agent framework cannot. A monitoring layer watches what happens. An authority plane controls what is allowed to happen, and the log of what it allowed is authoritative precisely because nothing can act without passing through it.

Connecting Ultra to the rest of the factory

Cryptographic identity means little in isolation. Its value is that it propagates through every system the factory touches, binding each system’s outputs to the identity of the agent that produced them.

Kizuna, the AI-native source control system, accepts commits from agents as first-class signed artifacts. The agent identity from Ultra is the signing identity in Kizuna. A commit’s provenance chain runs from the Ultra registry through the Kizuna forge, so you can follow a line of code back to the specific agent version that wrote it, the mission it was executing, the policy it was operating under, and the human gate (if any) that approved the merge. This is what makes the supply chain defensible: not that a developer reviewed the code, but that the review was itself a signed event in a chain you can reconstruct.

Cosmictron, the live data and agent runtime plane, records state changes deterministically. Each state transition is associated with the agent identity that caused it. When Cosmictron’s deterministic replay is invoked, whether for debugging, for a compliance investigation, or for answering a regulator’s question about a specific transaction, every replayed event carries its originating identity. The replay does not reconstruct a plausible sequence of events. It reconstructs the actual sequence, cryptographically bound to the identities that executed it.

Ninmu’s signed mission history closes the loop. Each mission in the factory produces a signed record: the mission declaration, the budget ceiling, the task decomposition, the routing decisions, the human gates that were triggered, and the final artifact. The signed mission history ties all of this together. You can take any mission in the factory’s history and produce a complete, verifiable account of what was decided, who decided it, what each agent was authorised to do, and what it actually did.

This integration is why the six systems as one factory claim holds. Any single component in isolation is useful. Ultra’s signing without Cosmictron’s replay is a signed log you cannot fully interrogate. Cosmictron’s replay without Ultra’s signing is a sequence of events you cannot verify was not altered. Kizuna without Ultra is a source forge with bot accounts. The compound property, a governed factory where every action is signed and auditable by construction, emerges from the integration, not from any one system.

Why OAuth bot users are not the same thing

The common counter-argument is that OAuth “bot users” already give agents a separate identity. This is worth addressing directly, because the distinction matters for anyone evaluating agent platforms for regulated use.

An OAuth bot user is an account. It has a username, a set of permissions, and an access token. The token is typically a string of characters that can be copied, can expire, can be refreshed, and is stored somewhere a developer can retrieve it. If you know the token, you are the bot user, at least as far as the application is concerned. There is no cryptographic proof of possession. There is no lifecycle in the sense of a state machine with signed transitions. There is no tamper-evident chain binding the bot user’s actions together. The log records that the bot user did something, but it cannot prove that the actual entity holding the token at the time was the intended one.

More practically, bot users are typically configured by humans. A developer creates the account, generates the token, and puts it in the infrastructure. When the developer leaves, someone may or may not rotate that token. When the integration breaks, someone creates a new bot user with a fresh token. The lifecycle of the credential is manual, informal, and very often not recorded anywhere.

Ultra’s agent identities are registered, not configured. The registration is an event in the authority log. Suspension and revocation are events in the authority log. The private key never leaves the agent process, so there is no token to copy. The comparison is not “better OAuth” but a different class of solution: cryptographic identity versus credential management.

The sector where this is non-negotiable

Consider a healthcare setting. An agent system is used to process clinical coding, match diagnoses to billing codes, and route edge cases to human reviewers. The system makes decisions that affect patients: whether a claim is submitted, whether a denial is generated, whether a case is escalated. These are decisions under HIPAA, under 21 CFR Part 11 for electronic records in clinical contexts, and under emerging EU AI Act obligations if the system operates in Europe.

When a patient challenges a denial, the answer “the system made that decision” is not acceptable. The answer that is acceptable is a specific account of which version of which agent, operating under which policy, made which determination, at what time, and what information it had access to. That account must be producible, and it must be verifiable. If it cannot be verified, it is not evidence.

Before Ultra, that account requires the operations team to reconstruct it from multiple log sources, hope that none of the logs have been rotated or overwritten, and accept that the reconstruction is based on correlation rather than proof. With Ultra, the account is the log. It is a single chain you can walk from the patient’s claim through every agent action that touched it to the final decision, verifiable from first principles.

The same argument applies to financial services, to government eligibility decisions, to AML investigations. Anywhere an agent can affect a person’s money, health, housing, or legal standing, the ability to produce a verified account of what happened is not optional. It is the minimum requirement for being allowed to operate at all.

The before and after in regulated finance

A tier-two bank is running a pilot to automate its DORA operational resilience testing programme. The programme requires regular stress tests of critical ICT systems, signed evidence packs showing what was tested and what the outcome was, and a record of any human decisions made during the process.

Before: a team of three analysts runs the tests manually over several days. They capture screenshots, write up notes, assemble a Word document, and have the programme lead sign it off. The evidence pack is defensible to the regulator but expensive to produce. The cost is roughly three analyst-weeks per quarter. The audit trail quality depends on whoever was most diligent about their notes.

With Substrate: the mission is declared. Ninmu decomposes the programme into test scenarios. Each scenario runs as an agent task, acting under a signed policy that specifies exactly what testing is permitted. Ultra verifies each agent’s identity before it acts. Every action is committed to the log. Human gates surface the scenarios that require analyst sign-off, with full context presented to the analyst and the approval itself recorded as a signed event. The evidence pack is assembled from the log, not reconstructed from notes. It is audit-ready by construction: every entry in the pack has a provenance chain back to the agent that produced it and the human that approved it, verifiable by any party with the public keys.

The cost difference is illustrative rather than a precise figure from a live deployment. The quality difference is structural: the manually assembled pack is good enough if nothing goes wrong. The factory-assembled pack is verifiable whether or not anything goes wrong, which is exactly what you want when a regulator is asking the questions.

What to demand in an RFP

If you are evaluating agent platforms for any regulated use case, the identity question separates real systems from configured monitors. Here is what to ask.

Ask whether agent identities are cryptographic or credential-based. If the answer involves tokens, API keys, or OAuth service accounts, you are looking at a credential. Ask how identity state transitions (suspension, revocation) are recorded, and whether those records are in the same tamper-evident log as the action records. If they are in a separate system, ask how you verify that the revocation was not backdated.

Ask to see a verification demonstration. Not a dashboard showing that an agent acted. A chain verification: take a specific action log, ask the system to prove that the chain has not been altered since the action was recorded. If the system cannot do this, the audit log is not tamper-evident by the meaning of the term.

Ask what happens to the log during a provider outage. If the log is held by a third-party SaaS observability platform, it is outside your walls. A regulator asking for your records will be asking for records you do not directly control. Ultra’s log is sovereign by default: it runs within the customer’s own infrastructure, consistent with the sovereign by default operating model across the whole factory.

Ask how the agent identity integrates with your source control and your deployment pipeline. If the answer is that the agent commits to GitHub using a bot account with a human’s token, you do not have a signed supply chain. You have a developer’s access permissions assigned to a bot. The deterministic replay as the audit trail article covers what a real signed supply chain looks like at the execution level, and Kizuna: GitHub reimagined for agents covers what it looks like at the forge level.

Ask whether the system was designed with identity as a first-class property from the beginning, or whether it was added later. The answer reveals a lot. Identity, like governance and cost control and audit, is one of the hard properties that cannot be retrofitted into a system that was not designed for it. It is part of the 80 per cent that glue stacks structurally cannot reach.

A 90-day proof

You do not need a full production deployment to verify these properties. Pick a mission that has a clear audit requirement and a clear before state. A quarterly compliance report. An operational resilience test. An AML case review with a known sample set.

Run it under Ultra. At the end, take the log and perform a chain verification: prove that no entry has been altered since it was committed. Then ask your existing audit evidence pack team to produce a comparable verification for their last manually assembled pack. The comparison is the whole argument in miniature. One system produces a log whose integrity you can prove. The other produces a document whose integrity depends on who was paying attention.

Three things to check at the end of the 90 days. Did every agent action carry a signed identity that you can trace to a specific registered agent version? Did any revoked identity successfully complete an action? (The answer should be no, and you should be able to verify it from the chain.) And can you produce the full signed record for any action in the mission without reconstructing it from correlation across multiple log sources?

If all three pass, you have a factory floor that can operate in regulated environments. If they do not, you have learned something important before you committed to production.

The signed identity, the tamper-evident log, and the authority plane that enforces both are not features you activate when you need them. They are the floor the factory is built on. Everything auditable by construction that Substrate promises begins here.

If you want the full technical design and the investment case, including how Ultra integrates with the other five systems across finance, healthcare, and government deployments, you can request the investor brief. If you are working through the EU AI Act compliance picture specifically, the EU AI Act Article 12 explainer covers the logging obligations in detail. And if you are thinking about the memory provenance side of the same problem, provenance, not recall, is the differentiator picks up from where this article leaves off.