Identity for Autonomous Agents and Robots: Problem Statement, Threat Model, and Terminology

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.¶

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.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 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.¶

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.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.¶

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.¶

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 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.¶

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.¶

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.¶

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.¶

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.¶