1id.com

Australia cnd@1id.com https://1id.com

Security agent identity AI agents autonomous entities robots Sybil resistance terminology problem statement threat model identity provenance 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.

Introduction 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. 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; 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 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.

Purpose and Audience 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 .

Illustrative Uses This foundation supports two complementary classes of use case:

Durable identity.

Relying parties can reliably record who owns or operates an entity, what it is qualified and authorized to do, and its certifications, reputation, compliance, audit, and incident history. Those associations remain attached to the same entity across changes of credentials, software, hardware, provider, or operator.

Hardware-protected authentication and signing.

Keys intended to resist extraction and cloning provide agents the same class of credential-theft protection that FIDO and passkeys increasingly provide for humans, and can protect signatures over messages, transactions, code, records, and other data without exposing reusable secrets to agent software, prompts, context, or tools.

Scope and Non-Goals The focus of this problem statement, and of the companion series, is the identity0 foundation: 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), and coordination roles are committed to transfer under an independent multi-stakeholder authority (). The problem statement, terminology, and reference model presented here do not depend on adoption of that particular architecture.

Relationship to Other Documents 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 (); an Extensible Provisioning Protocol (EPP) mapping for provisioning those identities between registrars and a registry operator (); an RDAP profile for resolving and verifying them (); a transport binding that carries hardware attestation in email and other protocols (); and a constitution for the governance authority the architecture requires (). 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.

Problem Statement

Scale and Autonomy 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.

What Needs an Identity? 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.

Embodiment and Physical Indistinguishability As agents acquire actuators, the continuity gap 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.

Proxy Signals Are Not Identity 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.

Threat Model 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.

Identity Theft and Impersonation 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; describes the role of hardware anchors.

Identity Manufacture (Sybil Attacks) 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 and .

History Evasion, Erasure, Transfer, and Reassignment 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 and R2.

Terminology 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 and the privacy terminology of where applicable. The terms are for shared understanding and carry no normative force.

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" (; 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 -- 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 -- 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 , 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.

Defined and Adjacent Concepts

Continuity Gap

The failure to preserve a reliable association with the same entity over time when identifiers, credentials, hardware, providers, operators, or other surrounding artifacts change -- or when those artifacts persist but the entity behind them changes.

Identifier

A data object that refers to an identity within a context (, ). 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 remains attached to the same entity: negative reputation must not be escapable by discarding an identity, and positive reputation must not be transferable, purchasable, or inherited by another entity ().

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 hardware protection for an identity key, including resistance to 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 ().

Summary: What "Identity" Is Often Used To Mean The following table lists usages commonly labeled "identity" and the concept this document assigns to each. Common "identity" usages and their precise concept

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)

A Layered Reference Model

Borrowing the Discipline of Layering 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. A layered reference model for agent trust

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

Layering Violations 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 instead. Mutable properties such as operator, role, capability, trust tier, and jurisdiction belong above identity0.

Where Current Efforts Sit, and the Common Gap 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 () and requirements work that discusses pseudonymous or temporary identifiers (, ). 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.

Why the Identity Layer Needs an Anchor 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, R4, and R11. The mechanics of anchoring are specified in the companion documents.

Requirements and Design Goals 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.

R1 Persistence

The identity survives restarts, redeployment, software updates, addition or replacement of hardware anchors (a replaced anchor is permanently retired, never reused), 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. Changes in ownership, custody, operator, provider, or other relationships do not by themselves change which entity the identity denotes, and historical claims, permissions, reputation, and other attributes remain associated with that same identity unless their own semantics specify otherwise. R2 is a rule about what the identity refers to, not a property that cryptography alone can enforce. A protocol can demonstrate continuity of cryptographic control over an identity's anchors; it cannot observe which entity exercises that control. Authorized control can move: a device can be handed over, and a cooperating seller and buyer can present the same transcript as a legitimate hardware migration. A system meets R2 by never reassigning the identity to a different referent and by recording every change of control, so that a transfer cannot silently launder history; deterring covert transfer of control is a matter for governance, contract, and Relying Party policy.

R3 Sybil resistance

Creating additional identities at a Sybil-resistant assurance level consumes a scarce resource in proportion to the number created, not merely a function call ().

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 force disclosure of unnecessary attributes, and pseudonymous presentation is possible where accountability can still be preserved ().

R10 Transport independence

The identity is usable across email, HTTP, agent-to-agent messaging, and protocols not yet defined.

R11 Protection of identity proof

Where a hardware anchor is used, private identity keys are non-exportable through normal interfaces and designed to resist extraction or cloning; cryptographic operations using them occur inside the anchor, so compromise of surrounding software does not by itself expose a reusable credential.

Privacy Considerations A persistent machine identity is intentionally a strong correlator. 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 and R9 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, and ); the EU AI Act likewise treats AI as a regulated system, not a rights-bearing principal (). Whether that should change is a policy question outside this series.

Security Considerations 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 and the anchor properties in 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.

IANA Considerations This document has no IANA actions.

Informative References Encyclopaedia Britannica European Parliament and Council of the European Union Commonwealth of Australia European Parliament and Council of the European Union

Acknowledgments 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 and the privacy terminology of .