Agent Transaction Protocol (ATP)
draft-bates-atp-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 | David Asher Bates | ||
| Last updated | 2026-05-11 | ||
| 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-bates-atp-00
Independent Submission D. Bates
Internet-Draft SVT Robotics
Intended status: Informational 10 May 2026
Expires: 11 November 2026
Agent Transaction Protocol (ATP)
draft-bates-atp-00
Abstract
ATP defines a cryptographically verifiable directed acyclic graph
(DAG) model for agent transactions. ATP enables tamper-evident
signed causality and auditable lineage across agentic systems by
representing each action as a signed node with one or more parent
references, assuming verifier access to issuer public keys and the
referenced parent nodes. The protocol is designed to be lightweight,
transport-independent, and suitable for environments where
accountability, provenance, and verifiable history are required.
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 11 November 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.
Bates Expires 11 November 2026 [Page 1]
Internet-Draft ATP May 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 4
1.2. Cumulative Deferrals . . . . . . . . . . . . . . . . . . 5
2. Conventions and Requirements Language . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Architecture Overview . . . . . . . . . . . . . . . . . . . . 8
6.1. Deployment Patterns . . . . . . . . . . . . . . . . . . . 9
7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Node Schema . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Canonicalization . . . . . . . . . . . . . . . . . . . . . . 14
10. Signing and Verification . . . . . . . . . . . . . . . . . . 14
10.1. Node Identity . . . . . . . . . . . . . . . . . . . . . 14
10.2. Signature Algorithm . . . . . . . . . . . . . . . . . . 15
10.3. Signature Computation . . . . . . . . . . . . . . . . . 15
10.4. Verification . . . . . . . . . . . . . . . . . . . . . . 15
11. Heritage and DAG Semantics . . . . . . . . . . . . . . . . . 17
11.1. Identical Content and Idempotency . . . . . . . . . . . 18
12. Scope Model . . . . . . . . . . . . . . . . . . . . . . . . . 18
13. Validation Modes . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Full Recursive Validation . . . . . . . . . . . . . . . 20
13.2. Bounded Validation . . . . . . . . . . . . . . . . . . . 20
13.3. Tip Validation . . . . . . . . . . . . . . . . . . . . . 21
13.4. Redacted-Lineage Validation . . . . . . . . . . . . . . 21
13.5. Minimum Support and Validation Results . . . . . . . . . 21
13.6. Validation Result Format . . . . . . . . . . . . . . . . 22
13.7. ATP Core Conformance . . . . . . . . . . . . . . . . . . 24
14. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14.1. Relay Node Trust Semantics . . . . . . . . . . . . . . . 25
14.2. Relay Fidelity Validation States . . . . . . . . . . . . 27
14.3. Timestamp Trust . . . . . . . . . . . . . . . . . . . . 27
14.4. Signature Scope . . . . . . . . . . . . . . . . . . . . 27
14.5. Trust Model Summary . . . . . . . . . . . . . . . . . . 27
14.6. Suppression and Anti-Suppression . . . . . . . . . . . . 28
14.7. Replay and Scope Binding . . . . . . . . . . . . . . . . 29
15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
15.1. Data Minimization . . . . . . . . . . . . . . . . . . . 29
15.2. Deletion and Retention Tension . . . . . . . . . . . . . 30
15.3. Chain Existence as Metadata . . . . . . . . . . . . . . 30
15.4. Pseudonymous Identifiers and Post-Deletion
Verification . . . . . . . . . . . . . . . . . . . . . . 31
16. Operational Considerations . . . . . . . . . . . . . . . . . 31
16.1. Key Lifecycle . . . . . . . . . . . . . . . . . . . . . 31
16.2. Request/Completion Pairing . . . . . . . . . . . . . . . 32
16.3. Cross-Scope Resolution . . . . . . . . . . . . . . . . . 33
Bates Expires 11 November 2026 [Page 2]
Internet-Draft ATP May 2026
16.4. Actor Mapping Guidance . . . . . . . . . . . . . . . . . 34
16.5. Agent Versioning Guidance . . . . . . . . . . . . . . . 34
16.6. Issuer Identity Granularity . . . . . . . . . . . . . . 35
16.7. Storage Model Guidance . . . . . . . . . . . . . . . . . 36
16.8. Permissioned Verifiability . . . . . . . . . . . . . . . 37
16.9. Deletion and Redaction Operations . . . . . . . . . . . 38
16.10. Performance Budget Guidance . . . . . . . . . . . . . . 39
16.11. Node Granularity Guidance . . . . . . . . . . . . . . . 40
16.12. Chain Exchange Patterns . . . . . . . . . . . . . . . . 41
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
17.1. ATP Action Types Registry . . . . . . . . . . . . . . . 42
17.2. ATP Profiles Registry . . . . . . . . . . . . . . . . . 44
17.3. URN Sub-Namespace Registration . . . . . . . . . . . . . 45
18. Implementation Status . . . . . . . . . . . . . . . . . . . . 45
19. Profile Framework . . . . . . . . . . . . . . . . . . . . . . 46
19.1. Profile Identifiers . . . . . . . . . . . . . . . . . . 46
19.2. Profile Versioning . . . . . . . . . . . . . . . . . . . 47
19.3. Minimum Profile Contract . . . . . . . . . . . . . . . . 48
19.4. Canonicalization of Profile-Defined Fields . . . . . . . 49
19.5. Conformance Levels . . . . . . . . . . . . . . . . . . . 50
19.6. Worked Profile Reference . . . . . . . . . . . . . . . . 50
19.7. Profile Assessment States . . . . . . . . . . . . . . . 50
20. Normative References . . . . . . . . . . . . . . . . . . . . 51
21. Informative References . . . . . . . . . . . . . . . . . . . 52
Worked Example: MCP Tool Discovery and Invocation . . . . . . . . 53
A.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 53
A.2 Node Sequence . . . . . . . . . . . . . . . . . . . . . . . 54
Node 1 -- tool catalog query (atp:request) . . . . . . . . . 54
Node 2 -- tool catalog response (atp:completion) . . . . . . 55
Node 3 -- tool selection decision (atp:decision) . . . . . . 56
Node 4 -- tool invocation request (atp:request) . . . . . . . 56
Node 5 -- tool execution (atp:completion) . . . . . . . . . . 57
Node 6 -- tool execution response (atp:relay) . . . . . . . . 57
Node 7 -- decision synthesis (atp:decision) . . . . . . . . . 58
A.3 DAG Structure . . . . . . . . . . . . . . . . . . . . . . . 58
A.4 What This Example Demonstrates . . . . . . . . . . . . . . 60
A.5 Profile Note: action.type and action.subtype Vocabulary . . 61
Future Work and Areas for Further Refinement . . . . . . . . . . 61
Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 62
C.1 Identity and Authentication . . . . . . . . . . . . . . . . 63
C.2 Agent Communication Frameworks . . . . . . . . . . . . . . 63
C.3 Domain-Specific Governance . . . . . . . . . . . . . . . . 63
C.4 Standards Coordination . . . . . . . . . . . . . . . . . . 64
C.5 Existing RFCs Applied to Agent Systems . . . . . . . . . . 64
C.6 Transparency and Supply-Chain Provenance . . . . . . . . . 64
C.7 ATP's Distinct Contribution . . . . . . . . . . . . . . . . 65
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 65
Bates Expires 11 November 2026 [Page 3]
Internet-Draft ATP May 2026
1. Introduction
Agentic systems are rapidly increasing in autonomy, composition, and
reach. Agents now invoke tools, delegate work to other agents,
operate across service boundaries, and act on behalf of both humans
and non-human principals. Existing observability and identity
standards solve parts of this problem, but they do not fully answer a
more difficult governance question: can an independent verifier prove
what action occurred, what prior actions caused it, and under whose
authority it was taken?
ATP is intended to address that gap. ATP does not attempt to replace
existing identity, authorization, transport, or observability
mechanisms. Instead, ATP defines a minimal protocol for expressing
agent actions as signed graph nodes with explicit parent references.
This makes the resulting lineage tamper-evident; independent
verification requires access to issuer public keys and parent nodes
through deployment-specific mechanisms.
ATP is designed around causality rather than simple sequencing.
Linear logs can describe what happened next, but complex agent
systems require a model that can express branching, merging,
delegation, and parallelism. ATP therefore adopts a DAG model so
that the protocol can represent heritage truthfully rather than
forcing artificial ordering.
1.1. Document Scope
This document defines *ATP Core*: the node schema, canonicalization,
signing, validation, scope model, validation modes, security
considerations, privacy considerations, operational guidance, IANA
registries, and a Profile Framework that establishes how profiles MAY
extend or constrain Core.
Profile-specific rules -- including domain-specific action-type
vocabularies, emission and node-worthiness rules, sealed-scope
semantics, composite conformance labels, the full profile
specification template, and profile registration procedures -- are
defined in separate profile specifications registered under the ATP
Profiles registry (see Section 17.2 and Section 20). One
illustrative example of such a profile is an ATP-MCP profile that
defines composite conformance labels such as ATP-MCP-L1, ATP-MCP-L2,
or ATP-MCP-L3 for chains describing Model Context Protocol [MCP]
interactions; ATP-MCP is one possible profile among many and is not
specially privileged by ATP Core. The companion document
[ATP-PROFILES] is one such specification and is not normatively
required to use ATP Core.
Bates Expires 11 November 2026 [Page 4]
Internet-Draft ATP May 2026
1.2. Cumulative Deferrals
ATP Core intentionally defers several operational concerns to
deployments and future specifications: key discovery (Section 16.1),
cross-scope retrieval and federation (Section 16.3), transport
binding, deletion mechanisms (Section 16.9), well-known URI
registration (Section 17.3), and algorithm agility (Section 10).
Each individual deferral is a deliberate scope-discipline choice.
Cumulatively, the minimum operationally complete deployment between
two strangers therefore requires out-of-spec agreements on key
publication, node availability, and transport. Deployments that
cannot reach those agreements out-of-band SHOULD layer ATP with a
transparency service or federation profile (Section 14.6,
Section C.6) rather than expanding ATP Core.
2. Conventions and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
For the purposes of this document:
* *Node:* A single ATP transaction object.
* *Parent:* A referenced prior node that contributes to the current
node's heritage.
* *Heritage:* The recursively traversable causal lineage of a node.
* *Issuer:* The entity that signs the node.
* *Agent:* The execution identity that performed the action. An
agent MAY be any executable identity -- a software service, an AI
model, a robotic system, an automated process, or a human operator
acting through an instrumented interface. ATP does not assume an
agent is an AI model; the term is used in its general sense of
"the entity that took the action."
* *Actor:* An OPTIONAL delegating principal on whose behalf the
action was taken. The actor is distinct from the agent: the agent
performs the action, the actor authorizes it. An actor MAY be a
human, a service account, a scheduled-job identity, or another
accountable non-human principal.
Bates Expires 11 November 2026 [Page 5]
Internet-Draft ATP May 2026
* *Scope:* The transaction boundary within which node identity and
validation semantics are evaluated.
* *Validation:* The act of recomputing node identity, verifying
signatures, and traversing parent relationships according to ATP
rules.
* *Profile:* A normative specification that extends or constrains
ATP Core for a specific deployment context, domain, or
interoperability scope (see Section 20).
* *Profile Assessment:* A profile-defined evaluation of whether a
node or scope satisfies a profile's emission, lineage, or
completion rules. Profile assessment is distinct from ATP Core
validation (see Section 20.7).
3. Problem Statement
Modern agentic systems create a governance gap. An action may be
initiated by one principal, delegated to an orchestrator, enriched by
multiple subordinate agents, and executed through tools or downstream
systems. Traditional logs can record these events, but they are
frequently mutable, centralized, or unable to prove lineage
independently of the platform that produced them. Likewise, identity
tokens can prove who was authenticated, but they do not provide a
durable, linked record of what happened across a causal graph of
actions.
This creates operational and governance problems, including but not
limited to agent sprawl, weak accountability, incomplete audit
trails, and difficulty reconstructing a trustworthy history of
actions after an incident. ATP is intended to provide a common
protocol layer for verifiable agent-action lineage without requiring
a blockchain, without embedding large payloads, and without taking
ownership of broader policy or trust-distribution concerns.
4. Design Goals
ATP is designed to satisfy the following goals:
* *Verifiable causality:* An implementation can determine what prior
node or nodes caused a current action.
* *Tamper-evident heritage:* Changes to a node or its referenced
lineage invalidate downstream verification.
* *Deterministic identity:* Independently implemented systems can
compute the same node identity from the same canonical content.
Bates Expires 11 November 2026 [Page 6]
Internet-Draft ATP May 2026
* *Lightweight representation:* ATP carries hashes and lineage
references rather than full payload bodies.
* *Transport independence:* ATP is not bound to a specific
transport, runtime, vendor, or model provider.
* *Role separation:* Issuer, agent, and actor are represented
distinctly so that governance questions can be answered without
conflating execution identity and delegated authority.
* *DAG-native semantics:* ATP models branching and merging natively
rather than forcing complex systems into an artificial linear
chain.
5. Non-Goals
ATP intentionally does not define several adjacent concerns.
ATP Core does not define:
* trust registries or cross-organization trust anchors;
* key distribution, discovery, or long-term revocation
infrastructure;
* payload storage or payload confidentiality controls;
* authorization policy or runtime access control decisions;
* consensus mechanisms or conflict resolution across divergent
histories;
* execution semantics for how agents, tools, or workflows must
behave;
* profile governance procedures, the profile specification template,
or composite conformance labels (those are defined by individual
profile specifications and by [ATP-PROFILES]);
* domain-specific node-worthiness, streaming semantics, or sealed-
scope mechanisms (those are profile responsibilities, see
Section 20);
* anti-suppression mechanisms (see Section 14.6); a transparency-
service layer such as a SCITT-compatible service (see Section C.6)
MAY be composed alongside ATP where anti-suppression is required.
Bates Expires 11 November 2026 [Page 7]
Internet-Draft ATP May 2026
Those concerns may be layered alongside ATP Core, but keeping them
out of the core protocol is necessary to preserve implementability,
interoperability, and scope discipline.
6. Architecture Overview
ATP is a protocol layer, not a full platform. ATP assumes that
systems already have mechanisms for transport, execution, payload
storage, and authorization. ATP adds a verifiable transaction layer
that can travel alongside those mechanisms.
ATP is intentionally domain-neutral. It is suitable for AI agent
orchestration, but equally suitable for any system that benefits from
cryptographically signed, causally linked records of actions.
Illustrative use cases include (non-exhaustively): an insurance
underwriting workflow recording the chain of claim adjudication
decisions; a fraud-detection pipeline recording each scoring step and
the data used; a regulated medical-triage system recording why one
path was selected over another; a supply-chain routing system
recording handoffs between carriers; or any orchestrator-and-tool
architecture (the pattern Appendix A illustrates). The protocol
mechanics -- DAG-structured signed nodes with deterministic identity
-- are the same in all cases.
At a high level, an ATP-aware system performs the following steps for
each action:
1. Construct a transaction node describing the action.
2. Canonicalize the node according to ATP rules.
3. Compute the node identifier from the canonical content.
4. Sign the node identifier using the issuer's private key.
5. Store, emit, or transmit the signed node through implementation-
specific means.
6. Validate the node and its parents when lineage or integrity must
be verified.
ATP is intentionally compatible with centralized or decentralized
storage patterns. A deployment MAY keep nodes in an append-only
event store, a content-addressed object store, a relational database,
or another storage substrate, provided ATP node integrity and parent
resolution semantics are preserved.
Bates Expires 11 November 2026 [Page 8]
Internet-Draft ATP May 2026
6.1. Deployment Patterns
ATP does not mandate a single deployment topology. Three patterns
are common; deployments MAY combine them.
*Pattern 1 -- Inline emission.* The executor that performs the action
also constructs, signs, and persists the ATP node. The request node
is constructed and signed _before_ the action is invoked (its
inputHash covers the request payload); the completion or failure node
is constructed and signed _after_ the action returns (its outputHash
covers the result). This pattern requires the executor to hold
issuer key material directly. It is the lowest-overhead pattern and
is appropriate when the executor is the natural signing-authority
boundary.
*Pattern 2 -- Sidecar emission.* The executor delegates ATP node
construction and signing to a co-located ATP-emit service. The
executor calls the sidecar with action metadata; the sidecar
canonicalizes, signs, and persists. This pattern centralizes key
custody at the sidecar boundary and is appropriate when the executor
cannot or should not hold private key material directly.
*Pattern 3 -- Centralized audit service.* A separate service observes
executor activity (via instrumentation, message-bus subscription, log
shipping, or an explicit emit API) and constructs ATP nodes on the
executor's behalf. In this pattern the _audit service_ is the
issuer, signing under its own key, and the executor is identified in
the agent field. This pattern is appropriate when executors cannot
be modified to participate in ATP directly.
Storage MAY be centralized (a shared node store accessible to all
issuers) or decentralized (each issuer maintains its own store, with
cross-issuer references resolved via Section 16.3 cross-scope
mechanisms). ATP does not prescribe; the choice is operational.
Implementations SHOULD document which pattern they implement so
verifiers can correctly interpret the meaning of unresolved parent
references in the chosen topology (Section 14.5, Section 14.6).
7. Data Model
ATP models agent actions as nodes in a directed acyclic graph.
A node MAY have zero parents, one parent, or multiple parents:
* A node with zero parents is a root node.
* A node with one parent expresses a simple causal dependency.
Bates Expires 11 November 2026 [Page 9]
Internet-Draft ATP May 2026
* A node with multiple parents expresses fan-in, merge, or
synthesized heritage.
Multiple child nodes MAY reference the same parent. ATP therefore
supports fan-out naturally.
The following diagram illustrates these structural patterns:
graph TD
A["Root Node<br/>(0 parents)"] --> B["Node B<br/>(1 parent)"]
A --> C["Node C<br/>(1 parent)"]
B --> D["Node D<br/>(2 parents)"]
C --> D
C --> E["Node E<br/>(1 parent)"]
style A fill:#2E75B6,color:#fff
style B fill:#4A90D9,color:#fff
style C fill:#4A90D9,color:#fff
style D fill:#D94A4A,color:#fff
style E fill:#4A90D9,color:#fff
In this diagram:
* *Node A* is a root node with zero parents.
* *Nodes B and C* demonstrate fan-out: both reference Node A as a
parent.
* *Node D* demonstrates fan-in: it references both Node B and Node C
as parents, merging two causal lineages.
* *Node E* demonstrates a simple linear dependency on Node C.
ATP does not require total ordering across all nodes in a trust
domain. The protocol is designed to preserve causal relationships
rather than impose a global sequence. Implementations that require
ordering MUST provide that behavior outside ATP or as a profile
layered on top of ATP.
A valid ATP graph MUST be acyclic. No node may directly or
indirectly reference itself through its parent relationships.
8. Node Schema
An ATP node is a structured object containing identity, causality,
and signature material. The following fields are defined in the base
model:
Bates Expires 11 November 2026 [Page 10]
Internet-Draft ATP May 2026
* *nodeId:* The deterministic identifier of the node.
* *timestamp:* The claimed creation time of the node.
* *scope:* The boundary within which the node's identity and lineage
are evaluated.
* *issuer:* The signing authority for the node. issuerId identifies
a signing-authority boundary (see Section 16.6).
* *agent:* The execution identity that performed the action.
agent.version SHOULD change whenever the agent's decision-
producing configuration changes (see Section 16.5).
* *actor:* An OPTIONAL delegating principal on whose behalf the
action occurred (see Section 16.4).
* *action:* A description of the action and references to relevant
payload hashes. Depending on node type, one or both of inputHash
and outputHash MAY be present.
* *parents:* An ordered array of zero or more parent node
identifiers. Each entry MUST be a nodeId value as defined in
Section 10.1. The order of parents is significant for
canonicalization (Section 9) but has no semantic priority unless a
profile explicitly defines parent-position semantics. A parents
array MUST NOT contain duplicate nodeId values unless a profile
explicitly defines multiplicity semantics.
* *profile:* OPTIONAL. Identifies the ATP profile (see Section 20)
whose additional rules apply to this node. When absent, ATP Core
rules apply exclusively.
* *signature:* The cryptographic signature over the node identifier.
The base schema is as follows:
Bates Expires 11 November 2026 [Page 11]
Internet-Draft ATP May 2026
{
"nodeId": "hex(SHA256(canonical_node))",
"timestamp": "RFC3339",
"scope": "string",
"issuer": {
"issuerId": "string",
"keyId": "string"
},
"agent": {
"agentId": "string",
"version": "string"
},
"actor": { // OPTIONAL -- see below
"actorId": "string",
"authContext": "string"
},
"action": {
"type": "string",
"inputHash": "hex",
"outputHash": "hex" // OPTIONAL -- see below
},
"parents": ["nodeId"],
"profile": "string", // OPTIONAL -- see Section 20.1
"signature": "base64"
}
The example above is illustrative; fields annotated as OPTIONAL MAY
be omitted as defined in the surrounding prose. Per Section 9,
omitted fields do not appear in the canonical form and do not affect
nodeId computation.
The actor object is OPTIONAL. Actor identifies the delegating
principal whose authority the agent is acting under. That principal
MAY be a human, a service account, a scheduled-job identity, or
another accountable non-human principal. When no delegating
principal exists, actor is omitted. Such omission is meaningful: it
indicates the action was not taken on behalf of an accountable
principal.
Bates Expires 11 November 2026 [Page 12]
Internet-Draft ATP May 2026
When actor is omitted, validators MUST NOT treat the omission as
missing data; the omission is itself a normative claim that no
delegating principal exists. Implementations that fail to record an
actor when one exists are emitter-side governance failures, not
protocol ambiguities. Validators have no protocol-level mechanism to
distinguish accidental omission from autonomous-action omission;
deployments requiring that distinction MUST address it operationally
-- for example, through emitter-side governance, profile-defined
actor-required rules (per Section 20.3 node-worthiness), or out-of-
band audit policy. Profiles MAY further constrain when actor MUST be
present.
Within the action object, outputHash is OPTIONAL in the base
protocol. A node MAY omit outputHash when the action's outcome is
not yet known at emission time (see Section 16.2 for the request/
completion pairing pattern).
The profile field is OPTIONAL. When present, validators MUST apply
the validation rules of the identified profile in addition to ATP
Core rules (see Section 20.1 and Section 20.4).
All other top-level fields shown above are REQUIRED unless a future
profile or extension explicitly states otherwise.
Profiles MAY define additional top-level fields and additional fields
within the action object as specified in Section 20.3 and
Section 20.4. For example, profiles MAY add fields such as
action.subtype; Appendix A illustrates this pattern.
A *decisional node* is a node that records a selection, policy
decision, or synthesis without a direct invocation of an external
system. Decisional nodes typically use inputHash to reference the
material the decision was based on and outputHash to reference the
decision rationale or output. The atp:decision action type
(Section 17.1) is the canonical core action type for decisional
nodes; Appendix A illustrates decisional-node usage in a multi-issuer
chain.
A *relay node* is a node whose action semantics assert that input was
forwarded without modification. Relay nodes have unique trust
semantics that differ from request/completion semantics; full
treatment is in Section 14.1, with relay-fidelity validation states
defined in Section 14.2.
Bates Expires 11 November 2026 [Page 13]
Internet-Draft ATP May 2026
9. Canonicalization
Canonicalization is REQUIRED for ATP interoperability. Two
conforming implementations presented with the same ATP node content
MUST produce the same canonical byte sequence before hashing.
ATP implementations MUST canonicalize nodes according to RFC 8785
JSON Canonicalization Scheme (JCS) [RFC8785].
Before hashing:
* object keys MUST be sorted according to RFC 8785;
* UTF-8 encoding MUST be used;
* insignificant whitespace MUST NOT be included;
* arrays MUST preserve their declared order;
* null-valued fields MUST be omitted unless a future ATP profile
explicitly defines otherwise.
Because canonicalization is foundational to deterministic identity,
implementations that do not use RFC 8785 JCS are not conformant with
this draft.
10. Signing and Verification
10.1. Node Identity
The node identifier is computed as:
nodeId = SHA256(canonical(node_without_signature))
The signature field itself MUST NOT be included in canonicalization
or nodeId computation. The nodeId field, when present in a node
representation, MUST also NOT be included in its own
canonicalization. The nodeId is the _output_ of canonicalization
plus hashing; its inclusion in the input would be circular.
Implementations computing or recomputing nodeId over a stored or
transmitted node MUST first remove both nodeId and signature before
canonicalization. Parent references, scope, timestamp, issuer,
agent, actor (when present), profile (when present), and action
fields MUST be included. Profile-defined fields, when present, MUST
be included as specified in Section 20.4.
Bates Expires 11 November 2026 [Page 14]
Internet-Draft ATP May 2026
ATP Core mandates SHA-256 for nodeId computation. ATP Core does not
define a hash-algorithm-agility mechanism. This is intentional and
keeps the protocol simple at the cost of forward flexibility; if
cryptographic developments require a different hash algorithm, that
capability will be introduced in a future ATP Core revision or
profile rather than negotiated within this version.
10.2. Signature Algorithm
Implementations conforming to this draft MUST support Ed25519
[RFC8032].
Additional algorithms MAY be supported by future ATP profiles, but
interoperable baseline implementations MUST support Ed25519. ATP
Core does not define a signature-algorithm-agility mechanism; the
same forward-compatibility rationale stated for hash algorithms
(Section 10.1) applies.
10.3. Signature Computation
The signature is computed over the nodeId:
signature = Sign(privateKey, nodeId)
The key used to generate the signature MUST correspond to
issuer.keyId.
10.4. Verification
A node is *fully lineage-valid* under ATP only if all of the
following conditions hold:
1. The node can be canonicalized successfully.
2. The nodeId recomputes exactly from the canonicalized node content
excluding signature.
3. The signature validates against the issuer key identified by
issuer.keyId.
4. All referenced parent nodes can be resolved in the relevant
verification context.
5. All referenced parent nodes are themselves fully lineage-valid
according to ATP rules.
6. No cycle is introduced by the node's parent relationships.
Bates Expires 11 November 2026 [Page 15]
Internet-Draft ATP May 2026
Conditions 1, 2, 3, and 6 together establish *node-level integrity*
and apply to every validation mode. Conditions 4 and 5 establish
*lineage validity* and apply only to validation modes that resolve
parent nodes (full recursive validation per Section 13.1, and bounded
validation within its declared boundary per Section 13.2). Tip
validation (Section 13.3) intentionally does not resolve parents and
therefore does not establish lineage validity.
Validation modes other than full recursive validation MAY produce
mode-specific validation results as defined in Section 13. An
implementation MUST NOT represent the result of tip validation,
bounded validation, or redacted-lineage validation as full lineage
validation.
A node with unresolved, invalid, or withheld parents MUST NOT be
treated as fully lineage-valid in any verification context.
Conflict resolution between multiple valid child nodes that reference
the same parent is out of scope for ATP.
If a validator cannot retrieve the public key for the (issuerId,
keyId) pair identified in a node, the node MUST be reported as
keyUnresolved in the validation result. A key-unresolved node MUST
NOT be treated as cryptographically valid, and MUST NOT be classified
as invalid. The keyUnresolved state is distinct from: an invalid
node, whose key is available but whose signature verification fails;
and an unresolved parent, whose content cannot be obtained in the
current verification context.
A keyUnresolved node has not established node-level integrity, even
when canonicalization succeeds and nodeId recomputes correctly.
Node-level integrity (conditions 1, 2, 3, and 6 above) requires
successful signature verification, which is impossible without the
issuer key. Implementations MUST NOT report a key-unresolved node in
the verified set of any validation mode.
When a parent node is keyUnresolved, the parent's signature cannot be
verified. A child node referencing such a parent retains its own
node-level integrity (assuming conditions 1, 2, 3, and 6 hold for the
child's own content), but its *lineage validity is not established*
for as long as the parent remains key-unresolved. Validators MUST
report the parent under keyUnresolved and MUST NOT report the child
as fully lineage-valid in that validation run. A subsequent re-
validation that obtains the parent's public key MAY restore lineage
validity for the child without re-signing the child, since the
child's signature covers its own nodeId only.
Bates Expires 11 November 2026 [Page 16]
Internet-Draft ATP May 2026
11. Heritage and DAG Semantics
Heritage is the complete set of ancestor nodes reachable by
recursively following parent references from a given node. Heritage
establishes the causal lineage of an action.
ATP heritage has the following properties:
* *Transitivity.* If node C references node B as a parent, and node
B references node A as a parent, then node A is part of node C's
heritage.
* *Tamper evidence.* Because each nodeId is computed from canonical
content that includes parent references, modifying any ancestor
invalidates the nodeId of every descendant that references it,
directly or transitively.
* *Non-exclusivity.* A node's heritage may include nodes signed by
multiple issuers, spanning multiple scopes, and representing
actions taken by multiple agents. Heritage is a graph property,
not an ownership property.
Heritage traversal is the mechanism by which validators answer causal
questions: "what caused this action?" is answered by walking parent
edges; "was this action derived from a specific prior action?" is
answered by checking whether a given nodeId appears in the heritage
of the node under inspection.
ATP does not define a required traversal algorithm. Implementations
MAY use depth-first, breadth-first, or other graph-traversal
strategies. The protocol requires only that heritage traversal
follows parent references and that each traversed node is subject to
the applicable validation mode (see Section 13).
Because ATP graphs are DAGs, heritage traversal is guaranteed to
terminate. The acyclicity constraint (Section 7) ensures that no
traversal path can loop.
Fan-in nodes -- nodes with multiple parents -- create heritage that
merges two or more causal lineages. This is intentional and
necessary for representing actions that depend on multiple prior
results, such as a synthesis that combines a tool execution result
and a prior selection decision. Heritage traversal through a fan-in
node follows all parent edges.
Bates Expires 11 November 2026 [Page 17]
Internet-Draft ATP May 2026
11.1. Identical Content and Idempotency
Because nodeId is content-addressed (Section 10.1), two emissions
that produce identical canonical content will produce identical
nodeId values. ATP treats such emissions as the same logical node: a
verifier that encounters the same nodeId twice MAY deduplicate, and
storage substrates MAY reject the second write as an idempotent no-
op.
Where two distinct emissions are intended to be distinct nodes (for
example, two retries of the same operation), emitters MUST ensure
that some canonical field differs. Practical mechanisms include:
* a high-precision timestamp (sub-millisecond) so concurrent
emissions are distinguishable;
* a profile-defined nonce field that participates in
canonicalization per Section 20.4;
* a sequence number embedded in agent.version or another canonical
field;
* distinct inputHash values when the underlying request payloads
differ.
Emitters that allow identical canonical content for genuinely-
distinct actions accept the consequence that those actions collapse
into a single ATP node. This is sometimes desirable (the same
logical event observed twice) and sometimes a correctness bug (two
retries that should be separately auditable). Profiles MAY mandate a
freshness mechanism for emission contexts where collapse is
unacceptable.
12. Scope Model
Scope is REQUIRED on every ATP node.
Scope identifies the transaction boundary to which the node belongs.
In typical deployments, a scope corresponds to one workflow
execution, one request lifecycle, or one business transaction. ATP
does not impose a global meaning beyond that boundary concept. Scope
values SHOULD be unique per transaction and SHOULD be shared by all
nodes that belong to the same transaction; that is, scope is a
transaction-level identifier, not a node-level identifier.
Bates Expires 11 November 2026 [Page 18]
Internet-Draft ATP May 2026
Scope is an opaque string. ATP does not define or constrain its
format. Implementations MAY use UUIDs, URNs, structured identifiers,
or other stable values. Nodes that belong to the same transaction
boundary SHOULD share the same scope value.
Each parents entry is a nodeId. Because nodeId is content-addressed
and scope is a field inside the referenced node rather than part of
the parent reference itself, parent references are scope-agnostic by
definition.
Parent references MAY target nodes in the same scope or in different
scopes. Cross-scope parent references are therefore PERMITTED.
When a validator resolves a parent node and discovers that the
parent's scope differs from the current node's scope, that difference
is not an error condition. The validator MUST proceed with normal
ATP verification. If a parent nodeId can be resolved to content but
the parent's declared scope differs from the current node's scope
(including when the parent was obtained through out-of-band
retrieval), the validator MUST still apply full ATP validation to the
parent content; scope mismatch alone is not a validation failure.
A validator operating within a given verification context MUST
attempt to resolve referenced parent nodes regardless of whether they
are in the same scope or a different scope.
If a referenced parent node is obtained and fails ATP verification,
that parent is *invalid*.
If a referenced parent node cannot be obtained in the current
verification context -- including because the validator lacks access
to the relevant scope, the referenced scope is unavailable, or
verification is restricted to a single scope -- that parent is
*unresolved*. The parent is not absent; it is simply not reachable in
the current verification context.
Validators MUST distinguish between invalid parents and unresolved
parents.
Full lineage verification requires access to all referenced parent
nodes across all relevant scopes. Implementations MAY provide
bounded or partial validation modes (see Section 13), but such modes
MUST NOT treat unresolved parents as valid.
Bates Expires 11 November 2026 [Page 19]
Internet-Draft ATP May 2026
Scope participates in nodeId computation in the same way as other
canonical node fields. Two nodes that are identical except for
different scope values therefore produce different nodeId values.
This is intentional: the same action in two different transaction
contexts is represented as two different ATP nodes.
Because parent references are made to nodeId values rather than to
scope membership, cross-scope heritage does not weaken ATP integrity
semantics. It does, however, affect what a validator can practically
resolve and verify in a given environment.
13. Validation Modes
Validation modes are verifier-side behaviors. ATP nodes are written
the same way regardless of which validation mode a future verifier
uses. Validation modes therefore affect how heritage is read and
checked, not how nodes are emitted.
ATP defines four validation modes.
13.1. Full Recursive Validation
In full recursive validation, the validator resolves every parent
recursively back to every reachable root node within the available
verification context. Each traversed node MUST be canonicalized, its
nodeId MUST be recomputed, its signature MUST be verified, and the
traversed heritage MUST satisfy ATP DAG constraints, including
acyclicity.
This mode provides the strongest lineage claim and is appropriate for
incident forensics, regulatory audit, and dispute resolution. Full
recursive validation is the only mode that establishes full lineage
validity per Section 10.4.
13.2. Bounded Validation
In bounded validation, the validator declares a verification
boundary, such as a depth horizon (e.g., "verify this node and 3
generations of parents") or a time horizon (e.g., "verify back to
nodes created after timestamp T"). Every node within that declared
boundary MUST be fully validated according to ATP rules. Parent
nodes beyond the declared boundary are not re-verified in that
validation run and MUST be reported as out-of-horizon.
This mode is appropriate for operational health checks, real-time
monitoring, and performance-constrained environments. Bounded
validation establishes lineage validity only within its declared
horizon.
Bates Expires 11 November 2026 [Page 20]
Internet-Draft ATP May 2026
13.3. Tip Validation
In tip validation, the validator verifies only the node under
inspection. The node MUST be canonicalized, its nodeId MUST be
recomputed, and its signature MUST be verified. Declared parent
references MUST be checked for structural presence, but parent nodes
are not resolved or verified.
This mode is appropriate for ingestion-time integrity checks and
other scenarios where the primary question is whether the node itself
arrived intact. Tip validation establishes node-level integrity per
Section 10.4 but does not establish lineage validity.
13.4. Redacted-Lineage Validation
In redacted-lineage validation, the validator is given a partial
lineage in which one or more nodes are intentionally withheld for
confidentiality, access-control, or privacy reasons. A withheld node
MAY be represented by nodeId alone. In this mode, the validator can
confirm that downstream nodes reference specific parent nodeIds, but
cannot validate the withheld node's content or signature unless the
withheld node is later made available.
Withheld nodes are distinct from unresolved nodes. A withheld node
is intentionally omitted but acknowledged. An unresolved node is one
that the validator could not obtain in the current verification
context.
The distinction between withheld and unresolved is communicated to
the validator out-of-band: it is the responsibility of the party
providing the chain (the chain-bundle producer, the API endpoint, the
audit-export tool, or equivalent) to declare which nodeIds are
withheld. ATP Core does not define a normative protocol for this
declaration; in practice, deployments use an explicit withheldNodeIds
list in the chain-exchange envelope (Section 16.12), an out-of-band
agreement between the auditor and the audited party, or a profile-
defined sentinel in node payloads. Validators MUST NOT infer
withheld status from absence alone -- absence is unresolved unless
explicitly declared withheld.
This mode is appropriate for cross-organization audits and
permissioned verification contexts where not all parties have access
to all nodes.
13.5. Minimum Support and Validation Results
Implementations MUST support tip validation at minimum.
Bates Expires 11 November 2026 [Page 21]
Internet-Draft ATP May 2026
Implementations that claim support for full lineage verification
(i.e., the full recursive validation mode defined in Section 13.1)
MUST implement that mode and MUST report results in the format
defined in Section 13.6.
Bounded validation and redacted-lineage validation are OPTIONAL.
When implemented, they MUST clearly report validation depth, out-of-
horizon nodes, unresolved nodes, and withheld nodes as applicable.
A validation result MUST include, at minimum:
* the validation mode used;
* the set of verified nodes;
* the set of invalid nodes, if any;
* the set of unresolved nodes, if any;
* the set of withheld nodes, if any;
* the set of out-of-horizon nodes, if any;
* the set of key-unresolved nodes, if any; and
* the set of profile-unresolved nodes, if any.
No validation mode may silently suppress unresolved, withheld,
invalid, out-of-horizon, key-unresolved, or profile-unresolved
lineage gaps.
13.6. Validation Result Format
Validation results MUST be expressed as a JSON object with the
following top-level keys:
{
"mode": "full",
"boundary": {},
"verified": [],
"invalid": [],
"unresolved": [],
"withheld": [],
"outOfHorizon": [],
"keyUnresolved": [],
"profileUnresolved": [],
"relayFidelity": {}
}
Bates Expires 11 November 2026 [Page 22]
Internet-Draft ATP May 2026
The fields are defined as follows:
* *mode* (string): The validation mode used for this result. MUST
be one of "full", "bounded", "tip", or "redacted", corresponding
to the validation modes defined in Sections 13.1 through 13.4.
* *boundary* (object, OPTIONAL): When mode is "bounded", the
declared verification boundary that was applied (Section 13.2).
REQUIRED when mode is "bounded" and SHOULD be omitted otherwise.
The object MUST contain at least one of: "depth" (integer -- the
parent-generation depth checked) or "sinceTimestamp" (RFC 3339
string -- the time horizon checked). Implementations MAY include
additional implementation-specific boundary descriptors. The
boundary object makes bounded-validation results self-describing
so that operators and downstream auditors know exactly what was
verified.
* *verified* (array of strings): The nodeId hex strings of all nodes
that passed the validation checks applicable to the selected
validation mode (Sections 13.1 through 13.4). Tip validation
establishes node-level integrity only; full recursive validation
establishes full lineage validity (see Section 10.4).
Implementations MUST NOT represent verified entries from non-full
modes as full lineage validation.
* *invalid* (array of strings): The nodeId hex strings of nodes that
failed ATP validation. Causes include, but are not limited to,
canonicalization failure, nodeId mismatch, signature failure,
acyclicity violation, and strict-mode profile-resolution failure
as defined in Section 20.4. Profiles MAY define additional
invalidity causes; such causes MUST be enumerated in the profile
specification.
* *unresolved* (array of strings): The nodeId hex strings of parent
nodes that could not be obtained in the current verification
context.
* *withheld* (array of strings): The nodeId hex strings of nodes
that were intentionally omitted but acknowledged in a redacted-
lineage context (Section 13.4).
* *outOfHorizon* (array of strings): The nodeId hex strings of nodes
lying outside the declared validation boundary in bounded
validation (Section 13.2).
Bates Expires 11 November 2026 [Page 23]
Internet-Draft ATP May 2026
* *keyUnresolved* (array of strings): The nodeId hex strings of
nodes whose issuer public key could not be retrieved for the
(issuerId, keyId) pair, preventing signature verification
(Section 10.4).
* *profileUnresolved* (array of strings): The nodeId hex strings of
nodes whose profile value was not recognized by the validator (per
Section 20.4). In permissive mode, a profile-unresolved node MAY
still pass ATP Core validation and appear in verified; in strict
mode it is also reported in invalid. Profile-unresolved nodes are
always reported in this category so that operators can detect
interoperability gaps.
* *relayFidelity* (object, OPTIONAL): An object keyed by nodeId hex
string, with values indicating the relay fidelity state of relay
nodes as defined in Section 14.2. Permitted values are
"Verified", "Asserted", and "Contradicted".
Absent categories MUST be represented as empty arrays, not omitted.
The relayFidelity object MAY be omitted when no relay nodes are
present in the validated set. The boundary object MUST be present
when mode is "bounded" and SHOULD be omitted in other modes.
Profiles MAY extend this structure with additional keys.
13.7. ATP Core Conformance
An implementation is *ATP Core conformant* if it satisfies all of the
following requirements:
* canonicalizes nodes according to RFC 8785 JCS as required by
Section 9;
* computes nodeId per Section 10.1, including all required fields
and any profile field when present;
* generates and verifies Ed25519 signatures per Section 10.2 and
Section 10.3;
* enforces acyclicity per Section 7;
* implements at least tip validation (Section 13.3);
* produces validation results in the format defined by Section 13.6,
including all required result categories;
* distinguishes invalid, unresolved, withheld, out-of-horizon, key-
unresolved, and profile-unresolved nodes per Section 13.5;
Bates Expires 11 November 2026 [Page 24]
Internet-Draft ATP May 2026
* treats the atp: action-type prefix as reserved per Section 17.1;
* passes all golden test vectors published in [ATP-TEST-VECTORS] for
canonicalization, nodeId computation, and Ed25519 signature
verification.
ATP Core conformance is the floor required for any ATP
implementation.
*Profile conformance is always additive.* An implementation that is
ATP Core conformant MAY additionally claim conformance with one or
more profiles registered per Section 17.2. Profile conformance
requires both ATP Core conformance and satisfaction of all rules
declared by the relevant profile. A profile MUST NOT weaken any ATP
Core conformance requirement (Section 7, Section 10).
Composite conformance labels (such as ATP-MCP-L1, ATP-MCP-L2, and
ATP-MCP-L3) are not defined by ATP Core. Such labels are defined by
individual profile specifications.
14. Security Considerations
ATP signatures prove that an issuer made a claim about a node. They
do not, by themselves, prove that every claim carried in the node is
true in the external world.
14.1. Relay Node Trust Semantics
A *relay node* is a node whose action semantics assert that input was
forwarded without modification. Relay nodes deserve a dedicated
treatment because they have a unique trust property: the relay
issuer's signature proves that the issuer _made the non-modification
claim_, but it does not prove the claim is true. Other ATP action
types (atp:request, atp:completion, atp:failure, atp:decision) carry
claims that are intrinsic to the issuer's own activity (the issuer
asked, completed, failed, or decided). Relay nodes are the only ATP-
Core action type whose claim is _about another party's data_, which
is why their fidelity must be evaluated separately. ATP defines
atp:relay (Section 17.1) as the canonical core action type for relay
nodes. A common indicator within atp:relay nodes is inputHash equals
outputHash. Profiles MAY define additional relay action types,
provided their semantics are explicitly declared per Section 20.3.
Bates Expires 11 November 2026 [Page 25]
Internet-Draft ATP May 2026
Profiles that define relay-like action types MUST state how relay
fidelity is evaluated for those types. Permitted evaluation methods
include: payload hash equality (e.g., inputHash equals outputHash),
direct-origin signature validation, dual-parent lineage (per the
mitigations in this section), or profile-specific rules. Profile-
defined relay types whose fidelity evaluation is not declared MUST be
treated by validators as equivalent to atp:relay.
A node whose action semantics imply relay, forwarding, or pass-
through behavior MUST be understood as an issuer assertion of
fidelity. The signature binds the relay issuer to that claim, but
does not independently prove payload integrity across the relay
boundary.
Validators MUST NOT treat a relay node's signature as proof that the
referenced payload was unmodified. The signature proves only that
the relay issuer made a non-modification claim.
When a downstream node is itself signed by a separate issuer,
validators SHOULD verify the downstream node's signature directly
rather than relying solely on the relay node's fidelity claim.
When the originating node that a relay claims to forward is reachable
via parent references or other available lineage context, validators
SHOULD verify the originating node's signature directly. This is the
strongest fidelity check available within ATP.
When the originating node is unreachable, including because it is
cross-scope, access-restricted, unresolved, or withheld, validators
SHOULD report relay fidelity as asserted rather than verified.
Implementations that require strong relay fidelity guarantees SHOULD
adopt one or more of the following mitigations:
* *Direct parent resolution:* The consuming node references the
originating node (skipping the relay) so that validators can
verify the original signature directly.
* *Dual-parent pattern:* The consuming node references both the
relay node and the originating node, preserving both the chain-of-
custody path and a direct verification path.
* *Out-of-band payload verification:* The validator independently
retrieves the payload identified by the relevant hash and
recomputes integrity outside the ATP graph.
Bates Expires 11 November 2026 [Page 26]
Internet-Draft ATP May 2026
Relay nodes remain valid and useful ATP nodes. They record that a
boundary was crossed, who claims to have crossed it, and what
fidelity assertion was made. ATP treats relay nodes as
accountability artifacts, not as automatic proof of non-modification.
If a relay issuer's fidelity assertion is later shown to be false,
the signed relay node remains evidence that the issuer made that
assertion.
14.2. Relay Fidelity Validation States
For relay-node fidelity, validation results SHOULD distinguish at
least the following states:
* *Verified:* The originating node is resolved, signatures validate,
and the relay claim is consistent with the originating material.
* *Asserted:* The relay node is validly signed but the originating
node was not independently verified.
* *Contradicted:* The originating node is resolved and the relay
claim does not match the originating material.
These states are specific to relay fidelity semantics and do not
replace the broader ATP validation result categories defined in
Section 13.5.
14.3. Timestamp Trust
The timestamp field is a claimed value set by the node emitter. ATP
does not define a trusted time source or require synchronized clocks.
Validators SHOULD treat timestamps as issuer assertions subject to
the same trust considerations as other node content.
14.4. Signature Scope
An ATP signature covers the nodeId, which is derived from the
canonical node content. The signature does not cover the referenced
payloads themselves -- only their hashes. Payload integrity depends
on the hash algorithm and the availability of the original payload
for recomputation.
14.5. Trust Model Summary
ATP's security guarantees rest on three trust assumptions. These
assumptions are stated individually elsewhere in this document and
are collected here for the benefit of implementers and reviewers.
Bates Expires 11 November 2026 [Page 27]
Internet-Draft ATP May 2026
* *Issuer key availability.* Verifiers are assumed to be able to
retrieve issuer public keys for any (issuerId, keyId) pair that
appears in the chain. Key discovery is intentionally deferred to
deployments and future specifications (Section 16.1). When a key
is unavailable, the affected node is keyUnresolved rather than
invalid (Section 10.4).
* *Node availability.* Full lineage verification requires that all
referenced parent nodes be retrievable in the verifier's
verification context. ATP does not define a federation or cross-
scope retrieval protocol (Section 16.3). Where parent nodes are
unavailable, the affected nodes are unresolved and lineage
validity is not established (Section 10.4, Section 13.5).
* *Issuer honesty (within signature scope).* ATP signatures prove
that an issuer made a claim about a node. They do not prove that
the claim is true in the external world. Timestamps
(Section 14.3), action types, and payload references are all
issuer assertions subject to operational trust in the issuer.
These assumptions are deliberate scope choices, not omissions. ATP
composes with identity, authorization, transparency, and federation
mechanisms that strengthen each assumption (Section 14.6,
Section C.6) without expanding ATP Core.
14.6. Suppression and Anti-Suppression
ATP detects modification but not suppression. A malicious operator
who controls a node store MAY withhold individual nodes from a
verifier. A verifier observing unresolved parents cannot, on the
basis of ATP alone, distinguish between (a) nodes that exist
elsewhere but are unreachable in the current verification context,
(b) nodes that have been deliberately suppressed, and (c) nodes that
were never written.
ATP Core does not provide an anti-suppression mechanism. This is a
deliberate scope choice, not an oversight.
Deployments that require operator-independent assurance against
suppression SHOULD layer ATP with an append-only transparency service
such as a SCITT-compatible service [SCITT]. In such a composition:
* ATP nodes (or their nodeId values) are published to the
transparency service as signed statements;
* the transparency service provides operator-independent evidence
that the node existed at a given time and was not retroactively
suppressed;
Bates Expires 11 November 2026 [Page 28]
Internet-Draft ATP May 2026
* ATP retains its causal-DAG and lineage-validity semantics over the
underlying chain.
Profiles MAY define normative SCITT-compatible or equivalent
publication patterns. ATP Core does not require such layering, but
the protocol is designed to compose with it (see Section C.6 for
further discussion of the SCITT relationship).
14.7. Replay and Scope Binding
Because scope participates in canonicalization (Section 9,
Section 12), a node's nodeId is bound to its declared scope. A
literal replay of a signed node into a different scope produces a
different recomputed nodeId; the original signature does not validate
against that different nodeId. Replay across scopes is therefore
not, by itself, a node-integrity attack.
However, a malicious party who obtains a signed node MAY present that
node in a different verification context where its declared scope
value happens to be permitted or expected. Validators MUST evaluate
scope semantics within their verification context and MUST NOT accept
a node as evidence of an action in a verification context whose scope
semantics do not match the scope value declared by the node.
ATP Core does not define an anti-replay mechanism beyond scope
binding. Deployments requiring stronger anti-replay protection (for
example, freshness guarantees against same-scope replays after a long
interval) SHOULD layer additional context-binding outside the
protocol -- for example, transport-layer freshness tokens, audited
delivery channels, or profile-defined nonce fields participating in
canonicalization per Section 20.4.
15. Privacy Considerations
ATP nodes carry metadata about actions, identities, and causal
relationships. Even when payload content is stored externally and
referenced only by hash, the existence of a node in an ATP chain
reveals that an action was taken, by which agent, on behalf of which
actor (when present), and in what causal relationship to other
actions.
15.1. Data Minimization
ATP's design supports data minimization by carrying hashes rather
than full payloads. However, the metadata fields themselves --
including actorId, agentId, issuerId, and action.type -- may
constitute personal data or sensitive operational data depending on
the deployment context and applicable jurisdiction.
Bates Expires 11 November 2026 [Page 29]
Internet-Draft ATP May 2026
Implementations SHOULD evaluate whether node metadata requires
protection under applicable privacy regulations and SHOULD apply
access controls to ATP node storage and retrieval accordingly.
15.2. Deletion and Retention Tension
ATP's tamper-evident properties create a tension with data subject
rights such as the right to erasure under GDPR and similar
regulations.
Payloads referenced by inputHash and outputHash are stored outside
the ATP chain and MAY be deleted independently without invalidating
the chain's structural integrity. The hash references will remain,
but the referenced content will no longer be retrievable.
Node metadata within the chain -- including actorId, agentId,
timestamps, and causal relationships -- cannot be removed without
invalidating the node's signature and the nodeId references of all
descendant nodes.
Implementations that must accommodate deletion rights SHOULD consider
the following approaches:
* Store personal data exclusively in external payloads referenced by
hash, not in node metadata fields.
* Use pseudonymous or indirect identifiers in actorId that can be
dereferenced through a separate, deletable mapping.
* Apply redacted-lineage validation (Section 13.4) so that nodes
containing personal data can be withheld from verification
contexts when required.
ATP does not define a normative deletion or redaction mechanism. The
tension between immutable audit evidence and deletion rights is an
operational and legal concern that deployments must address in the
context of their applicable regulatory requirements.
15.3. Chain Existence as Metadata
Even when all payload content and personal identifiers are removed or
pseudonymized, the existence of an ATP chain itself -- including its
structure, depth, timing, and issuer distribution -- may reveal
operationally sensitive information. Implementations SHOULD apply
appropriate access controls to chain metadata, not only to payload
content.
Bates Expires 11 November 2026 [Page 30]
Internet-Draft ATP May 2026
15.4. Pseudonymous Identifiers and Post-Deletion Verification
Implementations SHOULD use pseudonymous or indirect identifiers in
actorId rather than directly identifying personal data. A separate
identity-resolution service SHOULD manage the mapping between
pseudonymous identifiers and real identities.
When a data subject exercises a right to erasure, the RECOMMENDED
approach is to delete the identity-resolution mapping and any
external payloads containing personal data. The ATP chain itself is
not modified.
After identity-resolution deletion, the actorId value remains in the
chain but can no longer be resolved to a natural person. The chain's
structural integrity, signatures, and causal relationships are
unaffected.
Implementations MUST NOT rely on actorId opacity alone as a privacy
control. If the actorId value itself is directly identifying -- for
example an email address or employee number -- deletion of the
mapping service does not remove the personal data from the chain.
Pseudonymous identifiers are therefore RECOMMENDED as the default.
Following deletion of identity mappings or external payloads,
validators SHOULD use redacted-lineage validation as described in
Section 13.4 when verifying historical chains that include now-
unresolvable or now-withheld elements.
Deployments subject to data protection regulations SHOULD document
their ATP data retention and deletion procedures as part of their
privacy impact assessment.
16. Operational Considerations
16.1. Key Lifecycle
ATP does not define a key management protocol, key discovery
mechanism, or trust registry. However, ATP deployments depend on
durable issuer key practices in order for signed nodes to remain
verifiable over time.
Each issuer controls its own key material. No issuer is expected to
hold another issuer's private key. Private key storage is
implementation-specific and MAY use HSMs, cloud KMS systems, local
keystores, or other suitable mechanisms. The operational requirement
is that the private key associated with a given issuer.keyId can
generate ATP-conformant Ed25519 signatures, and that validators can
obtain the corresponding public key for verification.
Bates Expires 11 November 2026 [Page 31]
Internet-Draft ATP May 2026
An issuer MAY rotate signing keys at any time by beginning to sign
new nodes with a new keyId.
Previously signed nodes remain valid after rotation. A node
continues to identify the key that was active when it was signed
through its issuer.keyId value.
An issuer MUST maintain the ability to provide the public key for any
keyId that appears in its signed nodes for as long as those nodes may
need to be verified.
ATP Core does not define a public key discovery mechanism or a
normative well-known URI path for key publication. Implementations
MAY use well-known URIs, JWK sets, append-only key logs, out-of-band
registries, or other equivalent mechanisms that allow a validator to
retrieve the public key for a given (issuerId, keyId) pair. A future
ATP specification or profile MAY define a normative key-discovery
path; this document does not.
This deferral creates a practical interoperability consequence: until
a normative key-discovery path exists, two implementations that wish
to cross-verify each other's chains MUST agree on a key-retrieval
mechanism out-of-band. Cross-organization verification is therefore
fragmented at the discovery layer even though node integrity,
identity computation, and signature verification are deterministic.
Profiles requiring open cross-organization verifiability SHOULD
define a key-publication mechanism (for example, a JWK set served at
a profile-specified well-known URI) and SHOULD declare it as a
profile conformance requirement.
Key retirement does not invalidate previously signed nodes. The
nodeId and signature remain correct; only the deployment's ability to
verify those nodes depends on continued public key availability.
Implementations SHOULD plan for indefinite retention of public keys
for any keyId that has been used in production signing.
Deployments are RECOMMENDED to publish or otherwise maintain an
append-only public key record per issuer so that historical keyIds
remain resolvable even after active signing use has ended.
16.2. Request/Completion Pairing
ATP does not require a single emission timing model for all action
types. However, when implementations require auditable evidence of
attempted, in-progress, completed, or failed actions, a paired
request/completion pattern is RECOMMENDED.
Bates Expires 11 November 2026 [Page 32]
Internet-Draft ATP May 2026
In this pattern, a *request node* (typically atp:request, see
Section 17.1) records intent. The request node carries inputHash
covering the request payload. outputHash is omitted (not zeroed or
set to a placeholder -- absent). Per Section 9, null-valued fields
are omitted during canonicalization, so this is consistent with
deterministic identity computation.
A *completion node* (typically atp:completion, see Section 17.1)
records outcome. The completion node references the request node as
a parent. The completion node SHOULD carry an inputHash matching the
request node's inputHash so that validators can determine that both
nodes describe the same logical action. The completion node carries
outputHash covering the response or result payload.
A *failure* is also represented as a completion node, typically using
atp:failure (Section 17.1). The relevant action.type SHOULD indicate
failure semantics, and outputHash SHOULD cover any resulting error
payload.
ATP does not mandate that profiles use the core atp:request,
atp:completion, and atp:failure types directly. Profiles MAY define
more specific action types that follow the same emission semantics,
provided the profile specification declares the mapping (per
Section 20.3).
If an emitter crashes or otherwise fails between request-node
emission and completion-node emission, the unpaired request node
remains a valid ATP node. Validators and operational tooling SHOULD
report unpaired request nodes as open or incomplete rather than
invalid. This behavior is intentional and provides crash-recovery
and interrupted-action visibility.
16.3. Cross-Scope Resolution
Cross-scope parent verification is an operational capability, not a
separate ATP protocol. Implementations that expect validators to
verify nodes across scope boundaries SHOULD ensure that validators
can retrieve referenced nodes across those boundaries.
This MAY be achieved through a shared node store, an API-based
retrieval mechanism, or another exchange mechanism. ATP does not
define a federation protocol or a required topology for cross-scope
node access.
Bates Expires 11 November 2026 [Page 33]
Internet-Draft ATP May 2026
16.4. Actor Mapping Guidance
In governed deployments, actor omission SHOULD be uncommon. Most ATP
nodes ought to identify the principal whose authority the agent is
acting under.
actor represents the delegating principal. That principal MAY be
human or non-human.
When a human initiates an action, actorId SHOULD identify the human
principal and authContext SHOULD identify the authentication
mechanism, such as SAML or OIDC.
When a machine-originated chain has no human initiator, actorId
SHOULD identify the accountable service principal -- the service
account, scheduled-job identity, CI/CD pipeline identity, managed
identity, or equivalent non-human principal. authContext SHOULD
identify the credential or trust mechanism used, such as workload
identity, managed identity, service account, or API key.
When there is genuinely no delegating principal and the agent is
acting autonomously, actor MAY be omitted. Such omission is a
meaningful signal: it indicates the action was not taken on behalf of
an accountable principal. Implementations SHOULD treat frequent
actor omission as a governance concern rather than as routine
behavior. See Section 8 for the corresponding verifier rule on
omission.
16.5. Agent Versioning Guidance
ATP does not mandate a versioning scheme for agent.version.
Implementations MAY use semantic versions, date-based versions,
commit hashes, or other distinguishable version identifiers.
However, agent.version SHOULD change whenever the agent's decision-
producing configuration changes. The governing test is
*configurational*, not run-time behavioral: if the _configuration_
that produces outputs changes such that the agent could produce a
different output for the same input, the version SHOULD change. Run-
time output variance that is intrinsic to the agent's design -- for
example, a sampling LLM with no fixed seed producing different
completions for identical prompts -- does NOT require a version bump
on every emission. The version tracks the agent the way a software
version tracks a binary: it changes when the binary changes, not when
the binary processes different inputs.
Changes that SHOULD trigger a new agent.version include, but are not
limited to:
Bates Expires 11 November 2026 [Page 34]
Internet-Draft ATP May 2026
* a software code change that alters decision logic (a refactor, a
routing-rule change, a control-flow modification);
* a model swap (for AI agents);
* a prompt, template, or few-shot example change (for AI agents);
* a tool-scope change that affects what tools the agent can select
or invoke;
* a policy-bundle, guardrail, or business-rule change that affects
output behavior; and
* a configuration change that affects output behavior, such as
sampling parameters, retrieval settings, scoring weights, or
generation parameters.
Changes that ordinarily SHOULD NOT trigger a new agent.version
include infrastructure-only changes that do not affect decision
behavior, such as scaling changes, region failover, key rotation,
logging changes, observability changes, or transport/protocol
upgrades that do not alter the agent's decision logic. Run-time non-
determinism (sampling, random-seed-based variation, time-of-day-
dependent behavior) likewise does NOT trigger a version bump unless
the _configuration_ of that non-determinism changes.
ATP cannot enforce correct version bumps at the protocol level. If
an implementation changes agent behavior without changing
agent.version, that is an implementation governance failure rather
than a protocol ambiguity.
16.6. Issuer Identity Granularity
ATP does not prescribe a required granularity for issuerId. issuerId
identifies a signing-authority boundary: the entity that controls the
private key material and is accountable for the nodes it signs. That
boundary MAY align with a tenant, a deployment, a region, a service,
or another organizational unit.
The governing principle is key custody. Nodes signed under the same
issuerId share the same key-custody boundary. If two systems have
independent key custody -- for example, different key storage,
different rotation policies, or different operational teams -- they
SHOULD use different issuerId values.
Conversely, systems that share key custody MAY share an issuerId.
Bates Expires 11 November 2026 [Page 35]
Internet-Draft ATP May 2026
Implementations SHOULD choose issuerId granularity such that
compromise of one issuer's key material does not implicate nodes
signed by a different issuer. This is the primary security
constraint on issuerId design.
The combination of issuerId and keyId MUST be unique within the
relevant verification context. Two different issuers MUST NOT share
a keyId value that maps to different keys within that context.
ATP does not mandate whether issuerId maps to tenants, deployments,
services, or regions. This is an operational design decision. An
enterprise with centralized key custody MAY use one issuerId across
multiple agents or services. A deployment with per-tenant or per-
environment key isolation SHOULD use distinct issuerId values that
reflect those custody boundaries.
16.7. Storage Model Guidance
ATP does not mandate a storage substrate. Implementations MAY use
append-only logs, content-addressed object stores, relational
databases, or other storage systems.
In practice, three storage patterns are common:
*Pattern A -- Append-only event log.* Nodes are written sequentially
to a log. Parent resolution is performed by index lookup or by a
secondary index on nodeId. This pattern integrates naturally with
event-sourced architectures and operational monitoring systems, but
parent resolution across large graphs depends on effective indexing.
*Pattern B -- Content-addressed object store.* Nodes are stored keyed
by nodeId. Because nodeId is derived from canonical node content,
this pattern aligns closely with ATP's deterministic identity model
and supports direct parent lookup by nodeId. However, temporal
ordering and operational queryability may require additional
indexing.
*Pattern C -- Hybrid.* Nodes are written to an append-only log for
temporal ordering and operational queries, and are also indexed or
stored by nodeId for efficient parent resolution. This pattern
supports both operational visibility and efficient heritage traversal
at the cost of greater implementation complexity.
Regardless of storage choice, implementations MUST ensure that a node
can be retrieved by nodeId with sufficient performance to support the
validation modes the deployment intends to offer.
Bates Expires 11 November 2026 [Page 36]
Internet-Draft ATP May 2026
Implementations that support full recursive validation (Section 13.1)
SHOULD ensure that parent resolution by nodeId remains efficient at
scale, since recursive validation traverses the full heritage graph.
Implementations MUST ensure that stored nodes are immutable once
written. Mutation of a stored node invalidates its nodeId, breaks
downstream parent references, and defeats ATP's tamper-evidence
guarantees for any verifier that does not retain the original bytes.
Implementations MAY enforce immutability through storage-engine
constraints -- for example, write-once tables, content-addressed
object stores, append-only logs, or BEFORE UPDATE triggers that
reject row modifications.
Storage-layer integrity checks, such as recomputing nodeId from
stored content as an operational health measure, are RECOMMENDED.
However, such checks are not a substitute for ATP validation.
16.8. Permissioned Verifiability
ATP does not define an access-control model for node retrieval.
Access control over who may retrieve and verify which nodes is an
implementation and deployment concern.
In practice, ATP deployments often serve multiple verification
audiences with different access rights.
*Tier 1 -- Full-chain verification.* A verifier with unrestricted
access to all relevant nodes and scopes can perform full recursive
validation as defined in Section 13.1.
*Tier 2 -- Scoped verification.* A verifier with access limited to
particular scopes, issuers, time ranges, or other node attributes
validates the nodes available in that verification context. Parents
outside that boundary are reported as unresolved or out-of-horizon
according to the applicable validation mode.
*Tier 3 -- Redacted verification.* A verifier is given a partial
chain in which sensitive nodes are withheld and represented only by
nodeId or by withheld-node placeholders consistent with Section 13.4.
The verifier can validate visible nodes, confirm visible chain
structure, and transparently report withheld nodes.
Implementations that serve multiple verification audiences SHOULD
provide mechanisms to scope node access by verification context --
for example, by scope, by issuer, by time range, or by other node
attributes.
Bates Expires 11 November 2026 [Page 37]
Internet-Draft ATP May 2026
When a verification context restricts the nodes available to a
verifier, the verifier MUST use the appropriate validation mode and
MUST report any nodes that are unresolved, withheld, or out-of-
horizon in the validation result.
Implementations MAY offer a *hash-only verification path* in which a
verifier is given only nodeId values and parent references without
full node content. This allows the verifier to confirm chain
structure and determine whether one node descends from another
without access to the metadata of intermediate nodes.
ATP does not define a protocol for permissioned export, redacted-
chain generation, or verifier authorization. Those mechanisms remain
implementation-specific.
16.9. Deletion and Redaction Operations
ATP does not define a deletion protocol, a redaction protocol, or an
identity-resolution service. Those mechanisms remain implementation-
specific.
In practice, deployments can reduce privacy tension through three
operational layers:
*Layer 1 -- Keep personal data out of node metadata.* Deployments
SHOULD prefer pseudonymous identifiers in actorId and SHOULD avoid
embedding directly identifying personal data in actorId, agentId,
issuerId, or action.type.
*Layer 2 -- Delete external payloads freely.* Payloads referenced by
inputHash and outputHash may be deleted independently of the ATP
chain without breaking ATP structural integrity.
*Layer 3 -- Verify post-deletion chains using the appropriate
validation mode.* After identity-resolution deletion or payload
deletion, validators SHOULD use redacted-lineage validation or
another appropriate restricted verification mode so that withheld or
now-unresolvable content is reported transparently rather than
treated as invalid.
These operational practices do not eliminate the legal or governance
tension between immutable evidence and deletion rights, but they make
privacy-preserving ATP deployments practical without modifying the
core protocol.
Bates Expires 11 November 2026 [Page 38]
Internet-Draft ATP May 2026
16.10. Performance Budget Guidance
ATP does not define benchmark requirements. Performance depends on
implementation language, hardware, storage design, graph shape, and
validation mode. However, deployments SHOULD understand four
distinct ATP cost centers.
*Cost 1 -- Canonicalization.* Canonicalization cost scales primarily
with node count rather than with node complexity because ATP nodes
are structurally small and regular. For most deployments,
canonicalization is not the dominant validation cost.
*Cost 2 -- Signing and signature verification.* Ed25519 signing and
verification are computationally lightweight for individual nodes.
In bulk validation scenarios, signature verification cost becomes
measurable but remains parallelizable because each node's signature
is independent.
*Cost 3 -- Parent resolution.* The dominant performance cost in ATP
validation is usually parent resolution: retrieving referenced nodes
by nodeId. Implementations SHOULD optimize node retrieval by nodeId
as a primary access pattern.
*Cost 4 -- Lineage traversal.* Full recursive validation traverses
the entire heritage graph and therefore scales linearly with the
number of reachable nodes in that heritage. Bounded validation caps
traversal according to the declared horizon. Tip validation avoids
heritage traversal entirely.
Implementations that support full recursive validation (Section 13.1)
SHOULD ensure that parent resolution by nodeId remains efficient at
scale, since recursive validation traverses the full heritage graph.
Implementations that serve latency-sensitive validation requests
SHOULD consider bounded validation (Section 13.2) or tip validation
(Section 13.3) for operational use cases, reserving full recursive
validation for audit and forensic contexts.
Implementations SHOULD monitor and report heritage depth and
branching factor for production scopes. Unusually deep or wide
graphs may indicate emitting-system design issues, excessive
delegation, or insufficient scope partitioning.
Caching of previously validated subtrees is permitted and RECOMMENDED
for deployments that perform repeated validation of overlapping
heritage. Cached validation results MUST be invalidated if the
validator's trust in any issuer key changes, for example because of
key compromise, key replacement, or revocation-related policy change.
Bates Expires 11 November 2026 [Page 39]
Internet-Draft ATP May 2026
16.11. Node Granularity Guidance
ATP Core does not normatively prescribe what events MUST or MUST NOT
produce ATP nodes -- that is profile responsibility (Section 20.3).
However, deployments and profile authors benefit from a shared
default. The governing principle is: *an ATP node represents an
action that warrants independent audit*, not every internal
computation step.
The following non-normative heuristics describe the typical default:
*Node-worthy events* (typically emitted as ATP nodes):
* External tool invocations and their completions (cross-process,
cross-service, or cross-organization calls).
* Cross-agent dispatches (one agent handing work to another).
* Cross-issuer payload forwarding events (relay nodes).
* Decisions that materially affect downstream outcomes (tool
selection, routing decisions, synthesis from multiple inputs).
* Workflow or transaction boundaries (root nodes for new
transactions; completion nodes for terminating transactions).
*Not node-worthy events* (typically NOT emitted as ATP nodes):
* Internal control flow within a single agent's reasoning (if/else
branches, loops, exception handlers).
* Lookups of environment variables, configuration values, or static
reference data.
* Per-token model output during generation (token-streaming chunks).
* Pre-emission canonicalization, signing, or storage operations of
the ATP layer itself.
* Health-check pings, heartbeats, or other liveness traffic.
Bates Expires 11 November 2026 [Page 40]
Internet-Draft ATP May 2026
The boundary between node-worthy and not-node-worthy is *whether the
event crosses a trust boundary or affects auditability*. An internal
if statement in an agent's code is not node-worthy; a decision that
selects between two external tools, paid services, or downstream
agents is. A configuration lookup is not node-worthy; a
configuration _change_ that could alter the agent's behavior is
reflected in agent.version (Section 16.5), not in a separate
emission.
Profiles MAY normatively constrain these defaults. For example, a
high-assurance profile MAY require explicit decisional nodes for any
output that affects regulatory reporting; a low-assurance profile MAY
suppress decisional nodes entirely and emit only request/completion
pairs. Profiles SHOULD justify their granularity rules with
reference to the audit posture they target.
16.12. Chain Exchange Patterns
ATP does not define a transport protocol for chain exchange.
However, deployments that share chains across organizational or
system boundaries benefit from common patterns.
Three patterns are common:
*Pattern X -- Bundle export.* The producer assembles a JSON envelope
containing an array of signed nodes plus a list of withheldNodeIds
(where applicable) and provides it to the consumer as a single
artifact. A typical bundle structure:
{
"atpVersion": "11",
"nodes": [ /* array of signed ATP nodes */ ],
"withheldNodeIds": [ /* array of nodeId hex strings -- see Section 13.4 */ ],
"scopes": [ /* OPTIONAL -- array of scope values represented in this bundle */ ]
}
The consumer iterates nodes, validates each per the appropriate
validation mode (Section 13), and treats any parent reference that
resolves only to a withheldNodeIds entry as withheld rather than
unresolved.
*Pattern Y -- Pull by nodeId.* The producer exposes a content-
addressed retrieval API (GET /atp/nodes/{nodeId}) returning the
signed node by its identifier. The consumer walks parent references,
resolving each via the API. This pattern is appropriate when the
consumer's traversal pattern is unpredictable or when chains are very
large.
Bates Expires 11 November 2026 [Page 41]
Internet-Draft ATP May 2026
*Pattern Z -- Push to log.* Each issuer emits signed nodes to a
shared append-only log (a transparency service per Section C.6, an
event bus, or a centralized audit store). Consumers subscribe or
query the log. This pattern is appropriate when multiple consumers
need access to the same chains or when anti-suppression guarantees
(Section 14.6) are required.
Bundle exports SHOULD include enough context for the consumer to
perform the validation mode they require: a bundle intended for full-
recursive validation MUST include all heritage; a bundle intended for
tip validation MAY include only the tip nodes. ATP Core does not
define a normative bundle schema; profiles MAY do so.
17. IANA Considerations
This document requests the following IANA actions.
17.1. ATP Action Types Registry
IANA is requested to create a new registry titled "ATP Action Types"
under a new "Agent Transaction Protocol (ATP)" registry group. The
registration policy for this registry is Specification Required
[RFC8126].
Each entry in the registry MUST include the following fields:
* *Type Value:* The action type string.
* *Description:* A short description of the action type's semantics.
* *Reference:* A pointer to the specification that defines the type.
* *Status:* One of active, deprecated, or obsolete. active indicates
the type is currently recommended; deprecated indicates the type
SHOULD NOT be used in new emissions; obsolete indicates the type
is retained for historical lookup only and MUST NOT be used in new
emissions.
The atp: prefix is reserved for this registry. Action types defined
by ATP profiles MAY register under the atp: prefix following the
Specification Required policy above. Action types that are not
registered MUST NOT use the atp: prefix.
The following initial values are registered by this document, all
with Status active:
Bates Expires 11 November 2026 [Page 42]
Internet-Draft ATP May 2026
+================+========================+================+========+
| Type Value | Description | Reference | Status |
+================+========================+================+========+
| atp:request | Represents the | This document, | active |
| | initiation of an | Section 16.2 | |
| | action, recording | | |
| | intent and input | | |
| | material. outputHash | | |
| | is typically absent. | | |
+----------------+------------------------+----------------+--------+
| atp:completion | Represents the | This document, | active |
| | successful completion | Section 16.2 | |
| | of an action | | |
| | initiated by a | | |
| | corresponding request | | |
| | node. outputHash | | |
| | covers the result | | |
| | payload. | | |
+----------------+------------------------+----------------+--------+
| atp:failure | Represents the | This document, | active |
| | failure outcome of an | Section 16.2 | |
| | action initiated by a | | |
| | corresponding request | | |
| | node. outputHash | | |
| | SHOULD cover any | | |
| | error payload. | | |
+----------------+------------------------+----------------+--------+
| atp:relay | Represents a | This document, | active |
| | boundary-crossing | Section 14.1 | |
| | relay event in which | | |
| | the emitting issuer | | |
| | asserts that input | | |
| | was forwarded without | | |
| | modification. | | |
| | inputHash SHOULD | | |
| | equal outputHash. | | |
+----------------+------------------------+----------------+--------+
| atp:decision | Represents a | This document, | active |
| | decisional node | Section 8 | |
| | recording a | (decisional | |
| | selection, policy | node | |
| | decision, or | definition) | |
| | synthesis without | and Appendix A | |
| | direct invocation of | (worked | |
| | an external system. | example) | |
+----------------+------------------------+----------------+--------+
Table 1
Bates Expires 11 November 2026 [Page 43]
Internet-Draft ATP May 2026
Future ATP profile documents MAY request additional action type
registrations following the Specification Required registration
policy above. A registered action type MAY be transitioned to
deprecated or obsolete Status by a subsequent specification
registered under the same policy; transitions MUST cite the prior
registration.
The five initial action types are registered in Core because they
represent cross-system patterns whose vocabulary alignment is more
valuable than minimalism. Implementations MAY use only a subset. In
particular, profiles or deployments that have no need for explicit
relay or decisional emission MAY model those concepts using
atp:request + atp:completion pairs and never emit atp:relay or
atp:decision nodes. Conversely, deployments that DO emit relay or
decisional nodes benefit from registered vocabulary so that cross-
system validators can interpret them uniformly. Registration of
these types in Core does not imply any deployment must use them.
17.2. ATP Profiles Registry
IANA is requested to create a new registry titled "ATP Profiles"
under the "Agent Transaction Protocol (ATP)" registry group. The
registration policy for this registry is Specification Required
[RFC8126].
Each entry in the registry MUST include the following fields:
* *Profile Identifier:* The full URN of the form
urn:ietf:params:atp:profile:{name}:{version} (see Section 20.1).
* *Profile Name:* The short profile name component.
* *Version:* The semantic version of the profile (see Section 20.2).
* *Description:* A short description of the profile's scope and
purpose.
* *Reference:* A pointer to the specification that defines the
profile.
* *Status:* One of active, deprecated, or obsolete.
This document does not register any initial profile entries. Initial
profile entries are expected to be registered by separate profile
specifications, including [ATP-PROFILES].
Bates Expires 11 November 2026 [Page 44]
Internet-Draft ATP May 2026
17.3. URN Sub-Namespace Registration
IANA is requested to register the URN sub-namespace atp under
urn:ietf:params per [RFC3553].
* *Registry name:* Agent Transaction Protocol (ATP) Parameters
* *URN format:* urn:ietf:params:atp:{class}:{name}:{version} where
{class} is one of the registered ATP parameter classes (initially
profile), {name} is the parameter name, and {version} is the
parameter version.
* *Registration policy:* Sub-classes within urn:ietf:params:atp: are
added by IETF Consensus or by a registry policy declared in a
subsequent ATP specification.
* *Reference:* This document, Section 17.2 and Section 20.1.
This document does not request the registration of a well-known URI
for ATP key publication. A future ATP specification or profile MAY
define a normative key-discovery path and request the corresponding
well-known URI registration; this document explicitly defers that
work.
18. Implementation Status
This section is to be removed before publication as an RFC, in
accordance with [RFC7942].
At the time of this draft, ATP is at the design and prototype stage.
No production deployments are reported. A zero-dependency Node.js
reference implementation accompanying this draft passes all golden
vectors published in [ATP-TEST-VECTORS] for canonicalization
(Section 9), nodeId computation (Section 10.1), Ed25519 signature
generation and verification (Section 10.2 and Section 10.3), and tip-
validation node-level integrity (Section 10.4 / Section 13.3).
A reference implementation intended to demonstrate interoperability
SHOULD publish golden test vectors covering, at minimum:
* canonicalization per RFC 8785 JCS (Section 9), including the
inclusion of the profile field when present;
* nodeId computation (Section 10.1);
* Ed25519 signature generation and verification (Section 10.2 and
Section 10.3);
Bates Expires 11 November 2026 [Page 45]
Internet-Draft ATP May 2026
* each validation mode defined in Sections 13.1 through 13.4;
* the validation result format (Section 13.6), including
representation of all required result categories;
* profile-field canonicalization behavior under both strict and
permissive validator modes (Section 20.4);
* handling of invalid, unresolved, withheld, out-of-horizon, key-
unresolved, and profile-unresolved parents.
The companion Internet-Draft [ATP-TEST-VECTORS] provides an initial
set of golden vectors aligned with the requirements above.
Implementations claiming ATP Core conformance per Section 13.7 MUST
pass all vectors in [ATP-TEST-VECTORS] for canonicalization, nodeId
computation, and Ed25519 signature verification.
Authors and implementers wishing to report implementation status,
interoperability results, or production usage are invited to contact
the document author identified in the Author's Address section.
19. Profile Framework
An ATP *profile* is a normative specification that extends or
constrains ATP Core for a specific deployment context, domain, or
interoperability scope. Profiles MAY define additional action.type
values, additional node schema fields, more restrictive validation
rules, null-field inclusion rules (per Section 9), relay type
declarations (per Section 14.1), and completion-pairing semantics
(per Section 16.2). Full profile governance, including the
specification template, registration procedures, and composite
conformance labels, is defined by individual profile specifications
and by the companion document [ATP-PROFILES]. This document defines
the ATP Profile Framework: the rules that any profile MUST satisfy in
order to be ATP-conformant.
19.1. Profile Identifiers
A profile is identified by a string value carried in an OPTIONAL
profile field on ATP nodes (see Section 8). When a profile field is
present, validators MUST apply the validation rules of the identified
profile in addition to ATP Core rules. When the profile field is
absent, ATP Core rules apply exclusively.
Profile identifiers MUST follow one of the two formats defined below:
* *Registered profiles* use the prefix urn:ietf:params:atp:profile:
followed by the profile name and version:
Bates Expires 11 November 2026 [Page 46]
Internet-Draft ATP May 2026
urn:ietf:params:atp:profile:{name}:{version}
Example: urn:ietf:params:atp:profile:mcp:1.0
Registered profiles are recorded in the ATP Profiles registry
(Section 17.2) under the URN sub-namespace registered in
Section 17.3.
* *Private or vendor profiles* use the tag URI scheme [RFC4151] with
the profile maintainer's DNS authority:
tag:{authority},{date}:atp-profile/{name}:{version}
Where {authority} is a DNS name under the profile maintainer's
control, {date} is the year (YYYY) or year-month (YYYY-MM) on which
the maintainer became authoritative for that DNS authority, {name} is
the profile name, and {version} is the semantic version per
Section 20.2.
Example: tag:example.com,2026:atp-profile/internal-audit:1.0
Tag URIs are a registered URI scheme defined by [RFC4151] for use
cases where a stable identifier is needed without per-identifier IANA
registration. Private profile identifiers are not recorded in the
ATP Profiles registry (Section 17.2) and are valid within the
operational context of the deploying organization only.
Validators MUST distinguish registered profile identifiers (which are
URNs under urn:ietf:params:atp:profile:) from private profile
identifiers (which are tag URIs under tag:) on the basis of the URI
scheme.
Validators SHOULD reject nodes claiming a registered profile
identifier (using the urn:ietf:params:atp:profile: prefix) that does
not correspond to an entry in the ATP Profiles registry.
Implementations of earlier ATP drafts that emitted private profile
identifiers in the form private:{authority}/{name}:{version} SHOULD
migrate to the tag URI form before claiming -10 conformance.
Validators MAY accept the legacy private: form during a transition
period but MUST report any non-tag-URI private profile identifier
under profileUnresolved in the validation result (Section 13.6) so
that operators can identify migration backlog.
19.2. Profile Versioning
Profiles MUST use semantic versioning (MAJOR.MINOR.PATCH):
Bates Expires 11 November 2026 [Page 47]
Internet-Draft ATP May 2026
* A *MAJOR* version increment is REQUIRED when the profile
introduces breaking changes to canonicalization rules, the node
schema, or validation logic. Nodes produced under MAJOR version N
are not required to be validatable under MAJOR version N+1 without
explicit backward-compatibility provisions.
* A *MINOR* version increment MAY be used for non-breaking
additions, such as new action types or new optional fields.
* A *PATCH* version increment is used for errata, clarifications,
and non-normative changes only.
19.3. Minimum Profile Contract
A conformant ATP profile specification MUST define:
1. The profile identifier, in the format specified in Section 20.1.
2. The action type vocabulary in use, including any relay action
types (per Section 14.1) and their semantics. Profile-defined
action types SHOULD be registered in the ATP Action Types
registry (Section 17.1) when interoperability is required.
3. Any null-field inclusion rules that differ from ATP Core
(Section 9), enumerated explicitly by field name.
4. Any completion-pairing semantics that differ from ATP Core
(Section 16.2), including whether completion nodes may carry a
different inputHash than their paired request node.
5. The minimum conformance level required of validators claiming
compliance with the profile.
6. Any additional schema fields introduced by the profile, with
their normative status (REQUIRED, OPTIONAL, or MUST NOT be
present).
7. Node-worthiness rules identifying which events MUST, SHOULD, MAY,
or MUST NOT produce ATP nodes within the profile's scope. The
profile SHOULD provide examples for at least the most common
emission patterns.
8. Streaming semantics, if the profile supports streaming outputs.
Such profiles MUST define whether stream chunks, stream
completion events, or stream digests are represented as ATP
nodes, and how the resulting nodes relate to one another via
parents.
Bates Expires 11 November 2026 [Page 48]
Internet-Draft ATP May 2026
9. Relay-fidelity evaluation rules for any profile-defined relay-
like action type, per Section 14.1.
A conformant ATP profile specification SHOULD also identify any
fields it introduces that are likely to contain personal data,
confidential operational data, security-sensitive policy data, or
provider-specific identifiers, and SHOULD provide guidance on
minimization, pseudonymization, or external-payload referencing for
those fields (Section 15).
A profile MUST NOT weaken ATP Core's cryptographic integrity
requirements (Section 10) or its acyclicity constraint (Section 7).
19.4. Canonicalization of Profile-Defined Fields
Profiles MAY define additional top-level fields and additional fields
within the action object. Unless explicitly excluded by the profile
specification, all profile-defined fields MUST participate in
canonicalization (Section 9) and nodeId computation (Section 10.1).
Profiles SHOULD NOT exclude fields from canonicalization. Exclusion
is reserved for transport-local annotations that are never used for
validation, authorization, policy decisions, relay fidelity, or audit
claims. A profile that excludes one or more of its own fields from
canonicalization MUST enumerate those fields explicitly and MUST
justify the exclusion. Fields excluded from canonicalization are not
covered by the node signature and therefore MUST NOT be relied upon
for tamper-evidence.
Validators that encounter a node with a profile value they do not
recognize MUST report the node according to one of the following
behaviors, declared by the validator's mode of operation:
* *Strict:* The node is reported as invalid because the validator
cannot evaluate profile-defined fields' contribution to
canonicalization. The node is also recorded under
profileUnresolved in the validation result (Section 13.6).
* *Permissive:* The node is canonicalized including all present
fields per Section 9. ATP Core validation proceeds. The
validator MUST report the unrecognized profile identifier under
profileUnresolved in the validation result so that operators can
detect interoperability gaps.
Bates Expires 11 November 2026 [Page 49]
Internet-Draft ATP May 2026
The default behavior is implementation-specific; profile
specifications MAY require strict behavior of conformant validators.
In either mode, profile-unresolved nodes MUST appear in the
profileUnresolved array of the validation result and MUST NOT be
silently suppressed.
19.5. Conformance Levels
ATP Core does not define conformance levels beyond the validation
mode minimums in Section 13.5 and the ATP Core conformance definition
in Section 13.7. Profile specifications MAY define additional
conformance levels appropriate to their domain -- for example, a
hypothetical ATP-MCP profile might define ATP-MCP-L1 / L2 / L3, or an
ATP-Healthcare profile might define ATP-Healthcare-Basic / Audit /
Regulator. ATP-MCP is one possible profile and is not specially
privileged by Core. Conformance level definitions and any composite
labels are out of scope for ATP Core and are addressed by individual
profile specifications and [ATP-PROFILES].
Profile specifications that define composite conformance labels
SHOULD also specify the test artifacts (golden vectors, validator
behavior expectations, conformance test suites) required to
substantiate a conformance claim at each level.
19.6. Worked Profile Reference
Appendix A demonstrates a profile-style action-type vocabulary
applied to an MCP-style interaction. The action types and
action.subtype values used in Appendix A are illustrative; a future
ATP-MCP profile is expected to formally register an interoperable
vocabulary.
19.7. Profile Assessment States
ATP Core distinguishes protocol validation from profile assessment.
A node MAY be ATP-valid while the enclosing scope remains profile-
incomplete.
Profiles MAY define assessment states including:
* *node-conformant:* A node satisfies ATP Core and applicable
profile node rules.
* *scope-open / profile-progressing:* The scope contains no known
profile violations but remains open or incomplete.
* *scope-sealed / profile-conformant:* The scope is closed according
to profile rules and satisfies all required profile emissions.
Bates Expires 11 November 2026 [Page 50]
Internet-Draft ATP May 2026
* *scope-sealed / profile-nonconformant:* The scope is closed but
one or more required profile emissions, parent relationships, or
completion pairs are missing or invalid.
ATP Core does not require a scope-sealing mechanism. Profiles that
require sealed-scope assessment MUST define how a scope is sealed and
how assessment results are represented. Such profiles MAY define
dedicated terminal action types (for example, scope-assessment or
scope-sealed event nodes); ATP Core does not register such types.
Profile assessment results are distinct from ATP Core validation
results (Section 13.6). Profile specifications that define
assessment states SHOULD define a corresponding result format and
SHOULD ensure that assessment results compose cleanly with ATP Core
validation results without overloading the categories defined in
Section 13.6.
20. Normative References
[ATP-TEST-VECTORS]
D. Bates, "ATP Core Test Vectors", Work in Progress,
Internet-Draft, draft-bates-atp-test-vectors-00, 2026,
<https://datatracker.ietf.org/doc/draft-bates-atp-test-
vectors/>.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3553] M. Mealling et al., "An IETF URN Sub-namespace for
Registered Protocol Parameters", RFC 3553, June 2003,
<https://www.rfc-editor.org/rfc/rfc3553>.
[RFC4151] T. Kindberg, S. Hawke, "The 'tag' URI Scheme", RFC 4151,
October 2005, <https://www.rfc-editor.org/rfc/rfc4151>.
[RFC8032] S. Josefsson, I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017,
<https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8126] M. Cotton, B. Leiba, T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
Bates Expires 11 November 2026 [Page 51]
Internet-Draft ATP May 2026
[RFC8785] A. Rundgren, B. Jordan, S. Erdtman, "JSON Canonicalization
Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
21. Informative References
[ATP-PROFILES]
D. Bates, "ATP Profile Framework", Work in Progress,
Internet-Draft, draft-bates-atp-profiles-00, 2026,
<https://datatracker.ietf.org/doc/draft-bates-atp-
profiles/>.
[KASSELMAN]
P. Kasselman et al., "AI Agent Authentication and
Authorization", Work in Progress, Internet-Draft, draft-
klrc-aiagent-auth-01, 2026,
<https://datatracker.ietf.org/doc/draft-klrc-aiagent-
auth/>.
[MCP] Anthropic and contributors, "Model Context Protocol
Specification", 2025, <https://modelcontextprotocol.io/>.
[NI] Y. Ni et al., "Security Requirements for AI Agents", Work
in Progress, Internet-Draft, draft-ni-a2a-ai-agent-
security-requirements-01, 2026,
<https://datatracker.ietf.org/doc/draft-ni-a2a-ai-agent-
security-requirements/>.
[NIST-AASI]
National Institute of Standards and Technology, "AI Agent
Standards Initiative", 2026, <https://www.nist.gov/caisi/
ai-agent-standards-initiative>.
[RFC7591] J. Richer et al., "OAuth 2.0 Dynamic Client Registration
Protocol", RFC 7591, July 2015,
<https://www.rfc-editor.org/rfc/rfc7591>.
[RFC7942] Y. Sheffer, A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 7942, July
2016, <https://www.rfc-editor.org/rfc/rfc7942>.
[RFC8615] M. Nottingham, "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, March 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[RFC8693] M. Jones et al., "OAuth 2.0 Token Exchange", RFC 8693,
January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.
Bates Expires 11 November 2026 [Page 52]
Internet-Draft ATP May 2026
[ROSENBERG]
J. Rosenberg, C. Jennings, "Framework, Use Cases and
Requirements for AI Agent Protocols", Work in Progress,
Internet-Draft, draft-rosenberg-ai-protocols-00, 2025,
<https://datatracker.ietf.org/doc/draft-rosenberg-ai-
protocols/>.
[SCITT] H. Birkholz et al., "An Architecture for Trustworthy and
Transparent Digital Supply Chains", Work in Progress,
Internet-Draft, draft-ietf-scitt-architecture, 2025,
<https://datatracker.ietf.org/doc/draft-ietf-scitt-
architecture/>.
[SMITH] A. Smith, N. Pai, "Governance Framework for AI-Mediated
Autonomous Network Device Management", Work in Progress,
Internet-Draft, draft-smith-opsawg-ai-network-governance-
00, 2026, <https://datatracker.ietf.org/doc/draft-smith-
opsawg-ai-network-governance/>.
Worked Example: MCP Tool Discovery and Invocation
This appendix pressure-tests whether the Section 8 node schema
carries the weight of a realistic multi-party agent/tool interaction.
It illustrates multi-issuer chain-of-custody, fan-in, the
issuer/agent/actor split, relay node semantics, and the request/
completion pairing pattern.
The action types and action.subtype values used in this appendix are
illustrative only. They are non-normative and MUST NOT be treated as
registered ATP-MCP profile values. A future ATP-MCP profile is
expected to formally register an interoperable vocabulary.
A.1 Scenario
A human (Bob) is logged into an orchestrator platform. The platform
hosts an orchestrator agent that needs to complete a task requiring
an external tool. The platform is connected to an MCP (Model Context
Protocol [MCP]) broker, which fronts one or more tool services. The
orchestrator discovers tools via the broker, selects one, invokes it,
and synthesizes the result.
Three distinct issuers sign nodes in this chain:
* issuer:platform.example -- the orchestrator runtime (signs
orchestrator-side nodes).
* issuer:mcp-broker.example -- the MCP broker (signs broker-side
nodes).
Bates Expires 11 November 2026 [Page 53]
Internet-Draft ATP May 2026
* issuer:tool-crm.example -- the downstream tool service (signs
execution nodes).
Each issuer holds its own Ed25519 key pair. No issuer signs another
issuer's nodes. The DAG is assembled from cross-issuer parent
references.
All nodes share a single scope: "wf-8f3a1b" representing one workflow
execution. Cross-scope references are not used in this example but
are PERMITTED per Section 12.
The human actor is represented by the pseudonymous identifier
psn:9c3a7e4f-bob (resolvable through a separate identity-resolution
service per Section 15.4). The actor field persists across
orchestrator-side nodes. The pseudonymous form is used in this
example to align with the privacy guidance in Section 15.4 and
Section 16.9; production deployments SHOULD follow the same pattern
rather than embedding directly identifying values such as email
addresses or employee numbers in actorId.
Each example node uses a registered ATP Core value in action.type and
a profile-defined descriptive value in action.subtype. The subtype
field is shown to illustrate how a future ATP-MCP profile could add
domain-specific naming on top of the Core action types registered in
Section 17.1.
A.2 Node Sequence
The following seven nodes form the chain. Each is shown in its pre-
signing structure; nodeId and signature are elided for readability
but would be present and computed per Section 9 and Section 10.
Node 1 -- tool catalog query (atp:request)
Orchestrator asks the broker what tools are available.
Bates Expires 11 November 2026 [Page 54]
Internet-Draft ATP May 2026
{
"timestamp": "2026-04-23T12:58:00Z",
"scope": "wf-8f3a1b",
"issuer": { "issuerId": "platform.example", "keyId": "platform-2026-04" },
"agent": { "agentId": "orchestrator-agent", "version": "1.3.0" },
"actor": { "actorId": "psn:9c3a7e4f-bob", "authContext": "saml:corp-idp" },
"action": {
"type": "atp:request",
"subtype": "tool_catalog_query",
"inputHash": "sha256:ab12..."
},
"parents": []
}
Root node. parents: []. inputHash covers the broker endpoint and
query parameters. outputHash is omitted because the response has not
arrived yet -- this is a request node per the Section 16.2 request/
completion pairing pattern. The subtype field shown here is profile-
defined and would be specified by an ATP-MCP profile per
Section 20.3.
Node 2 -- tool catalog response (atp:completion)
Broker returns its tool inventory. *Signed by the broker, not the
orchestrator.*
{
"timestamp": "2026-04-23T12:58:00.110Z",
"scope": "wf-8f3a1b",
"issuer": { "issuerId": "mcp-broker.example", "keyId": "broker-2026-04" },
"agent": { "agentId": "mcp-catalog-service", "version": "2.1.0" },
"action": {
"type": "atp:completion",
"subtype": "tool_catalog_response",
"inputHash": "sha256:ab12...",
"outputHash": "sha256:cd34..."
},
"parents": ["<nodeId of Node 1>"]
}
The broker has no actor -- the action is not being taken on behalf of
a human principal; it is a service response. The actor field is
OPTIONAL per Section 8 and is omitted here. parents points back to
the orchestrator's query, forming a cross-issuer link. This node
serves as the completion node for Node 1's request, carrying the
outputHash that Node 1 omitted.
Bates Expires 11 November 2026 [Page 55]
Internet-Draft ATP May 2026
Node 3 -- tool selection decision (atp:decision)
Orchestrator picks a tool based on the catalog. This is a
*decisional node* per Section 17.1: no external system is called, but
a decision is recorded as part of the chain.
{
"timestamp": "2026-04-23T12:58:00.240Z",
"scope": "wf-8f3a1b",
"issuer": { "issuerId": "platform.example", "keyId": "platform-2026-04" },
"agent": { "agentId": "orchestrator-agent", "version": "1.3.0" },
"actor": { "actorId": "psn:9c3a7e4f-bob", "authContext": "saml:corp-idp" },
"action": {
"type": "atp:decision",
"subtype": "tool_selection_decision",
"inputHash": "sha256:cd34...",
"outputHash": "sha256:ef56..."
},
"parents": ["<nodeId of Node 2>"]
}
inputHash references the catalog the orchestrator saw; outputHash
references the selection rationale (prompt trace, scoring notes, or
policy decision). This node is the auditable answer to "why did the
agent choose this tool?"
Node 4 -- tool invocation request (atp:request)
Orchestrator asks the broker to invoke the chosen tool.
{
"timestamp": "2026-04-23T12:58:00.380Z",
"scope": "wf-8f3a1b",
"issuer": { "issuerId": "platform.example", "keyId": "platform-2026-04" },
"agent": { "agentId": "orchestrator-agent", "version": "1.3.0" },
"actor": { "actorId": "psn:9c3a7e4f-bob", "authContext": "saml:corp-idp" },
"action": {
"type": "atp:request",
"subtype": "tool_invocation_request",
"inputHash": "sha256:gh78..."
},
"parents": ["<nodeId of Node 3>"]
}
Request node -- outputHash is omitted per Section 16.2. Linear
descendant of the selection decision.
Bates Expires 11 November 2026 [Page 56]
Internet-Draft ATP May 2026
Node 5 -- tool execution (atp:completion)
The tool service executes the request and signs its own node. The
broker forwards the request but the tool signs directly, with parents
pointing at the invocation request.
{
"timestamp": "2026-04-23T12:58:00.610Z",
"scope": "wf-8f3a1b",
"issuer": { "issuerId": "tool-crm.example", "keyId": "crm-2026-04" },
"agent": { "agentId": "crm-lookup-service", "version": "5.0.2" },
"action": {
"type": "atp:completion",
"subtype": "tool_execution",
"inputHash": "sha256:gh78...",
"outputHash": "sha256:ij90..."
},
"parents": ["<nodeId of Node 4>"]
}
Third issuer enters the chain. No actor -- this is a service-origin
action.
Node 6 -- tool execution response (atp:relay)
Broker relays the execution result back to the orchestrator. This
node is _optional_ -- if the orchestrator accepts the tool's signed
node directly, the broker's relay does not require its own node.
Shown here for completeness and to illustrate relay node semantics.
{
"timestamp": "2026-04-23T12:58:00.630Z",
"scope": "wf-8f3a1b",
"issuer": { "issuerId": "mcp-broker.example", "keyId": "broker-2026-04" },
"agent": { "agentId": "mcp-relay-service", "version": "2.1.0" },
"action": {
"type": "atp:relay",
"subtype": "tool_execution_response",
"inputHash": "sha256:ij90...",
"outputHash": "sha256:ij90..."
},
"parents": ["<nodeId of Node 5>"]
}
Bates Expires 11 November 2026 [Page 57]
Internet-Draft ATP May 2026
*Relay node.* inputHash == outputHash because the broker asserts it
is not transforming the payload. Per Section 14.1, this is an issuer
assertion of fidelity, not proof of non-modification. Validators
requiring strong fidelity guarantees SHOULD verify Node 5's signature
directly rather than relying solely on this relay claim (see
Section 14.2 for the verified/asserted/contradicted fidelity states).
Node 7 -- decision synthesis (atp:decision)
Orchestrator synthesizes a final answer from the tool result. *This
is a fan-in node* -- it has two parents: the relay's execution
response (Node 6) and the selection decision (Node 3), because the
synthesis depends on both the evidence and the prior reasoning.
{
"timestamp": "2026-04-23T12:58:00.820Z",
"scope": "wf-8f3a1b",
"issuer": { "issuerId": "platform.example", "keyId": "platform-2026-04" },
"agent": { "agentId": "orchestrator-agent", "version": "1.3.0" },
"actor": { "actorId": "psn:9c3a7e4f-bob", "authContext": "saml:corp-idp" },
"action": {
"type": "atp:decision",
"subtype": "decision_synthesis",
"inputHash": "sha256:kl12...",
"outputHash": "sha256:mn34..."
},
"parents": [
"<nodeId of Node 6>",
"<nodeId of Node 3>"
]
}
Fan-in illustrates why the DAG model is necessary: a linear log could
not express that the synthesis is causally dependent on both the
selection rationale _and_ the tool result.
A.3 DAG Structure
The following diagram shows the node-and-edge structure of the
example, with nodes grouped by issuer:
Bates Expires 11 November 2026 [Page 58]
Internet-Draft ATP May 2026
graph TD
subgraph "issuer: platform.example"
N1["Node 1<br/>atp:request<br/>tool_catalog_query"]
N3["Node 3<br/>atp:decision<br/>tool_selection_decision"]
N4["Node 4<br/>atp:request<br/>tool_invocation_request"]
N7["Node 7<br/>atp:decision<br/>decision_synthesis"]
end
subgraph "issuer: mcp-broker.example"
N2["Node 2<br/>atp:completion<br/>tool_catalog_response"]
N6["Node 6<br/>atp:relay<br/>tool_execution_response"]
end
subgraph "issuer: tool-crm.example"
N5["Node 5<br/>atp:completion<br/>tool_execution"]
end
N1 --> N2
N2 --> N3
N3 --> N4
N4 --> N5
N5 --> N6
N6 --> N7
N3 --> N7
style N1 fill:#2E75B6,color:#fff
style N3 fill:#2E75B6,color:#fff
style N4 fill:#2E75B6,color:#fff
style N7 fill:#2E75B6,color:#fff
style N2 fill:#6AAF50,color:#fff
style N6 fill:#6AAF50,color:#fff
style N5 fill:#D94A4A,color:#fff
The following sequence diagram shows the temporal message flow of the
same interaction:
Bates Expires 11 November 2026 [Page 59]
Internet-Draft ATP May 2026
sequenceDiagram
participant Orchestrator
participant Broker
participant Tool
Orchestrator->>Broker: atp:request / tool_catalog_query (Node 1)
Broker-->>Orchestrator: atp:completion / tool_catalog_response (Node 2)
Orchestrator->>Orchestrator: atp:decision / tool_selection_decision (Node 3)
Orchestrator->>Broker: atp:request / tool_invocation_request (Node 4)
Broker->>Tool: (forwarded)
Tool-->>Broker: atp:completion / tool_execution (Node 5)
Broker-->>Orchestrator: atp:relay / tool_execution_response (Node 6)
Orchestrator->>Orchestrator: atp:decision / decision_synthesis (Node 7, fan-in)
Seven nodes. Three issuers. One actor (human) across all
orchestrator-side nodes; no actor on broker/tool-side nodes. One
workflow scope. One fan-in at the synthesis step. One relay node at
the broker layer.
A.4 What This Example Demonstrates
* *Section 8 schema carries the weight.* All seven nodes serialize
cleanly into the base schema. No new top-level fields were
required. The subtype field used in action is profile-defined and
would be specified by an ATP-MCP profile per Section 20.3.
* *Three-way identity split does real work.* The orchestrator's
nodes (1, 3, 4, 7) share issuer and agent but carry the human
actor. The broker and tool nodes carry no actor -- the action is
not human-delegated at that layer. This is exactly the
distinction the split is designed to capture.
* *Cross-issuer chain of custody works via parents.* No issuer signs
another issuer's nodes. Chain integrity comes from content-
addressed nodeId references, which are tamper-evident per
Section 10. When the tool's signed execution node (Node 5) is
present in the chain, the broker is a forwarding layer rather than
the authoritative origin of the tool result; profiles MAY override
this default by defining alternative authority semantics for relay
nodes.
* *Fan-in is necessary, not decorative.* The synthesis node (Node 7)
demonstrates why a DAG beats a linear log: causal dependency on
both evidence and prior decision.
Bates Expires 11 November 2026 [Page 60]
Internet-Draft ATP May 2026
* *Request/completion pairing works cleanly.* Nodes 1 and 4 use
atp:request and omit outputHash per Section 16.2. Nodes 2 and 5
use atp:completion and serve as their respective completion nodes.
The pattern handles cross-issuer request/response naturally.
* *Relay semantics are explicit.* Node 6 uses atp:relay and asserts
relay fidelity (inputHash == outputHash). Per Section 14.1, this
is an assertion, not proof. Validators can verify Node 5 directly
for stronger fidelity (Section 14.2).
* *"Node-worthy" selection is profile responsibility.* Node 6 could
legitimately be omitted in this Core example. ATP Core does not
prescribe; an ATP-MCP profile is expected to define node-
worthiness rules per Section 20.3.
A.5 Profile Note: action.type and action.subtype Vocabulary
The ATP Core action types used in this example (atp:request,
atp:completion, atp:relay, atp:decision) are registered in
Section 17.1. The descriptive subtypes (tool_catalog_query,
tool_invocation_request, etc.) are illustrative and are carried in a
profile-defined action.subtype field. Each example node uses a
registered ATP Core value in action.type and a profile-defined
descriptive value in action.subtype.
The subtype values used here are non-normative and MUST NOT be
treated as registered ATP-MCP profile values. A future ATP-MCP
profile specification is expected to define a canonical vocabulary
for MCP-style interactions and to register that vocabulary under the
Section 17.1 Specification Required policy. The vocabulary MAY be
expressed through action.subtype values, additional atp:-prefixed
action types (e.g., atp:mcp.tool_invocation), or both -- that design
decision is left to the profile authors.
Future Work and Areas for Further Refinement
The following areas are candidates for future refinement as
implementation experience accumulates:
* Empirical performance data across storage patterns and graph
shapes to validate the guidance in Section 16.10.
* Operational patterns for cross-scope federation mechanisms
referenced in Section 16.3.
Bates Expires 11 November 2026 [Page 61]
Internet-Draft ATP May 2026
* Profile specifications for domain-specific interaction patterns,
such as an ATP-MCP profile for MCP-style tool discovery and
invocation sequences and an ATP-Gateway profile for AI gateway
routing, guardrail, cache, and provider-fallback semantics.
* Formal specification of conformance levels (e.g., composite labels
such as ATP-MCP-L1/L2/L3) within profile specifications. ATP Core
defers conformance-level definition to profiles per Section 20.5.
* Scope-level assessment or sealing semantics for chains where an
explicit "no further nodes will be emitted" signal is required.
ATP Core defines the assessment-state vocabulary in Section 20.7
but does not define scope-sealing mechanisms; profiles that
require sealed-scope assessment are responsible for those
definitions.
* Streaming-response semantics for profiles that target token-
streaming gateways, including whether each token chunk is a node,
the final response is a node, or only a digest of the stream is
hashed into one completion node. ATP Core requires profiles that
support streaming to declare these semantics per Section 20.3.
* A normative key-discovery path (e.g., a well-known URI
registration under [RFC8615]). ATP Core explicitly defers this to
a future specification (Section 16.1, Section 17.3).
* A media type registration for the Section 13.6 validation result
format, if cross-organization exchange of validation results
becomes a recognized use case.
* Algorithm-agility mechanisms for the hash and signature primitives
currently fixed at SHA-256 and Ed25519. ATP Core treats this as a
forward-compatibility issue addressed by a future revision rather
than negotiated within this version.
Related Work
Several active Internet-Drafts and standards initiatives address
aspects of AI agent security, identity, and governance. ATP is
designed to be complementary to these efforts rather than
overlapping. This appendix describes the relationship between ATP
and each relevant body of work.
Bates Expires 11 November 2026 [Page 62]
Internet-Draft ATP May 2026
C.1 Identity and Authentication
[NI] defines security requirements for AI agents across provisioning,
registration, discovery, cross-domain interconnection, and access
control. It introduces an Agent Credential Authority (ACA) and an
Agent Registry Service (ARS) as part of that architecture.
[KASSELMAN] proposes AI Agent Authentication and Authorization using
existing standards including WIMSE, SPIFFE, and the OAuth 2.0 family.
It defines the Agent Identity Management System (AIMS) as a
conceptual model for establishing, maintaining, and evaluating the
identity and permissions of agent workloads.
Both efforts answer the question "is this agent authenticated and
authorized to act?" ATP answers a different question: "what did this
agent do, and can that action be independently verified?" ATP does
not replace credential issuance, registration, workload identity, or
authorization frameworks. An ATP deployment MAY consume credentials
or identifiers established by systems such as ACA/ARS or AIMS-
compatible deployments as the operational basis for issuer.keyId,
agent.agentId, and actor.authContext mappings.
C.2 Agent Communication Frameworks
[ROSENBERG] describes a framework for AI agent communications,
surveys protocols including MCP, A2A, and the Agntcy Framework, and
frames requirements for AI agent communications on the Internet.
ATP is not a communication protocol. ATP does not define how agents
discover, connect to, or exchange messages with one another. ATP
defines how actions taken during or as a result of those
communications are recorded as cryptographically signed, causally
linked graph nodes. ATP can therefore serve as an accountability and
audit layer for systems built on communication frameworks such as
those described in [ROSENBERG].
C.3 Domain-Specific Governance
[SMITH] defines a governance framework for AI-mediated autonomous
network device management. It establishes thirteen governance areas
including human authority, bounded autonomy, transparency,
reversibility, escalation, and related safety controls for AI-
mediated network management systems.
ATP and [SMITH] operate at different layers. [SMITH] defines
governance principles and control expectations. ATP defines
governance evidence: a verifiable record of what agents actually did.
The two are complementary. Governance principles without verifiable
Bates Expires 11 November 2026 [Page 63]
Internet-Draft ATP May 2026
evidence are difficult to prove; verifiable evidence without
governance principles is data without policy. ATP can provide the
evidentiary substrate used to demonstrate compliance or non-
compliance with domain-specific governance frameworks.
C.4 Standards Coordination
[NIST-AASI] describes the NIST AI Agent Standards Initiative, which
aims to foster industry-led technical standards and open protocols so
that agents function securely on behalf of users and interoperate
smoothly across the digital landscape. ATP's focus on verifiable
agent-action lineage falls within that broader accountability and
interoperability space.
C.5 Existing RFCs Applied to Agent Systems
Several existing RFCs are relevant in agent deployments.
[RFC8693] defines OAuth 2.0 Token Exchange, which can be used for
secure delegation and scoped authority grants between systems.
[RFC7591] defines OAuth 2.0 Dynamic Client Registration Protocol,
which can be applied to automated registration of agent workloads.
ATP does not depend on or replace these RFCs. Instead, ATP can
compose with them. For example, token-exchange contexts may be
reflected in actor.authContext, while identifiers established through
registration flows may be mapped by implementations into
agent.agentId and issuer.issuerId.
C.6 Transparency and Supply-Chain Provenance
[SCITT] (Supply Chain Integrity, Transparency and Trust) defines an
architecture for issuing, registering, and verifying signed
statements about software supply-chain artifacts via append-only
transparency services. SCITT and ATP address related but distinct
problems.
SCITT publishes signed statements to an auditable transparency log so
that the existence and order of statements can be verified
independently of the issuer. ATP defines a directed acyclic graph of
signed agent-action nodes whose causal relationships are themselves
cryptographically tamper-evident. SCITT is publication-and-
witnessing oriented; ATP is causality-and-heritage oriented.
The two are composable. An ATP deployment that requires independent
witnessing of node existence and ordering MAY publish ATP nodes (or
their nodeId values) as signed statements to a SCITT-compatible
transparency service. In that composition, ATP provides the
Bates Expires 11 November 2026 [Page 64]
Internet-Draft ATP May 2026
verifiable causal structure of agent actions, and SCITT provides
operator-independent evidence that those nodes existed at a given
time and have not been retroactively suppressed. This composition is
the recommended deployment pattern for the anti-suppression scenario
discussed in Section 14.6.
ATP Core does not require a transparency layer. Future profile
specifications MAY describe SCITT-compatible publication patterns
where stronger anti-suppression guarantees are needed.
C.7 ATP's Distinct Contribution
The gap ATP fills is specific: none of the above efforts define a
protocol for cryptographically signed, DAG-structured, causally
linked records of agent actions with explicit separation of issuer,
agent, and actor identity. Adjacent efforts address who agents are,
what agents are allowed to do, how agents communicate, what
governance principles they should follow, and how supply-chain
statements are made transparent. ATP addresses what agents actually
did, provably, with tamper-evident lineage that does not require
trusting the platform that produced the record.
ATP is intentionally narrow so that it can compose with identity,
authorization, communication, governance, and transparency layers
defined by adjacent efforts without creating conflicts or
dependencies that would impair adoption of either ATP or the systems
it complements.
Author's Address
David A. Bates
SVT Robotics
Email: david.bates@svtrobotics.com
URI: https://www.svtrobotics.com/
Bates Expires 11 November 2026 [Page 65]