Agent Transaction Protocol (ATP)

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

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

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

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

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

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

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

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

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

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": {}
}

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).¶
• 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;¶
• 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.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.¶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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):¶

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

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

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

{
  "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": []
}

{
  "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>"]
}

{
  "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>"]
}

{
  "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>"]
}

{
  "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>"]
}

{
  "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>"]
}

{
  "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>"
  ]
}

A.3 DAG Structure

The following diagram shows the node-and-edge structure of the example, with nodes grouped by issuer:¶

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

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

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