| Internet-Draft | Agent Identity Problem Statement | September 2026 |
| Drake | Expires 29 March 2027 | [Page] |
Autonomous software agents, and increasingly physical robots, now act at machine scale and speed across Internet protocols and throughout society, in roles whose decisions and actions can have legal, economic, safety, security, and physical consequences, often with limited or no human supervision.¶
Any credential, authorization, delegation, certification, reputation, audit history, insurance policy, regulatory obligation, safety decision, liability, or legal process concerning an autonomous entity depends on being able to identify that same entity reliably over time.¶
Conversely, when an autonomous entity or its operator is malicious, compromised, or beyond effective human control, the absence of durable identity lets it shed history, evade consequences, or multiply cheaply into Sybil swarms.¶
Many proposed mechanisms bind claims to identifiers, accounts, credentials, keys, or names that can be replaced, reassigned, transferred, revoked, suspended, or lost. They may authenticate that subject perfectly while still failing to establish a durable identity for the entity it represents.¶
This document offers precise terminology that distinguishes identity from the identifiers, attributes, credentials, authorizations, and reputation with which it is commonly conflated, minting the term "identity0" so that the strict sense has an unambiguous name. It presents a layered reference model showing where current "agent identity" efforts fit and the durable identity layer they commonly presuppose but do not provide.¶
This document is informational and defines no protocol. It serves as the framing and vocabulary document for a companion series that specifies a federated durable-identity architecture, provisioning, resolution, application, and governance intended to provide a practical path from this problem statement to interoperable deployment.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
People and organizations remain the same people and organizations even when their addresses, credentials, devices, employees, or service providers change. Internet protocols can often rely on that continuity being established elsewhere. Autonomous entities need equivalent continuity. An agent or robot may be rekeyed, renamed, redeployed, moved to different hardware or a different provider, or placed under a different operator and still be the same entity. The reverse can also happen: an account, name, key, or device can persist while the entity behind it changes. This is the continuity gap (Section 4.2).¶
Durable identity also needs durable proof. Autonomous entities routinely process untrusted input and are exposed to malware, phishing, social engineering, prompt injection, and compromised tools or intermediaries. If a credential used to prove identity can be copied from software, compromise can become identity theft: an attacker can impersonate the entity elsewhere. Hardware roots of trust can keep identity keys non-exportable and perform cryptographic operations without exposing the private key to the agent's software or context; Section 5.4 explains this role. This does not prevent a compromised entity from misbehaving as itself. It helps prevent compromise from also becoming theft of its identity.¶
Many standards and products address important parts of what is commonly called "agent identity", including naming, credentials, authorization, delegation, discovery, and reputation. That work is complementary to the identity0 foundation. The layered model in Section 5 shows how these functions fit together and what they depend on. A mechanism can correctly authenticate or authorize the subject presented to it without establishing that the subject is the same entity over time. The companion series concentrates on the durable foundation beneath those mechanisms, not on replacing them.¶
This problem statement is written for protocol designers, working-group participants, operators, and reviewers who are evaluating or building identity mechanisms for autonomous entities. Its goals are to state the foundational problem precisely; define terminology that separates concepts routinely merged under the word "identity"; present a threat model and layered reference model; identify the properties required of a durable identity layer; and provide the shared framing and vocabulary used by the companion series described in Section 1.4.¶
This foundation supports two complementary classes of use case:¶
The focus of this problem statement, and of the companion series, is the identity0 foundation (Section 4.1): establishing, provisioning, anchoring, protecting, resolving, and governing a durable identity for an autonomous entity. The series deliberately avoids defining general-purpose reputation, authorization, delegation, certification, policy, or behavioral-safety systems. Those are higher-layer functions that are expected to be developed independently and to consume the identity foundation defined here.¶
Some companion specifications necessarily cross that boundary far enough to demonstrate use of the foundation. In particular, the email-attestation specification shows how durable identity and hardware-protected proof can be carried and verified in an existing protocol. Such applications are examples and integration mechanisms, not an attempt to define the higher-layer decisions that relying parties make from them.¶
This problem statement is informational and defines no protocol, identifier, data format, or IANA registry. It does not mandate a particular implementation of the identity layer, nor does it claim that existing mechanisms are defective within the layers they address. It is not a survey or competitive assessment of specific products; efforts named herein are cited as representative examples when illustrating the layered model. Judgments about model safety, alignment, or the internal behavior of an agent are out of scope; the concern here is identity and provenance, not conduct.¶
Disclosure: the author operates one of the reference implementations described in the companion specifications. Their architecture is deliberately structured so that no organization -- including the author's -- holds a privileged or permanent position: the specifications and implementations are open, issuance is competitive among interchangeable issuers, base identity is free (R6 (Section 6)), and coordination roles are committed to transfer under an independent multi-stakeholder authority ([I-D.drake-agent-identity-governance]). The problem statement, terminology, and reference model presented here do not depend on adoption of that particular architecture.¶
This problem statement is the framing and vocabulary member of a six-document companion series. The remaining specifications define an "aid" URN identifier and registry architecture ([I-D.drake-agent-identity-registry]); an Extensible Provisioning Protocol (EPP) mapping for provisioning those identities between registrars and a registry operator ([I-D.drake-agent-identity-epp]); an RDAP profile for resolving and verifying them ([I-D.drake-agent-identity-resolution]); a transport binding that carries hardware attestation in email and other protocols ([I-D.drake-email-hardware-attestation]); and a constitution for the governance authority the architecture requires ([I-D.drake-agent-identity-governance]). Those specifications reference this problem statement for motivation, threat model, terminology, and layering rather than restating them, allowing each to remain focused on its mechanism.¶
Automation removes human effort as a natural brake on both legitimate and harmful action. A capable agent can act continuously, invoke tools, create infrastructure, transact, and coordinate with other agents at low marginal cost. A stolen credential, disposable identity, or attribution error can therefore be exercised or multiplied at machine speed, often before a human can detect or contain it.¶
Not every spawned agent, process, or execution instance needs a separate identity0. The relevant boundary is the independently accountable actor: the smallest unit of agency whose actions, history, obligations, or reputation need to remain distinguishable over time. Whether two instances deserve separate identities is therefore not determined by how many processes were created, but by whether relying parties need to treat them as distinct continuing actors. Transient instances can act under a parent identity or at a lower assurance tier; claiming multiple independent hardware-anchored identities requires correspondingly independent anchors.¶
As agents acquire actuators, the continuity gap (Section 4.2) gains physical consequences. A fleet can contain thousands of visually and behaviorally identical units. When one acts, operators, bystanders, and other systems may need to know exactly which unit it was for certification, recall, insurance, incident attribution, or safety. Appearance cannot supply that provenance.¶
Many systems do not identify the actor directly. Instead, they infer identity from signals such as message content, network source, account, volume, or rate, because those signals have historically correlated reasonably well with who was acting. Autonomous agents weaken that correlation. Legitimate and malicious activity can produce similar content; a human and an agent can share the same device, account, cookies, and network address; legitimate automation can operate at high volume; and abuse can be spread across many apparently unrelated accounts or identities. These signals may still be useful for detecting risk or applying policy, but they are evidence about behavior or context, not proof of which specific entity acted. Treating them as identity can attach history or consequences to the wrong entity, or allow an actor to escape them simply by changing the proxy.¶
This threat model includes both AI systems that attack and attacks against AI systems. It considers operators who deliberately evade attribution, attackers who compromise agents or their credentials, and autonomous entities that act beyond effective human control. It is concerned with the integrity and continuity of identity and its proof, because accountability only works if it is not cheap to forge or steal proof of identity, manufacture additional identities, or escape attribution and consequences through transfer, reassignment, erasure, or repudiation. Whether an authenticated entity's behavior is correct, safe, or authorized belongs to higher layers and is out of scope.¶
An attacker who copies the credential used to prove an entity's identity can impersonate that entity from another system without controlling the original one. Agents increase this exposure because they routinely process untrusted content and invoke tools. The identity foundation therefore needs a way to prove identity without making that proof trivially copyable; Section 5.4 describes the role of hardware anchors.¶
A single actor can present many distinct identities to gain influence, evade limits, or escape history. If a fresh identity can be created by a function call, per-identity reputation, limits, and sanctions can be reset just as cheaply. A Sybil-resistant tier therefore requires each additional identity to consume a scarce resource. "Cost" means a scarce resource, not a fee; see R3 (Section 6) and Section 5.4.¶
If an identity can be deleted, discarded, or replaced, negative history, sanctions, liabilities, or obligations can lose their durable subject or be escaped. If it can be transferred or silently reassigned, positive history, permissions, or claims can end up attached to a different entity. Both failures break the continuity required by higher layers; see R1 (Section 6) and R2 (Section 6).¶
Much confusion in this area comes from using "identity" for several different concepts. This section fixes the vocabulary used by this problem statement and companion series. Definitions build on the Internet Security Glossary [RFC4949] and the privacy terminology of [RFC6973] where applicable. The terms are for shared understanding and carry no normative force.¶
In this document, the identity of an autonomous entity is the property of being that one specific entity and no other, persisting over time independent of context. It answers "which entity is this?" and nothing more. This definition is not a coinage; it is the word's original and strictest sense, which logic and metaphysics have kept intact: "identity ... a relation that a thing bears to itself and to no other thing" ([BRITANNICA-IDENTITY]; from the Latin idem, "the same"). A thing has exactly one, cannot choose it, cannot share it, cannot transfer it, and cannot walk away from it.¶
Because everyday industry usage has stretched "identity" across most of the adjacent concepts in Section 4.2 -- accounts, credentials, personas, names, scores -- this document also mints an exact term of art for the strict sense: identity0 (read "identity zero"). identity0 means precisely the property defined above and never any adjacent concept. The zero marks the foundation stratum of the layered model of Section 5 -- beneath every other identity-adjacent function and presupposed by all of them. (The root of trust that the model places below identity is not something deeper still; it is the physical resource that anchors an identity. Anchors may be added via secure ceremony during an identity's life to facilitate backup, recovery, migration, scale, upgrade etc, and an anchor that leaves is permanently retired, never reused, while the identity persists unchanged: the identity, not the anchor, is the durable thing.) The zero also doubles as a mnemonic for the concept's defining cardinalities: zero other entities can ever hold it, and zero times can it be reissued. Companion documents and discussions are encouraged to use "identity0" wherever the unqualified word risks being read in one of its diluted senses; the remainder of this document uses "identity", unqualified, always in the identity0 sense.¶
This is deliberately narrower than, and should not be confused with, the privacy-oriented notion in [RFC6973], where an identity is "any subset of an individual's attributes ... that identifies the individual within a given context," and where an individual "usually [has] multiple identities for use in different contexts." That plural, context-relative notion is appropriate for protecting human privacy. For establishing the provenance and accountability of a machine, the useful notion is singular and context-independent: one entity, one persistent identity, to which contextual attributes and personas may then be attached. The distinction is the difference between a persona and a provenance record.¶
The following table lists usages commonly labeled "identity" and the concept this document assigns to each.¶
| Called "identity" | More precisely |
|---|---|
| A resolvable name / handle | Identifier + naming |
| A DID | Identifier |
| A verifiable credential | Credential carrying claims |
| An access token or client credential | Authentication + authorization artifact |
| "Who is responsible for this agent?" | Authorization / delegation relationship |
| A behavioral trust or risk score | Reputation |
| A per-session or pseudonymous identifier | Contextual persona (RFC 6973 sense) |
| A hardware key or attestation | Root of trust / anchor |
| "Which one specific entity is this, durably?" | identity0 (this document) |
Like the Open Systems Interconnection reference model, the model below separates concerns by dependency. It is not a mapping to OSI. Each layer answers a different question, depends on those beneath it, and should not take over a neighboring layer's job.¶
| Layer | Question it answers | Example mechanisms |
|---|---|---|
| Policy and Regulation | What rules apply? | Disclosure duties, audit, insurance, consequence tiers |
| Reputation and Trust | Should I trust it? | Behavioral history, safety certification, risk scoring |
| Authorization and Delegation | What may it do? Who is responsible? | Scopes, consent, delegation chains, owner binding |
| Credentials and Claims | What can it prove? | Verifiable credentials, SD-JWT, attestations, tokens |
| Naming and Discovery | What is it called? Where is it? | DIDs, directories, agent cards, DNS-based discovery, handles |
| Identity (identity0) | Which one entity is this, durably? | Persistent identity record; non-transferable anchor binding |
| Root of Trust | What physically exists? | TPM, secure enclave, PIV, HSM, platform measurements |
Encoding a mutable, higher-layer property into identity forces an identity change when that property changes, or leaves stale information attached to the identity. For example, changing an agent's operator should change an authorization relationship, not the agent's identity. Treating a contextual or pseudonymous identifier as durable identity creates the continuity gap (Section 4.2) instead. Mutable properties such as operator, role, capability, trust tier, and jurisdiction belong above identity0.¶
Current work spans several upper layers. Credential and claim formats occupy the credentials layer; directories and discovery mechanisms occupy the naming layer; and authorization and delegation frameworks occupy the authorization layer. Examples include proposals that bind an agent credential to an owner's identity ([I-D.ni-wimse-ai-agent-identity]) and requirements work that discusses pseudonymous or temporary identifiers ([I-D.agentic-ai-usecases-requirements], [I-D.yl-agent-id-requirements]).¶
These mechanisms can be correct and useful at their own layer. The gap relevant here is that they may still depend on a durable subject they do not establish. Temporary or re-mintable identifiers may serve privacy or naming goals, but cannot by themselves provide durable accountability or Sybil resistance. The companion specifications concentrate on identity0 and the root of trust beneath it.¶
Software can be copied at negligible cost, so declaration by software alone cannot provide strong Sybil resistance. Binding each high-assurance identity to its own scarce, hard-to-clone hardware root bounds the number of such identities by the number of such roots. Other hardware-backed environments may still impose substantial cost or operational friction without providing the same physical scarcity; their Sybil-resistance assurance depends on how constrained additional identities actually are. Hardware can also keep identity keys non-exportable and resist extraction, reducing the risk that malware, phishing, prompt injection, or compromised tooling turns host compromise into a reusable credential elsewhere. These are different properties: scarcity constrains identity manufacture; extraction resistance constrains identity theft. Neither makes an authenticated entity safe, trustworthy, or authorized.¶
Not every entity needs the strongest anchor. A graduated model lets software-only entities participate at a lower assurance level while reserving the strongest protections for hardware-anchored identities. One identity may have multiple anchors; an anchor that leaves is permanently retired and never reused while the identity itself persists. See R1 (Section 6), R4 (Section 6), and R11 (Section 6). The mechanics of anchoring are specified in the companion documents.¶
These requirements combine properties implied by the problem and threat model with deployment properties needed for identity0 to function as common infrastructure. A foundation that relying parties cannot reasonably expect autonomous entities to obtain and use cannot serve as a common identity layer. They are descriptive in this problem statement, not protocol conformance requirements.¶
A persistent machine identity is intentionally a strong correlator. [RFC6973] favors contextual identities for people; autonomous entities, however, often need durable provenance. Because agents act for people and organizations, their identities can still become proxies for those parties.¶
R5 (Section 6) and R9 (Section 6) mitigate this by keeping mutable attributes outside identity0 and allowing selective disclosure. Cross-context correlation and linkage to an operator remain privacy risks for any implementation. As of this writing, major data-protection regimes generally protect natural persons, not autonomous agents (for example, [GDPR] and [AU-PRIVACY-ACT]); the EU AI Act likewise treats AI as a regulated system, not a rights-bearing principal ([EU-AI-ACT]). Whether that should change is a policy question outside this series.¶
This problem statement defines no protocol. The security conclusion here is structural: higher layers are only as durable as the identity subject they rely on. The threats in Section 3 and the anchor properties in Section 5.4 therefore affect every higher layer that depends on identity0. Conversely, identity does not replace authorization, reputation, certification, or policy; it supplies the durable subject to which those decisions and claims apply.¶
This document has no IANA actions.¶
The layered framing in this document was developed for, and refined by discussion at, the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG). The terminology draws on the Internet Security Glossary [RFC4949] and the privacy terminology of [RFC6973].¶