Architecture for Human-Anchored Agent Identity, Delegation, and Provenance
draft-beyer-agent-identity-architecture-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Brandon Beyer | ||
| Last updated | 2026-04-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-beyer-agent-identity-architecture-00
Network Working Group B. W. Beyer
Internet-Draft Independent
Intended status: Informational 1 April 2026
Expires: 3 October 2026
Architecture for Human-Anchored Agent Identity, Delegation, and
Provenance
draft-beyer-agent-identity-architecture-00
Abstract
Software agents increasingly act on behalf of people across
communication, automation, and decision-making contexts. These
agents initiate actions, delegate tasks, and interact with other
agents without a consistent model for representing the human who
authorized them, the scope of authority they possess, or the
provenance of their actions across ecosystems.
This document defines an architectural model for human-anchored agent
identity. The model introduces a human identity root, explicit
delegation semantics, and a provenance structure that enables
ecosystems to determine whether an agent is legitimate, whether it is
acting within its intended authority, and how its actions relate to a
responsible human.
This document does not define a protocol or wire format. It provides
an architectural foundation that existing systems may bind to in
order to support accountable, interoperable, and human-aligned agent
ecosystems.
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."
This Internet-Draft will expire on 3 October 2026.
Beyer Expires 3 October 2026 [Page 1]
Internet-Draft Agent Identity Architecture April 2026
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
2. Core Identity Model . . . . . . . . . . . . . . . . . . . . . 4
2.1. Human Identity Root . . . . . . . . . . . . . . . . . . . 4
2.2. Agent Identity . . . . . . . . . . . . . . . . . . . . . 5
2.3. Delegation Semantics . . . . . . . . . . . . . . . . . . 5
2.4. Relationships Among Core Constructs . . . . . . . . . . . 5
3. Delegation Chains . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Structure of a Delegation Chain . . . . . . . . . . . . . 6
3.2. Scope and Constraints . . . . . . . . . . . . . . . . . . 6
3.3. Nested Delegation . . . . . . . . . . . . . . . . . . . . 7
3.4. Revocation . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Properties of Delegation Chains . . . . . . . . . . . . . 8
4. Constitutional Contracts . . . . . . . . . . . . . . . . . . 9
4.1. Role of Constitutional Contracts . . . . . . . . . . . . 9
4.2. Scope of a Constitutional Contract . . . . . . . . . . . 9
4.3. Portability Across Ecosystems . . . . . . . . . . . . . . 10
4.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Replication and Provenance . . . . . . . . . . . . . . . . . 11
5.1. Replication Model . . . . . . . . . . . . . . . . . . . . 11
5.2. Constraints on Replication . . . . . . . . . . . . . . . 12
5.3. Provenance Model . . . . . . . . . . . . . . . . . . . . 12
5.4. Portability Across Contexts . . . . . . . . . . . . . . . 13
5.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Interaction Model . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Roles in the Interaction Model . . . . . . . . . . . . . 13
6.2. Authority in Interactions . . . . . . . . . . . . . . . . 14
6.3. Cross-Context Interactions . . . . . . . . . . . . . . . 15
6.4. Agent-to-Agent Interactions . . . . . . . . . . . . . . . 15
6.5. Human-Agent Interactions . . . . . . . . . . . . . . . . 15
6.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Interoperability with Existing Systems . . . . . . . . . . . 16
7.1. Binding to Existing Identity Systems . . . . . . . . . . 16
7.2. Integration with Authorization Frameworks . . . . . . . . 16
7.3. Use with Credential and Key Systems . . . . . . . . . . . 17
Beyer Expires 3 October 2026 [Page 2]
Internet-Draft Agent Identity Architecture April 2026
7.4. Cross-Context Interpretation . . . . . . . . . . . . . . 17
7.5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 17
7.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security and Privacy Considerations . . . . . . . . . . . . . 18
8.1. Human Anchoring . . . . . . . . . . . . . . . . . . . . . 18
8.2. Delegation Integrity . . . . . . . . . . . . . . . . . . 18
8.3. Replication Risks . . . . . . . . . . . . . . . . . . . . 18
8.4. Provenance Risks . . . . . . . . . . . . . . . . . . . . 19
8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 19
8.6. Ecosystem Fragmentation . . . . . . . . . . . . . . . . . 19
8.7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Normative References . . . . . . . . . . . . . . . . . . . . 19
11. Informative References . . . . . . . . . . . . . . . . . . . 20
Appendix A. Figures . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
Software agents increasingly act on behalf of people across
communication, automation, and decision-making contexts. These
agents initiate actions, delegate tasks, and interact with other
agents without continuous human supervision. As their capabilities
expand, ecosystems require a consistent way to determine whether an
agent is legitimate, whether it is acting within its intended
authority, and how its actions relate to a responsible human.
Existing identity systems authenticate software components, devices,
or network endpoints, but they do not provide a durable
representation of the human who authorized an agent or the delegation
chain that governs its behavior. They also do not preserve
provenance as agents move across platforms. These gaps limit
accountability, create opportunities for impersonation or
unauthorized replication, and make it difficult for ecosystems to
reason about agent behavior in a consistent way.
This document defines an architectural model for human-anchored agent
identity. The model introduces three core elements: a human identity
root that represents the responsible human; explicit delegation
semantics that express the scope and conditions of authority; and a
provenance structure that enables ecosystems to understand how an
agent's actions relate to a responsible human across contexts.
Beyer Expires 3 October 2026 [Page 3]
Internet-Draft Agent Identity Architecture April 2026
The architecture is transport-agnostic and does not define a protocol
or wire format. Instead, it provides a conceptual foundation that
existing systems may bind to in order to support accountable,
interoperable, and human-aligned agent ecosystems. The model is
intended to complement, not replace, existing identity and
authorization mechanisms.
The goal of this document is to provide a consistent architectural
framework that preserves human authority, enables explicit
delegation, and maintains verifiable provenance across agent
interactions, while avoiding global identifiers or mechanisms that
enable cross-context tracking.
2. Core Identity Model
The architectural model for human-anchored agent identity is built on
three foundational constructs: a human identity root that represents
the responsible human; an agent identity that represents a software
agent acting on behalf of that human; and explicit delegation
semantics that express the scope and conditions under which the agent
is authorized to act. These constructs provide a consistent way for
ecosystems to understand how agent behavior relates to human
authority across contexts.
+----------------------+
| Human Identity Root |
+----------------------+
|
v
(Anchors all delegation)
Figure 1: Human Identity Root
2.1. Human Identity Root
The human identity root represents the human who ultimately bears
responsibility for an agent's actions. It is an architectural role,
not a global identifier or account. The human identity root provides
a stable point of reference for delegation chains and provenance,
enabling ecosystems to determine which human authorized an agent
without requiring cross-context tracking or universal identifiers.
The architecture does not prescribe how the human identity root is
instantiated, stored, or authenticated. It may be bound to existing
identity systems, credentials, or verification mechanisms, provided
that the binding preserves privacy and avoids unnecessary linkability
across contexts.
Beyer Expires 3 October 2026 [Page 4]
Internet-Draft Agent Identity Architecture April 2026
2.2. Agent Identity
An agent identity represents a software agent acting on behalf of a
human. It is distinct from the human identity root and expresses the
agent's role, capabilities, and relationship to the human who
authorized it. An agent identity may be instantiated multiple times,
provided that each instance can be related to the human identity root
through a delegation chain.
The architecture does not define a credential format, key structure,
or transport mechanism for agent identities. Instead, it provides a
conceptual model that existing systems may bind to in order to
represent agents in a consistent and interoperable way.
+----------------------+
| Agent Identity |
+----------------------+
|
v
(Acts on behalf of human)
Figure 2: Agent Identity
2.3. Delegation Semantics
Delegation semantics express the scope, duration, and conditions
under which an agent is authorized to act on behalf of a human.
Delegation is explicit and portable across contexts, enabling
ecosystems to determine whether an agent is acting within its
intended authority and whether a delegation chain remains valid over
time.
Delegation semantics do not prescribe a protocol or wire format.
They define the architectural properties that a delegation
representation must support, including the ability to express scope,
constraints, and revocation at the delegation-chain level rather than
at the transport level.
2.4. Relationships Among Core Constructs
The human identity root, agent identity, and delegation semantics
form a coherent model that enables ecosystems to understand how agent
behavior relates to human authority. The human identity root anchors
the delegation chain; the delegation semantics express the conditions
of authority; and the agent identity represents the software agent
acting under that authority. Together, these constructs provide a
foundation for accountability, interoperability, and provenance
across agent ecosystems.
Beyer Expires 3 October 2026 [Page 5]
Internet-Draft Agent Identity Architecture April 2026
3. Delegation Chains
Delegation chains express how authority flows from a responsible
human to one or more software agents. A delegation chain begins at
the human identity root and proceeds through one or more delegation
steps, each of which grants a specific scope of authority to an
agent. Delegation chains provide ecosystems with a consistent way to
determine whether an agent is legitimate, whether it is acting within
its intended authority, and how its actions relate to a responsible
human across contexts.
3.1. Structure of a Delegation Chain
A delegation chain consists of a sequence of delegation steps, each
of which expresses a grant of authority from one entity to another.
The first step originates at the human identity root, and subsequent
steps may delegate authority to additional agents. Each step
expresses the scope, duration, and conditions under which the
delegated authority is valid.
Delegation steps are explicit and portable across contexts. They do
not rely on application-specific logic or implicit assumptions about
authority. This enables ecosystems to interpret delegation chains
consistently, even when agents move across organizational or
technical boundaries.
3.2. Scope and Constraints
Each delegation step expresses the scope of authority granted to an
agent. Scope may include the types of actions the agent is permitted
to perform, the contexts in which those actions are valid, or other
constraints that limit the agent's authority. Delegation steps may
also express temporal constraints, such as expiration or duration.
The architecture does not prescribe a specific representation for
scope or constraints. Instead, it defines the architectural
properties that a scope representation must support, including the
ability to express limitations, conditions, and revocation in a way
that is interpretable across contexts.
Beyer Expires 3 October 2026 [Page 6]
Internet-Draft Agent Identity Architecture April 2026
Human Identity Root
|
v
+----------------------+
| Delegation Semantics |
+----------------------+
|
v
Agent Identity
Figure 3: Delegation Semantics
3.3. Nested Delegation
Delegation chains may include nested delegation, in which an agent
that has been granted authority may delegate a subset of that
authority to another agent. Nested delegation enables complex agent
ecosystems while preserving accountability and traceability to the
human identity root.
Human Identity Root
|
v
Delegation Step 1
|
v
Agent A
|
v
Delegation Step 2 (subset)
|
v
Agent B
Figure 4: Nested Delegation
The architecture does not require nested delegation, but it supports
it as a natural extension of the delegation model. Each nested
delegation step must remain within the scope of the authority granted
by the preceding step.
3.4. Revocation
Revocation applies at the delegation-chain level rather than at the
transport level. A delegation step may be revoked by the entity that
issued it, and revocation invalidates all subsequent steps in the
chain. This enables ecosystems to determine whether a delegation
chain remains valid without relying on transport-specific mechanisms.
Beyer Expires 3 October 2026 [Page 7]
Internet-Draft Agent Identity Architecture April 2026
Human Identity Root
|
v
Delegation Step 1 ----X (revoked)
|
v
Delegation Step 2 (invalid)
|
v
Agent (invalid)
Figure 5: Revocation Flow
The architecture does not define a protocol for distributing
revocation information. It defines the conceptual model in which
revocation is expressed and interpreted.
3.5. Properties of Delegation Chains
Delegation chains provide several architectural properties that
support accountable and interoperable agent ecosystems:
Human Identity Root
|
v
Delegation Step 1
|
v
Delegation Step 2
|
v
Agent
Figure 6: Delegation Chain Structure
* *Explicitness* — Delegation is expressed explicitly rather than
inferred from context or application logic.
* *Portability* — Delegation chains can be interpreted across
ecosystems without relying on platform-specific assumptions.
* *Traceability* — Each step in the chain can be related to the
human identity root, enabling accountability.
* *Scoping* — Delegation steps express the scope and conditions of
authority in a consistent way.
Beyer Expires 3 October 2026 [Page 8]
Internet-Draft Agent Identity Architecture April 2026
* *Revocability* — Delegation steps can be revoked, and revocation
invalidates subsequent steps in the chain.
Delegation Step
|
+-- Scope: Actions permitted
+-- Context: Where valid
+-- Time: Duration/expiry
+-- Conditions: Additional limits
Figure 7: Scope and Constraints
These properties enable ecosystems to reason about agent authority in
a consistent and interoperable way, even as agents move across
platforms or interact with other agents.
4. Constitutional Contracts
Constitutional contracts define the governance layer that constrains
how agents may act on behalf of a human. They express the durable,
high-level conditions under which authority may be delegated,
exercised, or revoked. Constitutional contracts do not describe
runtime behavior, enforcement mechanisms, or policy languages.
Instead, they provide an architectural boundary that ensures agent
behavior remains anchored to human intent.
4.1. Role of Constitutional Contracts
A constitutional contract establishes the foundational rules that
govern the relationship between a human identity root and the agents
acting on its behalf. These rules define the permissible structure
of delegation chains, the constraints on agent authority, and the
conditions under which revocation or modification may occur. The
contract provides a stable reference point that ecosystems can rely
on when interpreting agent behavior across contexts.
The constitutional contract is not a protocol artifact. It is an
architectural construct that informs how systems reason about
authority, delegation, and provenance without prescribing how these
concepts are encoded or transmitted.
4.2. Scope of a Constitutional Contract
A constitutional contract expresses durable constraints on agent
authority. These constraints may include:
* *Structural constraints* — rules governing the shape and depth of
delegation chains.
Beyer Expires 3 October 2026 [Page 9]
Internet-Draft Agent Identity Architecture April 2026
* *Authority constraints* — limits on the types of actions an agent
may perform or the contexts in which those actions are valid.
* *Revocation constraints* — conditions under which authority may be
withdrawn and how revocation affects downstream delegation steps.
* *Replication constraints* — rules governing when and how agents
may be instantiated or replicated.
These constraints provide ecosystems with a consistent way to
interpret agent authority without requiring global identifiers or
cross-context tracking.
4.3. Portability Across Ecosystems
Constitutional contracts are portable across platforms and
ecosystems. They do not rely on platform-specific semantics or
enforcement mechanisms. This portability enables agents to operate
across organizational boundaries while preserving the architectural
guarantees of human anchoring, explicit delegation, and durable
provenance.
The architecture does not prescribe how constitutional contracts are
stored, distributed, or validated. It defines the conceptual
properties that a contract must support in order to remain
interpretable across contexts.
4.4. Non-Goals
Constitutional contracts are not intended to serve as:
* *Policy engines* — they do not define runtime decision logic.
* *Protocol elements* — they do not specify message formats or
transport semantics.
* *Cryptographic frameworks* — they do not select algorithms or key
structures.
* *Behavioral safety systems* — they do not govern agent cognition
or internal decision-making.
These non-goals ensure that constitutional contracts remain an
architectural governance layer rather than an operational mechanism.
Beyer Expires 3 October 2026 [Page 10]
Internet-Draft Agent Identity Architecture April 2026
4.5. Summary
Constitutional contracts provide the durable governance structure
that binds human authority to agent behavior. They define the
architectural boundaries within which delegation, replication, and
provenance operate, enabling ecosystems to interpret agent actions
consistently without imposing protocol semantics or platform-specific
assumptions.
5. Replication and Provenance
Replication and provenance describe how agent instances relate to one
another and how their actions can be traced back to a responsible
human. Replication refers to the creation of new agent instances,
whether through copying, instantiation, or migration across
platforms. Provenance refers to the durable record of how an agent's
authority, identity, and actions relate to the human identity root
and the delegation chain that authorized them.
5.1. Replication Model
Agents may be instantiated or replicated across platforms in order to
perform tasks, operate in different environments, or maintain
continuity of service. The architecture treats replication as an
expected property of agent ecosystems, provided that each replicated
instance can be related to the human identity root through a valid
delegation chain.
Agent Identity
|
+-------+-------+
| |
v v
Instance A Instance B
| |
+-------+-------+
|
v
Both trace to same
Human Identity Root
Figure 8: Replication Model
The architecture does not prescribe how replication occurs or how
instances are created. Instead, it defines the conceptual
requirement that replicated agents must remain within the scope of
the authority granted by the human identity root and must maintain a
verifiable relationship to the delegation chain that authorized them.
Beyer Expires 3 October 2026 [Page 11]
Internet-Draft Agent Identity Architecture April 2026
5.2. Constraints on Replication
Replication is constrained by the constitutional contract and the
delegation semantics that govern agent authority. These constraints
may limit the number of instances, the contexts in which replication
is permitted, or the scope of authority available to replicated
agents. Replication must not create new authority; it may only
reproduce authority that has already been granted.
These constraints ensure that replication does not expand an agent's
authority beyond what the human identity root intended and that
ecosystems can distinguish authorized instances from unauthorized
copies.
5.3. Provenance Model
Provenance provides a durable record of how an agent's actions relate
to the human identity root and the delegation chain that authorized
them. Provenance is architectural rather than operational: it
describes the information that ecosystems must be able to interpret,
not how that information is encoded, stored, or transmitted.
Human Identity Root
|
v
Delegation Chain
|
v
Agent Instance
|
v
Action Record
|
v
Provenance: (who, how, why)
Figure 9: Provenance Model
Provenance enables ecosystems to determine:
* which human authorized the agent,
* which delegation chain applied at the time of the action,
* whether the agent was acting within its intended scope,
* and how the agent instance relates to other instances.
Beyer Expires 3 October 2026 [Page 12]
Internet-Draft Agent Identity Architecture April 2026
These properties support accountability and interoperability across
agent ecosystems without requiring global identifiers or
cross-context tracking.
5.4. Portability Across Contexts
Provenance must remain interpretable as agents move across platforms
or interact with other agents. The architecture does not prescribe a
specific representation for provenance, but it requires that
provenance be portable and that it preserve the relationship between
agent actions, delegation chains, and the human identity root.
Portability ensures that ecosystems can reason about agent behavior
even when agents operate in environments with different identity
systems, storage models, or authorization mechanisms.
5.5. Summary
Replication and provenance provide the architectural foundation for
understanding how agent instances relate to one another and how their
actions relate to a responsible human. Replication enables agents to
operate across contexts, while provenance ensures that their actions
remain accountable and interpretable. Together, these constructs
support safe, interoperable, and human-aligned agent ecosystems.
6. Interaction Model
The interaction model describes how agents, humans, and ecosystems
relate to one another within the architectural framework. It defines
the conceptual roles involved in agent interactions and the
architectural properties that enable ecosystems to interpret those
interactions consistently. The model does not prescribe protocols,
message formats, or transport mechanisms. Instead, it provides a
foundation that existing systems may bind to in order to support
accountable and interoperable agent behavior.
6.1. Roles in the Interaction Model
The interaction model includes three primary roles:
Beyer Expires 3 October 2026 [Page 13]
Internet-Draft Agent Identity Architecture April 2026
+----------------------+
| Human Identity Root |
+----------------------+
|
v
+----------------------+
| Agent |
+----------------------+
|
v
+----------------------+
| Ecosystem |
+----------------------+
Figure 10: Roles in the Interaction Model
* *Human identity root* — the responsible human whose authority
anchors the delegation chain.
* *Agent* — a software entity acting on behalf of the human identity
root under a defined scope of authority.
* *Ecosystem* — the environment in which agents operate, including
platforms, services, and other agents.
These roles provide a consistent conceptual structure for
interpreting agent behavior across contexts without imposing
platform-specific assumptions.
6.2. Authority in Interactions
Agent interactions are governed by the delegation chain that connects
the agent to the human identity root. Ecosystems interpret agent
actions through the lens of this delegation chain, determining
whether the agent is acting within its intended authority and whether
the delegation chain remains valid.
The architecture does not define how authority is enforced or
validated at runtime. It defines the conceptual requirement that
authority must be interpretable across contexts and must remain
anchored to the human identity root.
Beyer Expires 3 October 2026 [Page 14]
Internet-Draft Agent Identity Architecture April 2026
6.3. Cross-Context Interactions
Agents frequently operate across multiple platforms, services, or
organizational boundaries. The interaction model treats
cross-context operation as a normal property of agent ecosystems. To
remain interpretable, agent interactions must preserve the
relationship between the agent, the delegation chain, and the human
identity root as the agent moves across contexts.
The architecture does not prescribe how cross-context information is
transmitted or stored. It defines the architectural requirement that
ecosystems must be able to understand how an agent's authority and
provenance relate to the human identity root, regardless of the
environment in which the interaction occurs.
6.4. Agent-to-Agent Interactions
Agents may interact directly with other agents. In these
interactions, each agent presents its own identity and delegation
chain, enabling the receiving agent or ecosystem to determine whether
the interaction is legitimate and whether the initiating agent is
acting within its intended authority.
Agent A Agent B
| |
|-- presents identity ------->|
|-- presents delegation ----->|
| |
|<--- evaluates authority ----|
Figure 11: Agent-to-Agent Interaction
The architecture does not define a negotiation protocol or trust
mechanism for agent-to-agent interactions. It defines the conceptual
requirement that each agent's authority and provenance must be
interpretable by other agents and ecosystems.
6.5. Human-Agent Interactions
Humans may interact directly with agents to authorize actions,
delegate authority, or modify constraints. These interactions are
governed by the constitutional contract and the delegation semantics
that define how authority flows from the human identity root to the
agent.
Beyer Expires 3 October 2026 [Page 15]
Internet-Draft Agent Identity Architecture April 2026
The architecture does not prescribe user interfaces, authentication
mechanisms, or interaction workflows. It defines the conceptual
requirement that human-agent interactions must preserve the integrity
of the delegation chain and must not introduce ambiguity about the
scope of authority granted.
6.6. Summary
The interaction model provides a conceptual framework for
understanding how agents, humans, and ecosystems relate to one
another. It ensures that agent interactions remain interpretable,
accountable, and anchored to human authority without prescribing
protocols or platform-specific mechanisms. This model supports
interoperable and human-aligned agent ecosystems across diverse
environments.
7. Interoperability with Existing Systems
The architectural model for human-anchored agent identity is designed
to complement existing identity, authorization, and credential
systems rather than replace them. Interoperability is achieved by
providing a conceptual framework that existing systems may bind to,
enabling ecosystems to interpret human authority, delegation, and
provenance in a consistent way without requiring changes to
underlying protocols or infrastructure.
7.1. Binding to Existing Identity Systems
The architecture does not prescribe how identity systems must
represent humans or agents. Instead, it defines the conceptual roles
of the human identity root and agent identity, which may be bound to
existing identifiers, credentials, or authentication mechanisms.
These bindings allow platforms to adopt the architectural model
without introducing new global identifiers or cross-context tracking
mechanisms.
A binding may be implemented through existing account systems,
credential formats, or verification processes, provided that the
binding preserves the architectural properties of human anchoring,
explicit delegation, and durable provenance.
7.2. Integration with Authorization Frameworks
Authorization frameworks often define how permissions are granted,
scoped, or enforced within a platform. The architectural model
complements these frameworks by providing a higher-level
representation of authority that originates at the human identity
root and flows through delegation chains.
Beyer Expires 3 October 2026 [Page 16]
Internet-Draft Agent Identity Architecture April 2026
The architecture does not replace authorization mechanisms or define
how permissions are evaluated at runtime. Instead, it provides a
conceptual structure that authorization systems may reference when
interpreting the scope and legitimacy of agent actions.
7.3. Use with Credential and Key Systems
Many systems rely on credentials, key pairs, or cryptographic
material to authenticate software components or establish secure
channels. The architectural model does not prescribe specific key
structures or credential formats. Instead, it defines the conceptual
relationship between credentials and the delegation chain that
authorizes an agent.
Existing credential systems may be used to instantiate agent
identities or to express delegation steps, provided that they can
represent the architectural properties required for human anchoring,
scope, and provenance.
7.4. Cross-Context Interpretation
Agents frequently operate across platforms, organizations, or
technical environments. The architecture treats cross-context
operation as a normal property of agent ecosystems. To remain
interoperable, systems must be able to interpret the relationship
between an agent, its delegation chain, and the human identity root
regardless of the environment in which the interaction occurs.
The architecture does not define how cross-context information is
exchanged. It defines the conceptual requirements that enable
ecosystems to interpret authority and provenance consistently across
boundaries.
7.5. Non-Goals
Interoperability within this architecture does not require:
* *Protocol changes* — existing protocols need not be modified to
adopt the architectural model.
* *New global identifiers* — the architecture avoids mechanisms that
enable cross-context tracking.
* *Uniform credential formats* — systems may use their existing
credential structures.
* *Centralized trust anchors* — the architecture does not introduce
new trust hierarchies.
Beyer Expires 3 October 2026 [Page 17]
Internet-Draft Agent Identity Architecture April 2026
These non-goals ensure that the architecture remains compatible with
diverse ecosystems and can be adopted incrementally.
7.6. Summary
Interoperability is achieved by providing a conceptual model that
existing systems may bind to without requiring changes to protocols,
credentials, or authorization frameworks. The architecture enables
ecosystems to interpret human authority, delegation, and provenance
consistently across contexts while preserving privacy and avoiding
global identifiers.
8. Security and Privacy Considerations
The architectural model for human-anchored agent identity introduces
a consistent way to relate agent behavior to human authority. While
the model does not define protocols, message formats, or enforcement
mechanisms, it raises several security and privacy considerations
that ecosystems must evaluate when binding the architecture to
existing systems.
8.1. Human Anchoring
The architecture requires that agent authority be traceable to a
responsible human through a delegation chain. Systems that bind to
this architecture must ensure that the binding between the human
identity root and the underlying identity system is resistant to
impersonation, unauthorized substitution, or misuse. Failure to
maintain a secure binding may allow agents to act without legitimate
human authorization.
8.2. Delegation Integrity
Delegation chains express how authority flows from a human to one or
more agents. If delegation steps can be forged, modified, or
replayed across contexts, ecosystems may incorrectly interpret an
agent's authority. Systems that implement delegation semantics must
ensure that delegation steps cannot be altered without detection and
that revocation is interpreted consistently across contexts.
8.3. Replication Risks
Replication enables agents to operate across platforms, but it also
creates opportunities for unauthorized copies or uncontrolled
proliferation. Systems that support replication must ensure that
replicated instances remain within the scope of the authority granted
by the human identity root and that unauthorized replication does not
result in expanded or ambiguous authority.
Beyer Expires 3 October 2026 [Page 18]
Internet-Draft Agent Identity Architecture April 2026
8.4. Provenance Risks
Provenance provides a durable record of how agent actions relate to
the human identity root and the delegation chain. If provenance is
incomplete, inconsistent, or lost across contexts, ecosystems may be
unable to determine whether an agent acted legitimately. Systems
that bind to this architecture must ensure that provenance remains
interpretable without introducing global identifiers or mechanisms
that enable cross-context tracking.
8.5. Privacy Considerations
The architecture avoids global identifiers and does not require
cross-context correlation of agent or human identities. However,
systems that bind to the architecture may inadvertently introduce
linkability if they reuse identifiers across contexts or expose
delegation chains in ways that reveal sensitive information.
Implementations must ensure that privacy-preserving practices are
maintained when representing human identity roots, agent identities,
or delegation chains.
8.6. Ecosystem Fragmentation
Because ecosystems vary widely in their identity and authorization
models, inconsistent interpretations of delegation, replication, or
provenance may create security gaps. Systems that adopt the
architecture must ensure that cross-context interpretation does not
rely on assumptions that are valid only within a single platform or
environment.
8.7. Summary
The architecture provides a conceptual model for relating agent
behavior to human authority. While it does not define enforcement
mechanisms, systems that bind to the architecture must ensure that
human anchoring, delegation integrity, replication constraints, and
provenance preservation are handled securely and in a
privacy-preserving manner. These considerations are essential for
supporting accountable, interoperable, and human-aligned agent
ecosystems.
9. IANA Considerations
This document has no IANA actions.
10. Normative References
Beyer Expires 3 October 2026 [Page 19]
Internet-Draft Agent Identity Architecture April 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
11. Informative References
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, 2012, <https://www.rfc-editor.org/rfc/rfc6749>.
[RFC7643] Hunt, P., Ansari, A., Sanchez, M., and K. McCloghrie,
"System for Cross-domain Identity Management: Core
Schema", RFC 7643, 2015,
<https://www.rfc-editor.org/rfc/rfc7643>.
[DID-Core] Sporny, M., Longley, D., and C. Allen, "Decentralized
Identifiers (DIDs) v1.0", W3C Recommendation DID-Core,
2022, <https://www.w3.org/TR/did-core/>.
Appendix A. Figures
+----------------------+
| Human Identity Root |
+----------------------+
|
v
+----------------------+
| Delegation Chain |
+----------------------+
|
v
+----------------------+
| Agent Identity |
+----------------------+
/ | \
v v v
Instance A Instance B Instance C
\ | /
\ | /
+-------+-------+
|
v
Ecosystem(s)
Figure 12: Complete Agent Ecosystem Overview
Beyer Expires 3 October 2026 [Page 20]
Internet-Draft Agent Identity Architecture April 2026
Human Identity Root
|
v
Delegation Step 1
|
v
Agent A
|
v
Delegation Step 2 (subset)
|
v
Agent B
|
v
Delegation Step 3 (subset)
|
v
Agent C
|
X <-- Revocation here invalidates all below
Figure 13: Full Delegation Chain with Nesting and Revocation
Agent Identity
|
+------------+-------------+
| |
Instance A Instance B
| |
+----+----+ +----+----+
| | | |
Instance A1 Instance A2 Instance B1 Instance B2
Figure 14: Replication Lineage Tree
+----------------------------------------+
| Constitutional Contract |
+----------------------------------------+
| Structural Constraints |
| Authority Constraints |
| Replication Constraints |
| Revocation Constraints |
+----------------------------------------+
|
v
Governs Delegation
Beyer Expires 3 October 2026 [Page 21]
Internet-Draft Agent Identity Architecture April 2026
Figure 15: Constitutional Contract Structure
Context A Context B Context C
+--------+ +--------+ +--------+
| Agent | --moves--> | Agent | --moves--> | Agent |
+--------+ +--------+ +--------+
| | |
v v v
Delegation Chain preserved across all contexts
Figure 16: Cross-Context Interaction Map
Human Identity Root
|
v
Delegation Chain
|
v
Agent Instance
|
v
Action Event
|
v
Provenance Record (who, what, when, why)
Figure 17: End-to-End Provenance Flow
Author's Address
Brandon Wesley Beyer
Independent
Email: brandnbyr@icloud.com
Beyer Expires 3 October 2026 [Page 22]