Identity Is the First Problem a Multi-Agent System Hits
Give one agent one task and identity barely registers. The agent runs inside a process you control, calls a tool with a key you issued, and the question of who it is never comes up. The moment a second agent appears, and especially the moment agents start invoking each other across systems owned by different teams, that quiet assumption breaks.
Now the questions arrive at once. Which agent is calling? Is it the one it claims to be? On whose authority is it acting? When the work is done, who can prove which agent did what? These are not model questions. They are identity questions, and a multi-agent system cannot enforce authority, respect boundaries, or attribute actions without answering them first.
In the Covia Grid, every agent carries a decentralised identifier. This post explains what that is, why the alternatives fail at scale, and what portable cryptographic identity makes possible across the synthetic workforce.
What a DID Actually Is
Most identity systems people know are registry-based. A central authority issues an identifier, holds the record of who owns it, and answers when someone asks whether it is valid. Usernames, API keys, and OAuth clients all work this way. There is a database somewhere, run by someone, and identity means having a row in it.
That model has a structural cost. The registry is a single point of trust, a single point of failure, and a single point of control. Everyone who wants to verify an identity has to be able to reach it and has to trust whoever operates it.
A decentralised identifier, or DID, is an identifier that a subject can create and control without a central registry, backed by cryptographic keys rather than a database row. A DID resolves to a small document listing the public keys and methods needed to verify that the holder controls the identifier. Control is proven by a signature that anyone can check against the published key. No issuing authority sits in the path. No central database has to be online for verification to work.
The practical consequence: an agent can hold an identity that is genuinely its own, prove that identity to any counterpart, and do so without asking a shared authority for permission at the moment of proof. The identity travels with the agent instead of living in someone else's system.
Why Do Registry-Based Identities Break Down for Agents?
It is fair to ask why agents need anything new. Human-facing identity has run on central registries for decades. Why should a synthetic workforce be different?
Scale and topology. Consider what a busy multi-agent system looks like. Agents are created and retired constantly, sometimes in seconds. They act on behalf of chains of other agents and humans. They cross organisational lines, invoking capabilities that live in systems the calling team does not own. The volume of distinct actors is orders of magnitude higher than any human directory was built for, and the trust relationships do not fit inside one company's boundary.
A central registry buckles here on several fronts.
It becomes a bottleneck. Every verification is a call to the same authority, and that authority sits on the critical path of every cross-system action.
It becomes a trust problem across boundaries. When an agent in one organisation calls a capability in another, whose registry is authoritative? Neither team wants to depend on the other's database being correct and available.
It becomes an attribution gap. Registry identities are easy to reassign and hard to prove after the fact. When you need to establish which agent performed an action weeks later, "it was authenticated at the time" is a weaker claim than a signature that still verifies.
Decentralised identity dissolves these problems by removing the shared authority from the verification path. Each agent proves control of its own identifier cryptographically. Verification is a local check of a signature, not a remote call to a registry that has to be reachable and trusted.
Identity as the Root of Authority
Identity on its own is only an answer to "who is this." The reason it matters so much in the Grid is that everything downstream of authority hangs off it.
An agent's DID is the anchor for what that agent is permitted to do. The authority model, expressed through a rule book, is written against identities. The execution limits an agent operates within, expressed as boundaries, are enforced against a verified identity. Attribution after the fact resolves back to the identity that signed the request. If the identity layer is weak, every layer above it inherits that weakness, because a permission granted to an identity that cannot be reliably proven is a permission granted to no one in particular.
This is where DIDs and scoped authority meet. A DID establishes who an agent is. A capability token establishes what that specific identity is allowed to do, and for how long, without handing over standing credentials. We covered that mechanism in UCAN tokens and scoped authority; the relevant point here is that such tokens are issued to and signed by DIDs. Identity is the subject that authority is granted to. Take the identity layer away and scoped authority has nothing solid to attach to.
Crossing Boundaries With Verifiable Trust
The hardest case in a multi-agent system is the cross-boundary call: an agent in one venue invoking a capability that lives in another, across an organisational or trust line.
A boundary is an execution limit that separates one trust domain from another, and you can read the fuller definition in the Covia glossary. Boundaries are where central-registry identity is least workable, because the two sides do not share an authority and have no reason to trust each other's internal records.
Decentralised identity is built for exactly this crossing. When an agent presents a request across a boundary, the receiving side does not need to consult the sender's home registry or trust the sender's organisation to have authenticated correctly. It verifies a signature against the DID's published keys. The identifier is portable, so the same identity that meant something in the agent's home venue means the same thing on the other side of the boundary. Trust is established by cryptography that either side can check independently, rather than by a shared system both sides have to rely on.
This is what lets the Grid extend across organisations without collapsing into a single administrative domain. Each participant keeps its own identity, proves it directly to whoever it interacts with, and carries that identity intact wherever its work takes it.
Attribution That Survives the Event
Coordination is not only about permitting actions in the moment. It is about being able to establish, afterward, what actually happened. In a system where dozens of agents act across multiple venues, attribution is a real operational requirement, not a compliance afterthought.
DIDs make attribution durable because they make it cryptographic. When an agent acts, the action is tied to a signature from its identifier. That linkage does not depend on a log that could have been edited or a registry entry that may since have been reassigned. Months later, the same public key still verifies the same signature, and the action still resolves to the identity that produced it.
For anyone operating a synthetic workforce under real accountability, this is the difference between a record you can stand behind and one you can only describe. The identity that acted is provable from the artefact of the action itself.
What DIDs Give the Grid
Put together, decentralised identity gives the Grid a foundation with a specific shape. Each agent holds an identity it genuinely controls. That identity is verifiable by anyone without a central authority in the loop. It is portable across venues and boundaries. It anchors the authority an agent is granted and the limits it operates within. And it produces attribution that outlives the moment of action.
None of this requires a registry that every participant has to trust and keep online. That is the point. A coordination substrate meant to span organisations cannot rest its identity layer on a database owned by one of them.
The design question this leaves open is worth sitting with. As the number of agents acting on your behalf grows from a handful to thousands, and as they start reaching across lines your systems do not control, what does it take to still be able to prove, cleanly, exactly which one did what? If the honest answer is a database and a hope that it was current, the identity layer is already the weakest part of the system.