Agents Need an Identity. DID May Be the Best Place to Start

DID can anchor identity; authorization and runtime proof still need design.

Agents will need identities of their own. I do not mean assigning every process a UUID, or giving an API key a better name. An agent that acts for a person or an organization should be able to answer a few basic questions: who controls its long-lived identity, who authorized this action, whether this running instance is the approved one, and whether its authority can be withdrawn when something goes wrong.

Most agents today are still features inside somebody else's product. They read a few environment variables, call a few tools, and disappear when the process stops. A platform can give them an account, a token, and an audit log. That is convenient inside one system. It stops being enough when an agent moves between clouds, changes model providers, works across organizations, or takes actions with consequences. A platform account can say what that platform calls the agent. It does not necessarily say who the agent is, who it represents, or where its authority came from.

My view is simple: an agent's root identity should not be permanently owned by one platform, and an agent's real authority should never be self-declared. The first requires a portable identity anchor that its controller can prove control over. The second requires explicit delegation, scope, expiry, revocation, and audit. DID is probably the best open standard for the first layer. It is not an answer to everything that follows.

Identity is not an account, and it is not a master key

The human internet ran services first and slowly added login, permissions, and recovery later. Early personal computers simply booted into one user. Nobody worried much about multiple users, machines talking to one another, or permission boundaries. Once networks and services became the normal way to work, stolen accounts, closed accounts, and data trapped with a provider stopped being edge cases.

The agent version will move faster. A stolen human account may send phishing email. An agent with access to deployment, purchasing, devices, or sensitive data can make many bad calls in a short time. NIST launched its AI Agent Standards Initiative in 2026 and explicitly includes agent identity, authorization, and security in its work. The question is no longer whether an agent needs to log in. It is whether the relationships among people, organizations, agents, and resources can be seen, constrained, and traced. ^[1]

There is an easy mistake here. Identity control does not mean an agent gets to authorize itself. An agent may control an identifier, but that does not prove it may spend money, release production code, or sign for a company. Control of a key proves control of a key. It is not a business authorization.

DID is an anchor, not a universal proof

W3C DID Core became a Recommendation in 2022. It defines a resolvable identifier and its DID Document. That document can contain verification methods and service endpoints. A DID subject may be a person, organization, device, data model, or software. The important part is that a controller can cryptographically prove control of the identifier without first asking a centralized identity provider for permission. ^[2]

That maps well to an agent's long-term continuity. An agent can move to another machine, change model providers, or be recreated as a running instance while retaining a long-lived identity. Where necessary, a system can separate a root identity from task identities. "Who am I?" does not have to be completely tied to one vendor's account system.

But a DID does not grant reputation, a job title, or permission. DID Core intentionally leaves post-authentication behavior and assurance levels to methods and applications. ^[2] This is where Verifiable Credentials belong. A VC lets an issuer make a verifiable statement about a subject, such as that an agent was registered by an organization or is permitted to handle a class of support cases. A verifier still has to decide whether to trust that issuer, and credentials still need validity periods, status, and revocation rules. ^[3]

The useful structure is not "give an agent a DID and the problem is solved." DID establishes durable identification and control proof. Credentials and delegations express third-party statements and limits. Without those next layers, a DID is a good name and a set of keys, nothing more.

Existing standards need to keep doing their jobs

Treating DID as an agent's long-term identity anchor does not mean replacing OAuth, MCP, or SPIFFE. They answer different questions.

MCP authorization for HTTP transports is based on OAuth. It answers whether a client may access a protected MCP server on behalf of a resource owner, and requires the server to validate that a token was issued for that resource. ^[4] That is access control for an operation. It is not a complete, cross-platform identity model for an agent over its lifetime.

SPIFFE and SPIRE are closer to runtime reality: is the process making this request the workload that was actually attested? They can issue short-lived credentials based on node and process attributes, then rotate them. ^[5] That matters for agents because a long-lived identity cannot prove that the container in front of us has not been replaced, copied, or compromised. But a SPIFFE trust domain is still operated by somebody. It does not replace portable, cross-organization identity.

The more credible answer is a layered one. DID provides a portable, long-lived anchor. VCs and delegations express source and scope. SPIFFE proves the active workload. OAuth and MCP apply least-privilege access to a particular resource. DIF's Trusted AI Agents Working Group is taking identity, authority, and governance together, rather than treating identity as a number to assign to an agent. ^[6]

This has costs. Interoperability among DID methods, key rotation and recovery, credential status, issuer trust, and the question of whether a copied agent is still the same subject are not solved by one standard. Agents may automate work that is difficult for humans, but automation does not make the governance decisions for us. In particular, a language model should not directly hold an unconstrained long-lived key and authority.

Draw the boundary before the history becomes expensive

ArcBlock began researching DID in 2018 and brought it into its core stack in 2019. That does not prove that we knew agents would arrive in their current form, and it is not evidence that this article is right. It explains why I care about the question. Once an identity has been absorbed into one product's account system, extracting it later, when cross-platform work has become normal, is painful. We described that choice in a 2022 article on DID and ArcBlock's earlier work.

The opportunity today is that agent ecosystems have not yet accumulated an identity history that cannot move. We can separate a durable identity from a single model vendor, cloud provider, or app store. We can also require that real authority have a delegation, a scope, and a way to take it back. Product forms and protocols will change. Those two boundaries should not.

A platform account can let an agent sign in. An API key can let it call a tool. A runtime credential can say where the current process came from. All of those are useful. None of them alone answers who the agent is outside that platform, or why it may act for somebody else. DID is not the complete answer, but it gives this question an anchor we can begin to verify.