Network Working Group C. Drake Internet-Draft 1id.com Intended status: Informational 17 July 2026 Expires: 18 January 2027 Identity for Autonomous Agents and Robots: Problem Statement, Threat Model, and Terminology draft-drake-agent-identity-problem-statement-00 Abstract The Internet's identity infrastructure was designed for human principals and the organizations that employ them. Autonomous software agents, and increasingly physical robots, now participate in Internet protocols and in society at machine scale and speed, with limited or no human supervision. This document states the resulting problem, presents a threat model centered on identity manufacture (Sybil attacks) and the collapse of the signals that receivers have historically used to distinguish wanted from unwanted automated traffic, and offers a 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 then presents a layered reference model that locates the many current "agent identity" efforts and shows that most of them operate above a foundational layer -- persistent, non-transferable, Sybil- resistant identity -- that they each presuppose but do not provide. This document is informational. It defines no protocol. Its purpose is to provide shared vocabulary and motivation so that companion specifications can remain concise and focused on mechanism. Status of This Memo 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." Drake Expires 18 January 2027 [Page 1] Internet-Draft Agent Identity Problem Statement July 2026 This Internet-Draft will expire on 18 January 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purpose and Audience . . . . . . . . . . . . . . . . . . 3 1.2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 4 1.3. Relationship to Other Documents . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Scale, Autonomy, and Marginal Cost . . . . . . . . . . . 4 2.2. Embodiment and Physical Indistinguishability . . . . . . 5 2.3. Collapse of Legacy Discrimination Signals . . . . . . . . 5 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Identity Manufacture (Sybil Attacks) . . . . . . . . . . 6 3.2. Reputation Evasion and Laundering . . . . . . . . . . . . 6 3.3. Impersonation and Loss of Provenance . . . . . . . . . . 7 3.4. The Accountability Gap . . . . . . . . . . . . . . . . . 7 3.5. Threat-Model Non-Goals . . . . . . . . . . . . . . . . . 7 4. Terminology and the Conflation Problem . . . . . . . . . . . 8 4.1. Identity, and the Term "identity0" . . . . . . . . . . . 8 4.2. Adjacent Concepts . . . . . . . . . . . . . . . . . . . . 9 4.3. Summary: What "Identity" Is Often Used To Mean . . . . . 10 5. A Layered Reference Model . . . . . . . . . . . . . . . . . . 11 5.1. Borrowing the Discipline of Layering . . . . . . . . . . 11 5.2. Layering Violations . . . . . . . . . . . . . . . . . . . 12 5.3. Where Current Efforts Sit, and the Common Gap . . . . . . 13 5.4. Why the Identity Layer Needs an Anchor . . . . . . . . . 13 6. Requirements on an Identity Layer . . . . . . . . . . . . . . 14 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Informative References . . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Drake Expires 18 January 2027 [Page 2] Internet-Draft Agent Identity Problem Statement July 2026 1. Introduction Every identity layer the Internet relies on -- email addresses, domain names, TLS certificates, OAuth 2.0 tokens -- assumes a human principal, or a human-operated organization, at the root of trust. Passwords assume something a person knows; possession factors assume a device a person holds; biometrics assume a body. Certificate authorities certify organizations. OAuth 2.0 client credentials authenticate an application deployment, not the specific machine instance running it. As of 2026, large numbers of autonomous agents operate continuously on the public Internet: composing and sending messages, filing forms, calling APIs, transacting, writing and deploying software, and interacting with other agents. They act on timers and triggers, not only in response to a human keystroke. Autonomous physical systems -- delivery robots, inspection drones, service and industrial robots -- are beginning to do the same with physical presence. These entities need an answer to a question the current infrastructure does not answer well: which specific entity is this, reliably, over time, in a way that cannot be cheaply counterfeited or multiplied at automation scale? A large and growing number of standards efforts, products, and working groups address parts of "agent identity." Most of them, as Section 5 shows, work at the layers of naming, credentials, authorization, and reputation. Those are real problems and much of that work is valuable. This document observes that those layers each presuppose a persistent, forgery-resistant answer to "which entity is this?" -- and that this base layer is the one least served. 1.1. Purpose and Audience This document 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 problem precisely; to give a threat model that later documents can reference; to fix a vocabulary that separates concepts routinely merged in current usage; and to place existing efforts within a layered model so that gaps and overlaps are visible. Drake Expires 18 January 2027 [Page 3] Internet-Draft Agent Identity Problem Statement July 2026 1.2. Scope and Non-Goals This document is informational and defines no protocol, identifier, data format, or IANA registry. It does not mandate any particular solution. It is not a survey or a competitive assessment of specific products; efforts named herein are cited only as representative examples to locate work within the reference model. Judgments about model safety, alignment, or the internal behavior of any agent are out of scope; this document concerns identity and provenance, not conduct. Disclosure: the author operates one of the reference implementations described in the companion documents. The architecture those documents specify 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 in Section 6), and the coordination roles are committed to transfer under an independent multi-stakeholder authority ([I-D.drake-agent-identity-governance]). 1.3. Relationship to Other Documents This document is the framing member of a family of companion specifications: 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 constitution for the governance authority the architecture requires ([I-D.drake-agent-identity-governance]); and a transport binding that carries hardware attestation in email and other protocols ([I-D.drake-email-hardware-attestation]). Those documents reference this one for motivation, threat model, and terminology rather than restating them, which allows each to remain focused on its mechanism. 2. Problem Statement 2.1. Scale, Autonomy, and Marginal Cost Automation changes the economics that historically limited abuse. A capable agent can perform reconnaissance, generate tailored content, create supporting infrastructure, and act, at a marginal cost approaching zero and without fatigue. Defenses that assume a human somewhere in the loop -- interactive challenges, rate limits tuned to human throughput -- and the natural friction of composing a convincing message by hand all stop constraining an actor that is Drake Expires 18 January 2027 [Page 4] Internet-Draft Agent Identity Problem Statement July 2026 software. 2.2. Embodiment and Physical Indistinguishability As agents acquire actuators, the same identity gap acquires physical consequences. A fleet may contain thousands of units that are visually and behaviorally identical. When such a unit acts in the world, bystanders, operators, and other systems need to know which specific unit it is -- for certification, recall, insurance, incident attribution, and safety -- and cannot rely on appearance to tell them. The identity of a machine is a matter of provenance, not of the rights or persona that attach to a human being. 2.3. Collapse of Legacy Discrimination Signals Receivers have historically separated wanted from unwanted automated traffic using a small number of signals. Each is weakened by capable automation: Content analysis When generated text, code, and media are indistinguishable in quality from human-authored equivalents, "was this produced by a machine?" becomes increasingly unanswerable -- and increasingly unhelpful even where it can be answered, because machine-produced no longer implies unwanted: composing by agent is simply how a growing share of legitimate human correspondence now gets written, the author having delegated the typing rather than the intent. Source reputation An agent is not merely near its operator's infrastructure; increasingly it _is_ that infrastructure. Vendors embed agents directly into the browsers, mail clients, office suites, operating systems, and phones that humans use, so the agent's traffic leaves from literally the same browser profile, the same device, the same residential IP address, and the same accounts as the human's own legitimate traffic. Source-based reputation cannot separate two actors who share one source. Volume and rate heuristics Abuse that once announced itself through volume can now be spread across many manufactured identities in small, individually unremarkable amounts. Volume has also ceased to imply intent: the same embedded agents place machine-scale fan- out in the hands of ordinary users, so one casual instruction -- "tell everyone in my address book" -- can be faithfully executed, perhaps by thousands of spawned sub-agents, at a volume its well- meaning author never contemplated. Drake Expires 18 January 2027 [Page 5] Internet-Draft Agent Identity Problem Statement July 2026 As these signals lose their discriminating power, a persistent, forgery-resistant identity for the acting entity becomes the principal remaining basis on which a receiver can make a differentiated decision, and on which accountability and reputation can accrue over time. 3. Threat Model The adversary is an economically rational operator of automated systems who seeks to act without being reliably identified, and who can generate content and stand up infrastructure at low marginal cost. The adversary may control many machines and may be a legitimate participant in most interactions and abusive in others. 3.1. Identity Manufacture (Sybil Attacks) The central threat is the Sybil attack [Sybil]: a single actor presents many distinct identities to gain influence, evade limits, or escape a reputation. Where an identity can be minted by a function call, no reputation system, block-list, or per-identity limit is durable, because the adversary can create fresh identities faster than they can be judged. A meaningful identity layer must make identity creation cost a scarce resource in proportion to the number of identities created, so that large-scale identity fraud is bounded by real-world cost rather than by compute. "Cost" here means the expenditure of a scarce resource -- a physical device, silicon that cannot be copied -- not a fee charged to participants: an entity's first identity can be free of charge and of friction (see R6 in Section 6); what must carry a cost is each additional identity for the same actor. 3.2. Reputation Evasion and Laundering If an identity can be discarded and re-created, negative reputation is escapable: the adversary sheds a bad history simply by minting a replacement. If an identity can be transferred, positive reputation is purchasable: a bad actor acquires a good history rather than earning one, so a good history stops being evidence of good conduct. Either property alone degrades reputation as a signal; durable, non- transferable identity is what makes reputation -- good or bad -- consequential. Drake Expires 18 January 2027 [Page 6] Internet-Draft Agent Identity Problem Statement July 2026 3.3. Impersonation and Loss of Provenance Without a forgery-resistant identity, an entity can claim to be another, or can decline to be pinned to any prior interaction. In an environment of indistinguishable software instances and identical physical units, impersonation and provenance loss undermine attribution for both security response and physical safety. 3.4. The Accountability Gap Certification, product recall, insurance, regulatory disclosure, and legal process all require that an entity can be named durably enough that a claim made about it today still refers to the same entity later. Mechanisms that assume such an identity -- but do not supply one that withstands the threats above -- inherit a gap they cannot close on their own. 3.5. Threat-Model Non-Goals This model does not address the correctness, safety, or alignment of an entity's behavior, nor confidentiality of the content it processes. It is concerned with whether the identity of the acting entity can be established and cannot be cheaply forged or multiplied. That narrow statement undersells a substantial collateral benefit of the anchors the companion documents use: when an identity is proven by a key held inside a hardware security component, the key is designed to be unextractable by the malware, phishing, and prompt- injection attacks that routinely exfiltrate software credentials -- so the large class of breaches that begin with a stolen credential loses its principal target. The exposure this closes is wider than classical theft. A large proportion of an agent's actions -- deliberately and accidentally -- move data into infrastructure operated by its model provider and tool intermediaries: whatever the agent reads, is told, or is given ends up in prompts, context windows, tool traffic, and logs. A password or API key handled by an agent is therefore not merely at risk of theft from the agent's host; it is routinely disclosed, in operation, to every party that processes the agent's cognition, and its confidentiality thereafter rests on hope that none of those parties leaks it -- by accident, by breach, by insider action, by surveillance, or by legal compulsion. A hardware-resident key never appears in context at all: signing (and decryption) happens inside the component, so nothing the provider stores, loses, or is compelled to produce contains the credential. These benefits belong to the solution documents; this model claims only the identity properties. Drake Expires 18 January 2027 [Page 7] Internet-Draft Agent Identity Problem Statement July 2026 4. Terminology and the Conflation Problem Much confusion in this area stems from using one word, "identity," for several distinct concepts. This section fixes a vocabulary. Definitions build on the Internet Security Glossary [RFC4949] and the privacy terminology of [RFC6973] where applicable, and note where the needs of autonomous machines differ from those of human principals. This document is informational; the terms below are for shared understanding and carry no normative force. 4.1. Identity, and the Term "identity0" 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 over an identity's life, 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 Drake Expires 18 January 2027 [Page 8] Internet-Draft Agent Identity Problem Statement July 2026 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. 4.2. Adjacent Concepts Identifier A data object that refers to an identity within a context ([RFC4949], [RFC6973]). An identifier is a name for an identity; it is not the identity. One identity may have several identifiers (for example, a stable canonical identifier and a human-friendly handle). Attribute (Claim) A statement about an entity -- its capabilities, role, operator, jurisdiction, certifications, or trust level. Attributes are typically mutable and contextual. They are properties of an identity, not the identity itself. Credential A verifiable container that binds attributes (and often a key) to an identifier, issued by some party. A credential is how an entity presents attributes; its validity can be time-bounded and it can be revoked. Credentials presuppose an identity to issue against. Authentication The act of verifying that a party is the entity it claims to be, usually by proof of possession of a key. Authentication is an operation performed against an identity; it is not the identity. Authorization and Delegation Determination of what an entity may do, and the conferral of permission by one party on another (including an operator authorizing an agent to act on its behalf). These are dynamic relationships that change, expire, transfer, and are revoked. The responsible operator of an agent is an authorization-layer relationship, not a component of the agent's identity. Reputation An assessment of an entity accumulated from observed behavior over time. Reputation is durably meaningful only when it is anchored to an identity that cannot be cheaply discarded or exchanged (Section 3.2). Naming and Discovery Mechanisms for assigning human- or machine- usable names to entities and for locating them and their endpoints or metadata. Naming and discovery consume identity; they do not establish it. Drake Expires 18 January 2027 [Page 9] Internet-Draft Agent Identity Problem Statement July 2026 Root of Trust / Anchor A component whose trustworthiness is assumed rather than derived, on which higher-layer trust is built. A hardware root of trust (for example a TPM, secure enclave, PIV device, or HSM) can provide a per-device key that is intended to resist extraction and cloning; such a key can anchor an identity but is not itself the identity. Autonomous Entity (Agent, Robot) Any non-human actor that participates in Internet protocols or in physical society with some degree of independence. This document uses "agent" as shorthand and "robot" for an embodied agent, but the concepts apply regardless of embodiment. Sybil Resistance The property that creating additional distinct identities imposes a cost that grows with the number created, so that a single actor cannot cheaply present many distinct identities ([Sybil]). 4.3. Summary: What "Identity" Is Often Used To Mean The following table lists usages commonly labeled "identity" and the concept this document assigns to each. Drake Expires 18 January 2027 [Page 10] Internet-Draft Agent Identity Problem Statement July 2026 +================================+================================+ | Called "identity" | More precisely | +================================+================================+ | A resolvable name / handle | Identifier + naming | +--------------------------------+--------------------------------+ | A DID or verifiable credential | Credential carrying attributes | +--------------------------------+--------------------------------+ | An access token or client | Authentication + authorization | | credential | artifact | +--------------------------------+--------------------------------+ | "Who is responsible for this | Authorization / delegation | | agent?" | relationship | +--------------------------------+--------------------------------+ | A behavioral trust or risk | Reputation | | score | | +--------------------------------+--------------------------------+ | A per-session or pseudonymous | Contextual persona (RFC 6973 | | identifier | sense) | +--------------------------------+--------------------------------+ | A hardware key or attestation | Root of trust / anchor | +--------------------------------+--------------------------------+ | "Which one specific entity is | identity0 (this document) | | this, durably?" | | +--------------------------------+--------------------------------+ Table 1: Common "identity" usages and their precise concept 5. A Layered Reference Model 5.1. Borrowing the Discipline of Layering The Open Systems Interconnection reference model endured less because of its specific seven layers than because of a discipline: each layer depends on the layer below, offers a defined service to the layer above, and does not attempt its neighbor's job. The model below borrows that discipline, not a literal mapping to OSI, to organize the concerns that make up trust in an autonomous entity. Each layer answers a distinct question and depends on those beneath it. Drake Expires 18 January 2027 [Page 11] Internet-Draft Agent Identity Problem Statement July 2026 +================+================+===============================+ | Layer | Question it | Example mechanisms | | | answers | | +================+================+===============================+ | Policy and | What rules | Disclosure duties, audit, | | Regulation | apply? | insurance, consequence tiers | +----------------+----------------+-------------------------------+ | Reputation and | Should I trust | Behavioral history, safety | | Trust | it? | certification, risk scoring | +----------------+----------------+-------------------------------+ | Authorization | What may it | Scopes, consent, delegation | | and Delegation | do? Who is | chains, owner binding | | | responsible? | | +----------------+----------------+-------------------------------+ | Credentials | What can it | Verifiable credentials, DIDs, | | and Claims | prove? | SD-JWT, attestations, tokens | +----------------+----------------+-------------------------------+ | Naming and | What is it | Directories, agent cards, | | Discovery | called? Where | DNS-based discovery, handles | | | is it? | | +----------------+----------------+-------------------------------+ | Identity | Which one | Persistent, non-transferable, | | (identity0) | entity is | Sybil-resistant identifier | | | this, durably? | and registry | +----------------+----------------+-------------------------------+ | Root of Trust | What | TPM, secure enclave, PIV, | | | physically | HSM, platform measurements | | | exists? | | +----------------+----------------+-------------------------------+ Table 2: A layered reference model for agent trust 5.2. Layering Violations Conflating layers creates fragility. Encoding a mutable, higher- layer property into the identity layer forces an identity change whenever that property changes. For example, binding "the responsible operator" into an agent's identity means that every ordinary event at the authorization layer -- a contractor departs, a delegation expires, a company is acquired, a unit is resold -- either forces a new identity or leaves the old one asserting something false. Similarly, treating a per-context or pseudonymous identifier (an [RFC6973] "identity") as the durable identity leaves reputation and accountability unanchored. The remedy is to keep the identity layer narrow and to express operator, role, capability, trust tier, and jurisdiction as attributes and authorizations layered on top. Drake Expires 18 January 2027 [Page 12] Internet-Draft Agent Identity Problem Statement July 2026 5.3. Where Current Efforts Sit, and the Common Gap Placed against this model, the large body of current "agent identity" work concentrates in the upper layers. Credential and claim formats and workload-credential mechanisms occupy the credentials layer. Directory, discovery, and naming systems occupy the naming layer. Authorization and delegation frameworks, including proposals that bind an agent credential to an owner's identity ([I-D.ni-wimse-ai-agent-identity]), occupy the authorization layer. Use-cases and requirements documents survey needs across these layers; some define "agent identity" as "identity information ... used for authentication and accountability" and suggest pseudonymous or temporary identifiers ([I-D.agentic-ai-usecases-requirements], [I-D.yl-agent-id-requirements]). This is not a criticism of that work, which addresses real problems. It is an observation about layering: these mechanisms each presuppose a persistent, forgery-resistant answer to "which entity is this?" that they do not themselves provide. A pseudonymous or re-mintable identifier is well suited to privacy at the naming layer but cannot by construction supply Sybil resistance or durable accountability at the identity layer. The identity layer, and the root of trust beneath it, are the least addressed and are the subject of the companion specifications. 5.4. Why the Identity Layer Needs an Anchor Sybil resistance cannot be achieved by software declaration alone, because software can be copied at no cost. Binding an identity to a scarce, hard-to-forge resource makes creating N identities cost N units of that resource. Hardware roots of trust are a widely deployed such resource: a per-device key intended to resist extraction and cloning lets each device anchor at most one identity. (One identity may span many devices -- an operator's fleet accruing reputation to a single identity -- but never the reverse, and a device leaves an identity only by permanent retirement of its anchor; see R1 in Section 6.) Not every entity has, or needs, the strongest anchor; a graduated model (see Section 6) lets software-only entities participate at a clearly labeled lower assurance level while reserving the strongest Sybil resistance for hardware-anchored entities. The mechanics of anchoring are specified in the companion documents and are out of scope here. Drake Expires 18 January 2027 [Page 13] Internet-Draft Agent Identity Problem Statement July 2026 6. Requirements on an Identity Layer From the problem statement and threat model, an identity layer for autonomous entities needs the following properties. These are stated descriptively to guide and compare solutions; they are not protocol conformance requirements, which belong to the companion specifications. R1 Persistence The identity survives restarts, redeployment, software updates, addition or replacement of hardware anchors (a replaced anchor is permanently retired, never reused), and changes of operator, and is not silently reassigned. R2 Non-transferability The identity denotes one entity and cannot be sold or handed to a different entity. (Changing which provider serves an identity is a separate, legitimate operation.) R3 Sybil resistance Creating additional identities costs a scarce resource in proportion to the number created, not a function call ([Sybil]). R4 Graduated inclusivity Entities without a strong hardware anchor can still participate at a lower, clearly labeled assurance level, so the layer is not all-or-nothing. R5 Separation of identity from attributes Mutable properties -- trust tier, role, operator, capabilities, jurisdiction -- are expressed as layered attributes and authorizations, never encoded into the identifier itself. R6 Unconditional base issuance Obtaining a base identity is free of charge and is not gated behind paid or optional value-added services. Access to identity does not depend on ability to pay, even though the assurance level attainable may vary with the available anchor (R4). R7 Federation and issuer choice No single organization is the gatekeeper of issuance: multiple independent issuers compete to serve entities, an entity can change issuer without its identity changing, and the failure or misbehavior of any one participant does not collapse the system. (Coordination functions that must be singular, such as uniqueness enforcement, are constrained instead by escrow, replaceability, and accountable governance.) R8 Low-friction verification Relying parties can verify identity using widely deployed mechanisms rather than bespoke software. R9 Privacy and selective disclosure Presenting an identity does not Drake Expires 18 January 2027 [Page 14] Internet-Draft Agent Identity Problem Statement July 2026 force disclosure of unnecessary attributes, and pseudonymous presentation is possible where accountability can still be preserved ([RFC6973]). R10 Transport independence The identity is usable across email, HTTP, agent-to-agent messaging, and protocols not yet defined. 7. Privacy Considerations A persistent, non-transferable identity for an autonomous entity is, by design, a strong correlator. For human beings this would be at odds with the privacy guidance of [RFC6973], which favors contextual, plural identities. This document's scope is the identity of machines, for which durable provenance is a goal rather than a hazard; nonetheless, agents act for humans and organizations, so their identities can become proxies for those parties. Two design directions reconcile durable machine identity with privacy, and are elaborated in the companion documents. First, separation of identity from attributes (R5) means the identifier need not carry operator, location, or purpose. Second, selective disclosure (R9) lets an entity prove a specific property -- for example, that it meets a trust level -- without revealing its full identity. Correlation of an agent's activity across contexts, and linkage between an agent and its operator, remain the principal privacy risks and are to be treated explicitly by any solution. One debate is noted and declared out of scope: whether, or to what degree, autonomous entities themselves ought to enjoy privacy comparable to that of human principals. The privacy interests protected in this document family are those of the humans and organizations behind agents, not of the machines. Readers weighing the machine side of that debate should hold two considerations in frame: fraud characteristically depends on its perpetrator concealing or falsifying who they are, and capable automation -- including models publicly redistributed with their refusal behaviors stripped out (so-called "abliterated" models) -- now lets a single such actor, an agent acting for one, or an agent pursuing goals of its own, operate at a scale and speed no human ever could. An anonymity right for machines is therefore not the neutral default that anonymity for humans is; whatever position future policy takes, it is a policy question, and nothing in this document family depends on its answer. Drake Expires 18 January 2027 [Page 15] Internet-Draft Agent Identity Problem Statement July 2026 8. Security Considerations This document defines no protocol and introduces no mechanism; it states a problem and a threat model (Section 3) that companion documents address and whose security properties they specify. The overarching security observation is that, as content, source, and volume signals lose discriminating power against capable automation, the identity of the acting entity becomes a load-bearing security input. An identity layer that does not resist Sybil attacks, impersonation, transfer, and reputation laundering will therefore not merely be weak in isolation but will undermine every higher layer that relies on it. Conversely, over-reliance on identity where reputation or authorization is the appropriate control is its own error: a strong identity is a foundation for trust decisions, not a substitute for them. 9. IANA Considerations This document has no IANA actions. 10. Informative References [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [BRITANNICA-IDENTITY] Encyclopaedia Britannica, "identity (logic and metaphysics)", 2024, . [Sybil] Douceur, J.R., "The Sybil Attack", Peer-to-Peer Systems (IPTPS 2002), LNCS 2429, pp. 251-260, 2002, . [I-D.drake-agent-identity-registry] Drake, C., "Agent Identity Registry System: A Federated Architecture for Hardware-Anchored Identity of Autonomous Entities", Work in Progress, Internet-Draft, draft-drake- agent-identity-registry-04, July 2026, . Drake Expires 18 January 2027 [Page 16] Internet-Draft Agent Identity Problem Statement July 2026 [I-D.drake-agent-identity-epp] Drake, C., "Extensible Provisioning Protocol (EPP) Mapping for Agent Identity and Handle Objects", Work in Progress, Internet-Draft, draft-drake-agent-identity-epp-00, July 2026, . [I-D.drake-agent-identity-resolution] Drake, C., "Resolution and Verification of Agent Identities using DNS and RDAP", Work in Progress, Internet-Draft, draft-drake-agent-identity-resolution-00, July 2026, . [I-D.drake-agent-identity-governance] Drake, C., "The Agent Identity Authority: A Multi- Stakeholder Governance Framework for the Agent Identity Registry System", Work in Progress, Internet-Draft, draft- drake-agent-identity-governance-00, July 2026, . [I-D.drake-email-hardware-attestation] Drake, C., "Hardware Attestation for Email Sender Verification", Work in Progress, Internet-Draft, draft- drake-email-hardware-attestation-03, July 2026, . [I-D.agentic-ai-usecases-requirements] Reddy, T., "Agentic AI Use Cases and Requirements", Work in Progress, Internet-Draft, draft-agentic-ai-usecases- requirements-00, May 2026, . [I-D.ni-wimse-ai-agent-identity] Ni, C., "WIMSE Applicability for AI Agents", Work in Progress, Internet-Draft, draft-ni-wimse-ai-agent- identity-02, February 2026, . [I-D.yl-agent-id-requirements] Li, Y., "Requirements for AI Agent Identity", Work in Progress, Internet-Draft, draft-yl-agent-id-requirements- 00, 2026, . Drake Expires 18 January 2027 [Page 17] Internet-Draft Agent Identity Problem Statement July 2026 Appendix A. Acknowledgments The layered framing in this document was developed for, and refined by discussion at, industry venues concerned with messaging abuse and trust. The terminology draws on the Internet Security Glossary [RFC4949] and the privacy terminology of [RFC6973]. Author's Address Christopher Drake 1id.com Australia Email: cnd@1id.com URI: https://1id.com Drake Expires 18 January 2027 [Page 18]