First-Class Identity for Digital Actors

A position paper on identity infrastructure for AI agents and other software-recognizable subjects

Written by Christian Saucier, co-chair of the DID Methods Working Group

Abstract

AI agents and other software-defined actors are being deployed into production at a pace the identity layer beneath them cannot absorb. The DID Core specification has always permitted non-human subjects—much of the ecosystem built around it has not, in its focus on human-controller use-cases. This paper argues that the work required is not a new standard but architectural discipline applied to components that already exist: treating agents as first-class DID subjects, representing authority as verifiable evidence rather than opaque platform state, and recognizing that custody, delegation, and lifecycle management for digital actors demand different primitives than those designed for human-centric consent ceremonies.

What AI Agents Expose About the Identity Layer

AI agents are being deployed into production faster than the identity infrastructure beneath them can absorb. An agent is spawned in a session, handed an API key or an OAuth token, given a system prompt that encodes its authority, and sent out to act across systems on behalf of a person or an organization. The substrate holding this together is a mix of bearer tokens, session state, platform-local service accounts, and prompts, mostly reusing flows that inherit human-controller (and human attacker) assumptions. None of these were designed to identify an actor, dividing authentication from authorization. They were designed to authenticate access or shape behavior inside a single application. They are being asked to carry identity (often implicitly) because no better infrastructure is in place to do so.

The strain is already visible. An agent that needs to act across two platforms is instantiated as a new local principal in each, often with no way of linking the two across the event and access logs. An agent that needs to prove its authority to a third party has nothing to present but a token whose meaning is internal to the issuing platform, with its erroneous authentication assumptions. An agent whose key is compromised has no clean rotation path that other systems will recognize. The problem is not that agents are hard to build. The problem is that the identity layer underneath them is improvised and dangerously ill-adapted to this new context.

AI agents are the visible pressure point. The category is broader — services, devices, organizations, workflows, and infrastructure components face the same problem when they cross administrative boundaries. Agents are simply where the improvisation runs out first.

The Subject Model Was Always Broader

DID Core never restricted decentralized identifiers to humans. A DID subject can be a person, group, organization, thing, digital asset, or concept. A controller may be the subject or a separate authority, a signing service, an authenticator, etc. The standard left ample room for non-human actors. Much of the ecosystem built around it did not, and the underutilized capabilities were forgotten or missed by many observers.

Most decentralized identity practice still assumes a human-centric ceremony: a person, a wallet, an interactive prompt, a real-time verifier, browser sessions and cookies. That ceremony is essential where disclosure and consent are the events that matter. It is inadequate when the subject is a service, a workflow, or an agent operating continuously (and piping context) across systems.

The standards problem is no longer conceptual permission. Non-human subjects already fit the model. The hard work is making that generality usable in wallets, custody systems, authorization flows, messaging protocols, and relying-party practice. A broad subject model has no force or value if every implementation quietly reduces the actor to a human “subaccount”, a platform-local service principal, or a bearer token.

Subject, Controller, Operator, Beneficiary

"The user" is too crude as a universal primitive. It already strains under ordinary organizational identity. For digital actors, it collapses distinctions the system should preserve for many reasons, not least among them baseline privacy and security in an agentic age.

Consider a procurement agent. The agent is the subject. The company is the controller. A department or internal service may operate it. The organization (or even a specific department or client) is the beneficiary. A vendor marketplace may need to verify the agent can request quotes, even if it cannot commit funds at runtime. A finance system may require separate (often asynchronous) authorization before payment. A compliance system may need to reconstruct what authority existed at the time of each action.

Flatten that into "the user authorized the app" and the structure is lost. The subject is the entity identified. The controller has authority over the DID and its control material. The operator runs the actor in context. The beneficiary is who the actor acts for. The issuer makes claims. The verifier evaluates them. The relying party accepts risk.

Simple cases can collapse these roles. Serious systems cannot. If subject, controller, operator, and beneficiary are treated as interchangeable, security semantics become ambiguous and auditability degrades.

Why Agents Force the Issue

Earlier digital actors tolerated improvised identity because they stayed inside narrow boundaries, capabilities, permissions, and time windows. A build service ran inside one CI environment. A bot lived inside one workspace. The improvisation worked because the actor rarely left the administrative domain that defined it.

Three properties make existing improvisations untenable.

Frequency. A human authenticates occasionally and acts deliberately. An agent acts continuously, often many times per minute, under authority delegated earlier by someone no longer in the loop. The consent ceremony anchoring human flows cannot be invoked for every action. Authority has to be expressed once, in a form other systems can evaluate independently.

Consequence. Agents are given real authority — to spend, to commit, to write to systems of record. The cost of acting outside that authority is no longer a misconfigured webhook. It is an unauthorized purchase, a leaked record, a commitment the principal did not intend. The identity substrate has to carry enough structure that a relying party can determine, before accepting an action, what verifiable authority the agent actually has at runtime.

Identity mismatches. An agent is not a logged-in user, not a session, not a tool being invoked. It is an actor with continuity and delegated authority. Treating it as a logged-in user gives it too much — the full human account — and too little — no way to be recognized or held accountable as itself. Treating it as an API key gives it no identity at all, only access.

The industry is responding with longer-lived API keys, agent-specific OAuth clients, and platform-issued "agent accounts" that look like bot users with better marketing. Each is a local improvement. None solve the cross-context problem, because each remains owned by the platform that issued it.

What Has to Change

The DID ecosystem does not need a new grand standard. It needs architectural discipline applied to components that already exist.

Treat agents as first-class subjects. The subject model permits it. The operational ecosystem has to make it usable — wallets that can hold non-human actors, custody systems that govern them, relying parties that recognize them.

Represent authority as evidence. Delegation should be explicit, scoped, attenuated, revocable, and auditable — not hidden inside opaque platform state or bearer-token possession. A relying party should be able to determine who the actor is, who controls it, who authorized it, under what constraints, without private access to one application's database.

Generalize the wallet. The human consent ceremony does not scale to agents. Custody for digital actors means policy-governed signing, headless or organizational key management, threshold or enclave-backed control, and audit substrate. The target is controlled autonomy: software actors operating within bounded, inspectable, revocable authority. A private key in an environment variable is a failed architecture. So is a system requiring human approval for every action.

Anchor, do not absorb. A DID helps to identify the actor. It is not (thought it may contain or help find) the actor's inbox, database, memory store, or audit log. Adjacent protocols — messaging, credential exchange, authorization, storage — coordinate around the identifier without being collapsed into it.

Treat lifecycle as core architecture. Rotation, recovery, compromise response, controller transition, and retirement are normal events in operational systems, not exception cases.

Digital actors are arriving. The question is whether they become portable subjects with explicit authority and durable continuity, or app-local accounts wearing cryptographic clothing. Decentralized identity was built to challenge that pattern for people. The same discipline now belongs in the software layer itself.

Endnote: Where that change could happen

The Decentralized Identity Foundation has spent years building the standards, community, and market substrates that this argument depends on — credential exchange, presentation protocols, secure messaging, trust establishment, wallet interoperability, on the technical side, and an active, committed community on the human side. The work of making non-human subjects first-class participants in the data models and protocols will not happen elsewhere. It will happen in the working groups already composing these pieces, with the agent use case now pulling on every one of them at once.