AGTP Identifier Chain

Introduction

The Accountability Gap An agent that takes an action without a chain of custody is an anonymous actor. Existing transport protocols (HTTP, gRPC, message queues) record that a request occurred, that an action followed, and that a log entry was written, but they cannot prove that the specific agent that issued the request was the specific agent that took the action, that the action was authorized by a specific governance decision, or that the log entry was the original record and no reconstruction. The accountability gap matters in three settings:

Regulatory examination under frameworks such as the EU AI Act , which requires that high-risk AI systems maintain records sufficient to reconstruct the decision-making process.
Commercial dispute resolution, where a counterparty asserts that an agent took an action and the operator denies the binding.
Incident response, where the operator needs to identify which agent acted, which human is accountable, and what the governance system decided at the moment of action.

AGTP closes the gap by treating the identifier chain as a first-class protocol primitive; on HTTP it is application-level metadata.

A Layered Model Over Existing Primitives The identifiers defined by this document are no new inventions. The AGTP draft family already provides most of them. Agent-ID is defined in and derived from the Agent Genesis per . Owner-ID resolves to the principal recorded in the Agent Genesis. Session-ID is defined in and given session semantics by . Task-ID is defined in for workflow correlation. The Attribution-Record envelope is defined in and already carries server identity, timestamp, request hash, and response status as a JWS-signed attestation on every response. What this document adds is the connective layer:

A small set of additional identifiers (Request-ID, Response-ID, Action-ID, Evaluation-ID, Decision-ID) that extend the Attribution-Record envelope to record the per-interaction and governance-evaluation events that base AGTP has yet to capture by themselves.
The Audit-ID, defined as the cryptographic hash of the canonical extended Attribution-Record. The Audit-ID is the identifier of the audit record itself.
The per-agent hash chain. Each Attribution-Record an agent emits carries the Audit-ID of the agent's immediately preceding Attribution-Record. The chain is the agent's accountability trail.

This document introduces no new transparency log. The identity-lifecycle transparency log defined in records Agent Genesis issuance and lifecycle events; this document operates against the per-response Attribution-Record envelope of . The log records identity events; the envelope records actions. Each concern has its own record.

Identifier Layers The identifier chain is organized into four layers, plus the Audit-ID that anchors them:

Persistent identifiers are established at agent provisioning and remain stable for the agent's operational lifetime: Agent-ID and Owner-ID.
Context identifiers group multiple interactions under a shared operational context: Session-ID and Task-ID.
Per-interaction identifiers are minted at the moment of each interaction and bind the request, the response, and the action taken: Request-ID, Response-ID, and Action-ID.
Governance identifiers record the evaluation that authorized the action and the specific verdict produced: Evaluation-ID and Decision-ID.

The Audit-ID is the chain anchor that binds all of the above into a single verifiable artifact at each action. The layer model is logical: it describes the role each identifier plays in the accountability chain. The cryptographic binding that makes the chain tamper-evident is established inside the extended Attribution-Record JWS, where every identifier present is signed together with the agent's preceding Audit-ID. An identifier that appears in an Attribution-Record but cannot be linked to the records it claims to depend on (an Action-ID without its Evaluation-ID and Decision-ID, an Audit-ID whose previous_audit_id references no known predecessor) is a chain break and SHALL be treated as evidence of forgery or omission.

Relationship to the AGTP Draft Family This document is the connective specification across the AGTP draft family. It replaces no existing draft.

provides the Attribution-Record envelope, the Agent-ID, Session-ID, and Task-ID headers, the Request-Signature that binds every request to the agent's current key, the Delegation-Chain header and its verification, and the manifest signing infrastructure on which Attribution-Records are signed. The Owner-ID is recorded in the Agent Genesis and the Agent Identity Document () and resolved from the Agent-ID; it is never transmitted as a request header.
populates the Evaluation-ID record with the trust tier, verification path, trust score, and dimensional scoring defined there. Trust scoring is one set of dimensions within a governance evaluation.
records identity-lifecycle events (Agent Genesis issuance, revocation, suspension, reinstatement, deprecation). Audit-IDs link to identity-lifecycle events when an agent's identity state changes. Audit-IDs are committed to the AGTP-LOG transparency log only where a deployment requires tamper evidence against the recording agent itself (); the per-agent chain alone is tamper-evident to a verifier that trusts the agent's key.
carries the Agent-ID in the agent-id X.509 v3 extension. The Agent Certificate's TLS binding makes the wire identity verifiable at the TLS layer.
already specifies that the Attribution-Record on a PURCHASE response carries merchant_id, merchant_fingerprint, and intent_assertion_jti fields. This document specifies how those merchant-specific fields coexist with the identifier chain fields in the same extended Attribution-Record.
specifies ESTABLISH, RESUME, and TERMINATE for Session-ID and the session root: a rolling SHA-256 commitment over the Audit-IDs of a session's responses. This document treats Session-ID as a context identifier within the chain and the session root as the two-party commitment that composes with the one-party chain specified here ().
specifies the method vocabulary and the alias resolution that populates requested_method; specifies the synthesized contracts whose synthesis_id, contract_hash, and negotiation_origin appear as extension fields.

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 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the following terms.

Identifier Chain:: The ordered set of identifiers defined by this document (Agent-ID, Owner-ID, Session-ID, Task-ID, Request-ID, Response-ID, Evaluation-ID, Action-ID, Decision-ID, Audit-ID) that together constitute a verifiable record of an agent action.
Persistent Identifier:: An identifier whose value is established at agent provisioning and remains stable for the agent's operational lifetime. Agent-ID and Owner-ID are persistent identifiers.
Context Identifier:: An identifier that groups multiple per-interaction events under a shared operational context. Session-ID and Task-ID are context identifiers.
Per-Interaction Identifier:: An identifier minted at the moment of a specific interaction. Request-ID, Response-ID, and Action-ID are per-interaction identifiers.
Governance Identifier:: An identifier minted by a governance evaluation. Evaluation-ID and Decision-ID are governance identifiers.
Audit-ID:: The cryptographic hash of the canonical extended Attribution-Record, computed as specified in . The Audit-ID is the identifier of a single audit record and the chain anchor that links the record to the predecessor record in the agent's hash chain.
Extended Attribution-Record:: The base AGTP Attribution-Record JWS envelope, augmented with the identifier-chain fields specified by this document. The extension is additive; existing Attribution-Record consumers remain conformant.
Chain Link:: A cryptographic binding between two identifiers such that the successor identifier commits to the predecessor identifier. A chain link is established by including the predecessor identifier in the canonical input over which the successor identifier is computed or signed.
Chain Break:: A condition in which an identifier in the chain cannot be linked to its predecessor. A chain break voids the audit value of the record and SHALL be treated as evidence of forgery or omission.

Identifier Stack Overview The identifier chain is layered. Each identifier captures accountability for the moment it represents. The diagram below shows the relationship. The chain reads top to bottom. Agent-ID is the foundational identifier from which the accountability chain originates. The Audit-ID is the per-action hash that closes the chain and links to the agent's previous action.

Persistent Identifiers

Agent-ID Agent-ID is the foundational identifier of the chain. It is the 256-bit cryptographic hash of the agent's Agent Genesis document, as defined by the Agent Identity Taxonomy in . Agent-ID is permanent for the operational lifetime of the agent; revocation produces a revoked state in the registry but does neither retires nor reissues the identifier. Agent-ID MUST be:

Derived from the Agent Genesis via the procedure specified in : agent_id = sha256(canonical_json(agent_genesis)).
Rendered on the wire as 64 lowercase hexadecimal characters.
Carried in the Agent-ID request header on every AGTP request, per . When the request carries Agent-ID, the response SHOULD echo the same value in the Agent-ID response header to correlate the response with the requesting agent. The responding host's identity is carried separately in the Server-ID response header per ; Server-ID names the host that processed the request; it identifies no agent. When the audit consumer needs the canonical Agent-ID of the agent that produced the response, it is recorded in the agent_id field of the Attribution-Record payload.
Resolvable to an Agent Identity Document by any AGTP-aware infrastructure component, via the resolution mechanics specified in .

Agent-ID identifies who the actor is throughout the agent's operational lifetime. Every subsequent identifier in the chain links back to Agent-ID. An action whose Agent-ID cannot be resolved is an anonymous action and SHALL be refused by AGTP-aware infrastructure.

Owner-ID Owner-ID is the identifier of the human or organizational principal accountable for the agent. Owner-ID is bound to Agent-ID at provisioning and recorded in the Agent Genesis document. The binding is asserted by the governance platform that issued the Agent Genesis and is verifiable through the signature on the Genesis document. Owner-ID MUST be:

Present in the Agent Genesis document as the owner_id field and in the Agent Identity Document the Agent-ID resolves to ().
Resolved by the recipient from the Agent-ID of every request; never carried as a request header. A recipient that needs the Owner-ID reads it from the verified Identity Document, which binds it to the Agent-ID by the issuer's signature.
Resolvable to an Owner Identity Document that records the legal identity of the principal (a natural person, a registered organization, or a legal entity recognized by the governance platform's jurisdiction).
Stable for the operational lifetime of the agent. Ownership transfer requires reissuance of the Agent Genesis and produces a new Agent-ID.

Owner-ID MAY use any identifier scheme the governance platform recognizes: a national identity number where lawful, a registered organization number, a DID, or a platform-issued identifier. The identifier scheme MUST be declared in the Owner Identity Document under the id_scheme field. An Agent-ID without a resolvable Owner-ID lacks an accountability terminus and SHALL be treated as a Tier 3 (Experimental) agent per , regardless of any other trust signals it carries.

Why Both Identifiers Are Required Agent-ID answers the question "what acted." Owner-ID answers the question "who is responsible." A regulatory examination that asks "who is liable for this action" requires both. An incident response that asks "which human do we contact" requires Owner-ID. A counterparty that asks "is this agent who it claims to be" requires Agent-ID. The two identifiers MUST appear together on every request. A request carrying Agent-ID without Owner-ID is a malformed AGTP request and SHALL be refused with status 400 Bad Request.

Context Identifiers

Session-ID Session-ID identifies a logical context shared between two or more AGTP participants under which multiple method invocations are correlated. Session-ID is defined as a request header by and given establishment semantics by . For the purposes of the identifier chain:

Session-ID MAY be absent. Many agent interactions are single-method exchanges that have no session context.
When present, Session-ID MUST be carried on every request and response within the session, per .
Session-ID MUST be included in the extended Attribution-Record when present on the request that triggered the response.

A session collects multiple Request-ID, Response-ID, and Action-ID triples under one operational context. The session is no action in itself; it is the context within which actions occur.

Task-ID Task-ID identifies a specific task or operation that spans multiple requests, typically within a workflow that involves multiple agents or services. Task-ID is defined as a request and response header by . For the purposes of the identifier chain:

Task-ID MAY be absent. Many actions fall outside any multi-request task.
When present, Task-ID MUST be carried on every request and response that participates in the task, per .
Task-ID MUST be included in the extended Attribution-Record when present on the request that triggered the response.

Task-ID and Session-ID are independent. A long session may contain multiple discrete tasks. A single task may span multiple sessions if the workflow requires it. The two identifiers MAY both be present on the same request.

Per-Interaction Identifiers

Request-ID Request-ID captures the initiation of a specific interaction. When an agent issues a request to a tool, an API, another agent, or a service, the caller MUST mint a Request-ID and include it on the outbound request. Request-ID MUST be:

A UUIDv7 per or a ULID rendered as 26 base32 characters, selected at the caller's discretion. Both schemes provide monotonic ordering and high collision resistance.
Minted by the calling agent, never by the server. Server-minted identifiers break the causal chain because the caller cannot prove it issued the request before the server received it.
Carried in the Request-ID request header.
Unique within the caller's identifier space for the lifetime of the calling agent. Collisions across agents are tolerated; collisions within an agent's own request space are a conformance failure.

The Request-ID enables tracing an action back to its origin. An audit trail that records an action but cannot identify the request that initiated it cannot survive examination. Without Request-ID, the record shows that something happened but leaves open what initiated it.

Response-ID Response-ID links the response to the request that generated it. The responding agent MUST mint a Response-ID and include it on the outbound response. Response-ID MUST be:

A UUIDv7 or ULID, with the same construction rules as Request-ID.
Minted by the responding agent.
Carried in the Response-ID response header.
Paired with the corresponding Request-ID by echoing the request's Request-ID header on the response, following the same echo convention uses for Task-ID. The responding agent SHOULD echo Request-ID unchanged in the response.

Without Response-ID, the audit trail can show that a request was made and that an action followed, but cannot prove that the specific response to the specific request was what drove the action. The linkage between what the agent received and what it did next requires both identifiers to be present.

Action-ID Action-ID captures the specific action taken. An agent may take multiple actions within a session or task; each action MUST have its own Action-ID to be separately traceable. Action-ID MUST be:

Minted by the agent at the moment of action.
A UUIDv7 or ULID, with the same construction rules as Request-ID.
Carried as the action_id field in the extended Attribution-Record. Action-ID MAY also be carried on the wire as the Action-ID response header for client convenience.
Co-located with the Request-ID that initiated the action and the Response-ID that informed it inside the same extended Attribution-Record JWS. The JWS signature binds all three identifiers together as a single signed unit.

Action-ID MUST be present in the extended Attribution-Record for any method that produces state change, including (without being limited to) EXECUTE, DELEGATE, ESCALATE, CONFIRM, SUSPEND, PURCHASE, and the identity-lifecycle methods that trigger AGTP-LOG events (ACTIVATE, REVOKE, REINSTATE, DEPRECATE per ). Action-ID MAY be absent for cognitive methods (QUERY, DISCOVER, DESCRIBE, SUMMARIZE, PLAN, PROPOSE) that return information without recording an action in the accountability sense; the Attribution-Record is still emitted but the action_id field is omitted.

Governance Identifiers

Evaluation-ID Evaluation-ID is the identifier for the governance evaluation applied before an action proceeded. This is the record of the evaluation event, distinct from the verdict that the evaluation produced. Evaluation-ID MUST be:

Minted by the governance system at the moment the evaluation begins.
A UUIDv7 or ULID.
Carried as the evaluation_id field in the extended Attribution-Record.
Resolvable to an Evaluation Record per that captures the inputs evaluated, the dimensional scores computed, the confidence level, and the verdict produced.

Evaluation Record The Evaluation Record is held by the governance platform that performed the evaluation. The Evaluation Record SHALL contain:

evaluation_id (this identifier).
agent_id (the agent being evaluated).
owner_id (the owner accountable for the agent).
request_id (the request that triggered the evaluation).
contract_id (the identifier of the governance contract or policy in effect at the time of evaluation; the contract scheme is operator-defined and tracked as an Open Item in this revision).
inputs (a canonical representation of the inputs evaluated, with PII redacted per the governance platform's policy).
dimension_scores (a map of dimension names to scores, per ).
confidence (a scalar in the range 0.0 to 1.0 expressing the evaluator's confidence in its dimensional measurements).
timestamp_start (RFC 3339 timestamp of evaluation initiation).
timestamp_end (RFC 3339 timestamp of evaluation completion).

The Evaluation Record is signed by the governance platform's key and stored in the governance platform's evaluation store. The Attribution-Record references the Evaluation Record by evaluation_id; the full Evaluation Record is retrievable out-of-band via the governance platform's evaluation lookup endpoint. An audit trail without Evaluation-IDs records what happened but cannot prove that a governance evaluation occurred. Under the EU AI Act and similar regimes, the absence of an Evaluation-ID for a high-risk action is itself a compliance failure.

Decision-ID Decision-ID captures the governance verdict specifically. The Evaluation-ID covers the full evaluation process; the Decision-ID is the output of that process. Decision-ID MUST be:

Minted by the governance system at the moment the verdict is produced.
A UUIDv7 or ULID.
Carried as the decision_id field in the extended Attribution-Record.
Linked to the Evaluation-ID that produced it via the evaluation_id field in the Decision Record.

Decision Record The Decision Record is held by the governance platform that produced the verdict. The Decision Record SHALL contain:

decision_id (this identifier).
evaluation_id (the evaluation that produced this decision).
verdict (one of permit, deny, permit-with-conditions, defer).
reasoning (a structured record of the reasoning that produced the verdict, in a format the governance platform defines).
conditions (when verdict is permit-with-conditions, the conditions under which the permit applies).
timestamp (RFC 3339 timestamp of verdict issuance).
valid_until (RFC 3339 timestamp after which the decision MUST be re-evaluated; absent for one-shot decisions).

The Decision Record is signed by the governance platform's key and stored in the governance platform's decision store. As with Evaluation Records, the Attribution-Record references the Decision Record by decision_id; the full record is retrievable out-of-band. The Decision-ID makes the verdict independently auditable. A regulator or attorney requesting the governance decision for a specific action MUST be able to retrieve the Decision-ID and read the full reasoning record that produced it.

Separation of Evaluation and Decision Evaluation-ID and Decision-ID are separate identifiers because the two concepts are auditable separately. A regulator may ask "show me the inputs to the evaluation" (Evaluation Record) or "show me the verdict and the reasoning" (Decision Record). The governance platform MAY produce multiple Decision Records from a single Evaluation Record (for example, when a deferred decision is later resolved); each Decision Record references the same Evaluation-ID via the evaluation_id field.

Audit Identifier and the Attribution-Record Chain

Audit-ID Audit-ID is the cryptographic hash of the canonical extended Attribution-Record. It is the identifier of a single audit record and the chain anchor that links the record to the agent's preceding audit record. Audit-ID MUST be:

A 256-bit value rendered as 64 lowercase hexadecimal characters.
Computed as the SHA-256 hash of the canonical extended Attribution-Record JWS, per .
Carried on the wire as the Audit-ID response header on every response that carries an Attribution-Record.
Included as the previous_audit_id field in the agent's next emitted Attribution-Record, completing the chain link.

Extension to the Base Attribution-Record The base Attribution-Record envelope defined by is a JWS-signed token carrying server identity, response timestamp, request hash, and response status. This document extends the Attribution-Record payload with the identifier-chain fields. The extension is additive: existing Attribution-Record consumers remain conformant, and the JWS signature continues to cover the full extended payload. The extended Attribution-Record payload contains the following identifier-chain fields: Identifier-Chain Fields in the Extended Attribution-Record

Field	Type	Required	Description
`agent_id`	string	MUST	Acting agent's 64-hex Agent-ID
`owner_id`	string	MUST	Owner identifier per
`session_id`	string	conditional	Present when the request carried Session-ID
`task_id`	string	conditional	Present when the request carried Task-ID
`request_id`	string	MUST	Request-ID of the request being responded to
`response_id`	string	MUST	Response-ID of this response
`action_id`	string	conditional	Present for action-recording methods
`evaluation_id`	string	conditional	Present when governance evaluation occurred
`decision_id`	string	conditional	Present when governance decision was rendered
`previous_audit_id`	string	MUST	The agent's preceding Audit-ID, or 64 zeros for the first record
`audit_record_version`	string	MUST	This document's version: `"1"`
`requested_method`	string	conditional	The method as it arrived on the wire when alias resolution per translated it to a different canonical method before dispatch. Present only when an alias was resolved; absent when the request method was already canonical. Allows audit consumers to distinguish "BOOK arrived under that name" from "GET arrived and was aliased to FETCH."
`log_inclusion`	object	conditional	Reference to this record's inclusion in a transparency log per : log identifier, leaf index, and inclusion proof or a URI to it. Present when the deployment requires tamper evidence against the recording agent ().
`delegation_sequence_digest`	string	conditional	SHA-256 of the verified `Delegation-Chain` header value, 64 lowercase hex. Present when the request carried the header. Binds this record to the pre-authorization sequence per .
`principal_id`	string	conditional	Identifier of the human or service principal on whose behalf the agent acted, lifted from a validated external-IdP credential per the OAuth composition section in . Set when the server is configured to validate external credentials and the validator succeeded; the specific claim lifted is operator-configured (typically `sub` for OIDC). Absent when the request carried no external credential, when the server lacked configuration to validate one, or when validation produced no lifted claim. Distinct from `owner_id` (which identifies the agent's principal as recorded on the Agent Genesis) and from the Agent-ID: this field identifies the principal who delegated this specific request to the agent.
`synthesis_id`	string	conditional	Present when the action was dispatched under a synthesized contract (RCNS-spawned or PROPOSE-spawned). Opaque identifier of the contract per .
`contract_hash`	string	conditional	Present when the action was dispatched under a synthesized contract. SHA-256 of the canonical contract definition, 64 lowercase hex characters. Stable across all invocations of the same contract.
`negotiation_origin`	string	conditional	Present when the action was dispatched under a synthesized contract. One of `rcns-gate`, `propose`, or `pre-registered`.

These fields coexist with merchant-specific fields specified by (merchant_id, merchant_fingerprint, intent_assertion_jti), with the base Attribution-Record fields from , and with any other companion-draft extensions to the Attribution-Record payload.

Audit-ID Construction The Audit-ID is computed as follows:

The responding agent assembles the extended Attribution-Record payload as a JSON object containing the base AGTP fields, the identifier-chain fields from , and any other companion-draft extensions applicable to the response.
The payload is signed using the responding agent's manifest signing key per . The result is the JWS that the Attribution-Record response header carries.
The Audit-ID is computed as audit_id = sha256(jws_compact_serialization), where jws_compact_serialization is the full JWS compact form (header.payload.signature, base64url-encoded per ).
The responding agent stores the Audit-ID in its local audit store, indexed by agent_id and ordered by emission time. The same Audit-ID becomes the previous_audit_id value in the agent's next emitted Attribution-Record.

The hash covers the full signed JWS, including signature and protected header; the JSON payload alone is insufficient. This ensures that any modification of the signature, the protected header, or the payload invalidates the Audit-ID.

Unsigned Fallback (alg: none) A responding agent that has yet to provision a manifest signing key MAY emit Attribution-Records with alg: none in the JWS protected header and an empty signature octet, per Section 4.1.1. The Audit-ID is still computed as sha256(jws_compact_serialization) over the full unsigned compact form, and the per-agent chain is maintained: the next record carries this Audit-ID in its previous_audit_id field exactly as it would for a signed record. The unsigned fallback preserves wire format and chain construction during development and transition. It carries no anti-forgery claim. Verifiers and audit-trail consumers MUST treat alg: none records as unverified per the Attribution Forgery mitigation in . An agent that emits alg: none records once and signed records later produces a chain in which the unsigned prefix is hash-linked to the signed continuation; verifiers can audit the signed portion without re-evaluating the unsigned prefix, and the chain itself remains intact. Production deployments MUST configure a manifest signing key. The unsigned fallback is NOT a long-term mode.

The Per-Agent Hash Chain Each agent maintains a hash chain over its own emitted Attribution-Records. The chain has the following properties:

The chain head is the first Attribution-Record the agent ever emits. Its previous_audit_id is 64 hex zeros.
Each subsequent Attribution-Record carries the Audit-ID of the immediately preceding Attribution-Record this agent emitted in its previous_audit_id field.
Tampering with any record in the chain invalidates the previous_audit_id chain link for every record that follows it, and invalidates the JWS signature on the tampered record.

The chain is scoped per agent. An agent's chain is independent of any other agent's chain. A verifier reconstructing one agent's actions follows only that agent's chain. The agent is responsible for maintaining chain integrity. An agent that emits an Attribution-Record without setting previous_audit_id correctly produces a chain break and SHALL have its Tier 1 verification status revoked per .

Cross-Agent Chain Linkage A single action sometimes references actions taken by other agents. A delegation chain in which Agent C delegates to Agent A, which delegates to Agent B, produces three distinct per-agent chains. Each agent maintains its own chain; cross-agent references link them where required. When the action recorded in an Attribution-Record depends on or continues an action recorded by a different agent, the extended Attribution-Record MUST include a prior_actions array. Each entry is a tuple of the form: ", "audit_id": "<64 hex>", "agent_uri": "" } ]]> The agent_uri field is OPTIONAL but RECOMMENDED. When present, it carries the AGTP URI at which the referenced agent's audit store was addressable at the time the recording agent emitted the Attribution-Record (typically the URI the recording agent just invoked to obtain the upstream Audit-ID). A verifier that walks prior_actions SHOULD prefer the inline agent_uri over any locally-cached agent location, since the recording agent authored the URI with first-hand knowledge of where the upstream agent lived at the time of the interaction; locally-cached locations may have drifted out of date. A verifier traversing the chain MAY use prior_actions entries to walk into other agents' chains. Resolution of a prior_actions entry uses the standard Agent-ID resolution path when agent_uri is absent: Agent-ID resolves to the Agent Genesis per , the Genesis names the governance platform that issued it, and the Audit-ID is retrievable from that platform's audit infrastructure for that agent. When agent_uri is present, the verifier MAY use it directly and skip the resolution step. The standardized retrieval interface, regardless of how the verifier located the agent's audit store, is the INSPECT method specified in : a verifier invokes INSPECT target=audit audit_id={audit_id} on the referenced agent's server. Multiple entries with the same (agent_id, audit_id) pair MAY appear in the array when the recording agent's action depended on the same upstream action through multiple intermediate agents; verifiers MUST treat duplicate entries as references to a single upstream node (diamond convergence) and MUST NOT double-count traversal steps. The combination of per-agent chains and prior_actions references produces a verifiable global graph of action provenance. A regulator examining an incident MAY traverse the graph from any terminal Audit-ID back to the originating Agent Genesis through as many agents as the action involved.

Relationship to the Delegation Sequence AGTP specifies delegation on two sides of execution, and this document carries one of them. The pre-authorization side is the Delegation Sequence of : the ordered DELEGATE hops carried in the Delegation-Chain header, verified before the request is accepted, establishing that the requesting agent holds authority narrowed from an origin through every hop. The post-execution side is the prior_actions chain specified here: the signed references from a recording agent's Attribution-Record to the upstream Audit-IDs its action depended on, verified after the fact, establishing who caused what. The sequence and the record compose and are checked against each other. When a request carried a Delegation-Chain, the Attribution-Record its response produces MUST carry delegation_sequence_digest: the SHA-256 of the Delegation-Chain header value as verified. A verifier that holds both can confirm that the agents named in prior_actions for a delegated action are the agents the Delegation Sequence named, in the same order, and that no agent acted that the sequence had yet to authorize. The pre-authorization row is stated by ; the post-execution row is stated by this document; a relying party reading either one knows which it is reading.

Field Population Rules The following fields MAY be absent under specific conditions:

evaluation_id and decision_id MAY be absent for actions taken under standing authorization (a previously issued permit-with-conditions decision still within its valid_until window). In that case the extended Attribution-Record MUST include a standing_authorization_decision_id field pointing to the Decision-ID that authorized the action.
action_id MAY be absent for cognitive methods that never record actions, as specified in .
session_id MAY be absent when the request was outside any session.
task_id MAY be absent when the request was outside any multi-request task.
All other fields MUST be present. A field that MUST be present but is absent constitutes a chain break.

Verification Procedure Verification is a function of a fixed input set: the terminal Audit-ID, the Attribution-Records and lifecycle records fetched for the chain, the Identity Documents resolved for the agents named, and the verification time. A verifier applies no local policy inside the procedure; the relying party applies its policy to the result. The procedure has three outcomes: intact when every step passes; broken when a step fails on an input the verifier holds (); and indeterminate when a step cannot run because an input is unavailable (an audit store that fails to answer, an Identity Document that fails to resolve, a log inclusion proof that cannot be fetched). An indeterminate chain is never reported as intact and never as broken; the verifier names the missing input and the relying party decides. A verifier reconstructs the chain by:

Retrieving the terminal Audit-ID from the agent's audit store or from a counterparty's record of the Attribution-Record it received.
Fetching the full Attribution-Record JWS and verifying its hash matches the Audit-ID.
Verifying the JWS signature against the responding agent's agent_public_key as published in its Identity Document at the time of the record (), per . A record signed under a key the document has since rotated away from remains verifiable against the document version current at the record's timestamp, which the issuer retains per .
Following previous_audit_id backwards through the agent's chain, verifying each hash and each signature, until the chain head is reached.
When the Attribution-Record carries a prior_actions array, resolving each {agent_id, audit_id} tuple via the standard Agent-ID resolution path and verifying the referenced Attribution-Record by the same procedure recursively.
For each Attribution-Record, retrieving the referenced Evaluation Record and Decision Record from the governance platform and verifying each is signed by the appropriate governance platform key.
Confirming the Agent-ID resolves to a valid Agent Genesis per , that the owner_id recorded on the Attribution-Record matches the Genesis's owner_id field, and that the agent's identity state at the time of each Attribution-Record was consistent with the action recorded (the agent was in the active state at the time of action).
Confirming all timestamps are monotonically consistent (Request-ID timestamp precedes Response-ID timestamp, which precedes or is concurrent with Action-ID timestamp, with Evaluation and Decision timestamps before Action-ID).

A verification failure at any step on an input the verifier holds is a chain break and invalidates the audit value of the record. A step that cannot run yields an indeterminate outcome for the record and every record downstream of it.

Tamper Evidence Against the Recording Agent The per-agent chain is produced and held by the agent whose actions it records. Against a verifier that trusts that agent's key, the signature on each record and the hash linkage between records are sufficient: a modified record changes its Audit-ID and breaks the chain at that point. Against a verifier that distrusts the holder, they are insufficient, because the holder could re-sign a modified history from the chain head back and present it as original. The sharper form of the audit question, how a self-held record is made tamper-evident to a party that distrusts the holder, has an answer in this family, and this revision states it. The answer is inclusion in a transparency log the holder cannot rewrite. A deployment that requires tamper evidence against the recording agent MUST submit each Audit-ID (or a periodic chain head, at an interval the deployment states) to a transparency log per , aligned with RFC 9162 and RFC 9943 (SCITT), and MUST carry the inclusion proof reference in the extended Attribution-Record's log_inclusion field. A verifier that distrusts the holder checks the inclusion proof before trusting the record; a record whose inclusion proof fails is broken, and one whose log cannot be reached is indeterminate. A deployment that omits log inclusion is conformant and its records are tamper-evident only to verifiers that trust the holder; the verifier MUST say which case applies when reporting a chain as intact.

Composition with the Session Root specifies a session root: a rolling SHA-256 commitment both participants in a session fold independently over the Audit-IDs of the session's responses. The per-agent chain of this document is one agent's record of its own actions; the session root is two agents' agreement about what a session carried. They compose directly, since the session root is folded over Audit-IDs this document defines: a verifier holding a session's final root and its Audit-IDs can confirm the root by refolding and then verify each Audit-ID's record by the procedure above. A session root that fails to refold from the Audit-IDs the chain contains is evidence that one participant's record diverges from the other's, which is a chain break on whichever side's records fail to verify.

Wire Format The identifier chain materializes on the wire as a small set of new request and response headers and as extensions to the existing Attribution-Record envelope. Headers defined by other AGTP drafts (Agent-ID, Owner-ID, Session-ID, Task-ID, Server-ID, Attribution-Record) are referenced by this document and defined in theirs.

New Headers Defined by This Document New Headers Defined by AGTP-IDENTIFIERS

Header	Carried On	Required	Value
Request-ID	request	MUST	UUIDv7 or ULID per
Request-ID	response	SHOULD	Echo of the originating request's Request-ID
Response-ID	response	MUST	UUIDv7 or ULID per
Audit-ID	response	MUST when Attribution-Record present	64 lowercase hex per
Action-ID	response	MAY	UUIDv7 or ULID; convenience echo of the `action_id` field in the Attribution-Record payload

Owner-ID is a field of the Agent Genesis and the Identity Document; earlier revisions of this document registered it as a request header, which retired. Action-ID, Evaluation-ID, and Decision-ID are primarily carried as fields inside the extended Attribution-Record payload; none of the three is a standalone wire header. The Action-ID MAY appear as a convenience header on the response for clients that need to reference it without parsing the JWS.

ABNF Grammar The header values follow this grammar: A header value that fails to conform to this grammar SHALL be treated as malformed and the request or response SHALL be refused with status 400 Bad Request.

Echo Rules The responding agent SHOULD echo the request's Request-ID unchanged in the response. This follows the echo convention uses for Task-ID and Agent-ID, and avoids introducing a separate correlation header. The host that processed the request is named in Server-ID per ; Server-ID is a host identifier and identifies no agent. The canonical Agent-ID of the agent that produced the response is recorded in the agent_id field of the Attribution-Record payload. The responder's per-interaction identifier is carried in Response-ID. A response that omits Request-ID when responding to a request that carried Request-ID produces an audit chain that cannot be reconstructed without out-of-band correlation, and SHOULD be treated as a chain break by infrastructure relying on the identifier chain for accountability.

Identifier Resolution and Lookup

Resolution Targets Each identifier resolves to a specific record. The resolution target and store are summarized below. Identifier Resolution Targets

Identifier	Resolves To	Store
Agent-ID	Agent Identity Document	Governance platform registry; AGTP-LOG for lifecycle events
Owner-ID	Owner Identity Document	Governance platform
Session-ID	Session Context	Session participants and governance platform per
Task-ID	Task Context	Operator-defined
Request-ID	(no separate record; appears in Attribution-Record)	Caller's outbound log; responder's Attribution-Record
Response-ID	(no separate record; appears in Attribution-Record)	Responder's Attribution-Record
Action-ID	Extended Attribution-Record	Responding agent's audit store
Evaluation-ID	Evaluation Record	Governance platform's evaluation store
Decision-ID	Decision Record	Governance platform's decision store
Audit-ID	Extended Attribution-Record JWS	Responding agent's audit store; counterparty's received-record store

Lookup Methods The default lookup method is the responding agent's audit store, which MUST be addressable by Audit-ID. The standardized AGTP lookup interface is the INSPECT method specified in : a relying party invokes INSPECT target=audit audit_id={hex} on the agent's server and receives the JWS Compact serialization of the stored Attribution-Record. The relying party MUST recompute sha256(jws) and confirm it equals the requested audit_id before trusting the parsed payload. INSPECT also supports target=chain_head (returns the most recently emitted Audit-ID for a named Agent-ID, useful for chain walkers needing a starting point) and target=lifecycle (returns recent lifecycle log entries for a named Agent-ID). Implementations MAY additionally expose a REST endpoint over HTTPS or rely on out-of-band retrieval; the INSPECT method is the protocol-level interface and the recommended default. Evaluation Records and Decision Records are stored by the governance platform that produced them. Lookup is via the governance platform's evaluation and decision endpoints (out of scope for this document; defined by the governance platform). Agent-ID and Owner-ID resolve via the mechanisms defined in . Identity-lifecycle events for Agent-ID are stored in the AGTP-LOG transparency log per ; the lookup is via the AGTP-LOG protocol.

Caching Persistent identifiers (Agent-ID, Owner-ID) MAY be cached indefinitely by infrastructure components, refreshing on revocation signals from the AGTP-LOG transparency log. Per-interaction and governance identifiers SHOULD be cached only for the duration of the operation that references them. Caching beyond the immediate operation is an operator policy concern and is out of scope for this document.

Security Considerations

Identifier Forgery The primary threat is forgery of any identifier in the chain. The chain is resistant to forgery because:

Agent-ID is the hash of a signed Agent Genesis document. Forging Agent-ID requires forging the Genesis signature.
Owner-ID is bound to Agent-ID via the Genesis signature. Forging Owner-ID requires forging Agent-ID.
Per-interaction identifiers (Request-ID, Response-ID, Action-ID) are committed inside the JWS-signed extended Attribution-Record. Forging an after-the-fact identifier requires forging the JWS signature.
Governance identifiers (Evaluation-ID, Decision-ID) are referenced inside the JWS-signed Attribution-Record and produced by the governance platform's signed records. Forging requires compromising the governance platform's key or forging the JWS.
Audit-ID is the SHA-256 hash of the canonical JWS. Forging Audit-ID requires producing a colliding JWS, which is computationally infeasible.

A verifier that retrieves an identifier from a source other than the responding agent's audit store or a signed Attribution-Record SHALL treat the identifier as unverified until the originating record is retrieved and the signature confirmed.

Chain Breaks A chain break is the condition in which an identifier in the chain cannot be linked to its predecessor. Chain breaks are caused by:

Omission (the predecessor identifier was never minted).
Tampering (the predecessor identifier was modified after issuance).
Substitution (a different identifier was inserted in place of the original).

All three conditions MUST be treated as evidence of forgery or omission. The audit record SHALL NOT be relied upon for regulatory examination or counterparty dispute.

Replay An attacker that captures an extended Attribution-Record MAY attempt to replay it as if it were a new action. The chain resists replay because:

The Attribution-Record carries a timestamp inside the signed payload. Replay produces a stale timestamp that verifiers can reject.
The previous_audit_id field commits to a specific predecessor. A replayed record carries the same previous_audit_id as its original, which cannot match the current chain head when the chain has progressed.
The Audit-ID is deterministic over the JWS. A replayed Attribution-Record produces the same Audit-ID as its original, which the responding agent's audit store rejects as a duplicate.

The responding agent MUST enforce strict append-only semantics on its audit store. An audit store that permits insertion or modification of past entries undermines the replay resistance of the chain.

Agent Compromise If the responding agent's manifest signing key is compromised, an attacker can produce valid-looking Attribution-Records under that agent's identity. The chain provides no protection against this case; the threat is mitigated at the layer by issuing a agent-genesis-revoked event that retires the compromised agent. A verifier that finds an agent-genesis-revoked event for an Agent-ID SHOULD treat all Attribution-Records emitted under that Agent-ID after the revocation timestamp as suspect. Attribution-Records emitted before revocation remain valid; they were emitted by the agent in good standing at the time.

Privacy Identifiers themselves carry no payload data. However, the records they resolve to MAY contain personally identifiable information (particularly in Evaluation Records, where inputs may include user-submitted content). The governance platform that issues an identifier is responsible for the privacy of the record it resolves to. Specifically:

Owner-ID records MAY identify a natural person and MUST be treated as personal data under applicable law (GDPR, CCPA, and similar regimes).
Evaluation Records' inputs field SHOULD be redacted to remove PII before the record is committed to the evaluation store. The governance platform MAY retain the unredacted form under separate access controls.
Request-IDs and Response-IDs themselves are impersonal data; the payloads they reference MAY be.

A verifier with regulatory authority MAY request the unredacted form via the governance platform's out-of-band access procedure. A verifier without such authority is bound by the redacted form.

Identifier Reuse An identifier issued under one Agent-ID SHALL NOT be reused under a different Agent-ID. The collision-resistant identifier schemes (UUIDv7, ULID, SHA-256) make this statistically improbable. Governance platforms MUST enforce this constraint during identifier issuance.

Privacy Considerations The identifier chain produces a complete record of an agent's actions, indexed by Agent-ID and Owner-ID. This is by design: the chain is the audit record. However, the design has privacy consequences that implementers MUST consider.

Linkability The chain links every action an agent takes to a single Agent-ID, which in turn links to a single Owner-ID. An adversary with access to a responding agent's audit store or to multiple Attribution-Records emitted by the same agent can construct a behavioral profile. Mitigations:

Sensitive Owner-IDs (those identifying natural persons) MAY be pseudonymized at the governance platform. The platform retains the binding between pseudonym and natural person under separate access controls.
An owner that requires unlinkability across agent activities MAY provision multiple Agent-IDs under separate Owner-IDs. The governance platform MAY support this directly via the Owner Identity Document.

Right to Erasure GDPR Article 17 and similar provisions establish a right to erasure of personal data. The append-only nature of the agent's audit store creates tension with this right. A governance platform that operates in a jurisdiction with a right to erasure MUST implement one of:

A redaction mechanism that nulls the personal data fields in audit entries without removing the entries themselves, preserving the chain.
A revocation mechanism that marks the Owner-ID as revoked and prevents future linkage, preserving the chain for past entries under restricted access.

The specific mechanism is out of scope for this document.

Regulatory Mapping The identifier chain is designed to satisfy the record-keeping requirements of major AI regulatory regimes. This section is informative.

EU AI Act The EU AI Act requires that high-risk AI systems maintain records sufficient to reconstruct decisions. The chain satisfies this through:

Agent-ID and Owner-ID identify the actor and the accountable principal.
Evaluation-ID and Decision-ID record the governance evaluation and verdict required by Article 12 (logging) and Article 14 (human oversight).
Audit-ID provides the tamper-evident binding required by Article 20 (record-keeping) and Article 26 (deployer obligations).

A high-risk AI system that maintains the AGTP identifier chain maintains the records the EU AI Act requires.

SOC 2 and ISO 42001 SOC 2 Type II audits require evidence that controls operate effectively over time. ISO 42001 requires a management system for AI with comparable evidentiary requirements. The chain provides this evidence through cryptographically verifiable records of:

Who acted (Agent-ID, Owner-ID).
What authorized the action (Evaluation-ID, Decision-ID).
What action was taken (Action-ID).
When and in what order (timestamps and previous_audit_id).

IANA Considerations This document requests the following IANA actions.

AGTP Header Field Registry Additions Registration of the following entries in the AGTP Header Field Registry (established by ):

Header	Carried On	Required
Request-ID	request	MUST
Request-ID	response	SHOULD (echo)
Response-ID	response	MUST
Audit-ID	response	MUST with Attribution-Record
Action-ID	response	MAY

AGTP Attribution-Record Field Registry Establishment of an IANA registry: AGTP Attribution-Record Fields, with initial registrations for the identifier-chain fields specified in this document (), the merchant-identity fields specified in , and the base fields specified in .

Registration Procedure: Specification Required

The following fields are added by this revision to the registry above: delegation_sequence_digest () and log_inclusion ().

AGTP Verdict Registry Establishment of an IANA registry: AGTP Decision Verdicts, with initial registrations for permit, deny, permit-with-conditions, and defer.

Registration Procedure: Specification Required

AGTP Identifier Scheme Registry Establishment of an IANA registry: AGTP Identifier Schemes, with initial registrations for uuidv7, ulid, sha256, and the id_scheme values recognized for Owner-ID.

Registration Procedure: Specification Required

Open Items The following items are out of scope for this revision and are anticipated in future revisions:

Contract ID specification. Evaluation Records reference a contract_id (the governance contract or policy in effect at the time of evaluation). The contract ID scheme is referenced here and defined in .
Concrete redaction format for inputs in Evaluation Records.
The Owner Identity Document format. This document specifies what Owner-ID resolves to; the document structure is still open.
Cross-agent audit chain federation protocol. The wire format for prior_actions references in the Attribution-Record payload is specified; the federation protocol by which governance platforms reconcile cross-agent chains and serve remote audit lookups remains to be defined.
Standing authorization expiry and re-evaluation triggers.
Identifier scheme migration. The current document permits UUIDv7 and ULID for per-interaction and governance identifiers. A future revision may add or constrain schemes.
The interval at which a deployment requiring tamper evidence submits chain heads to the transparency log, and whether the interval belongs in the Identity Document so a verifier can know it.

Changes from v02 Version 03 aligns this document with AGTP v10 and answers two questions raised in review.

Owner-ID is a document field. v02 registered Owner-ID as a MUST request header. retired the header in v09 and records the Owner-ID in the Agent Genesis and the Agent Identity Document, resolved from the Agent-ID. The header row is removed from the wire format and the IANA registration; the Owner-ID section, the family relationship, and the verification procedure now read it from the verified document. The open item on reconciling Principal-ID and Owner-ID is closed.
Delegation split stated. A new subsection () states that the pre-authorization Delegation Sequence of and the post-execution prior_actions chain of this document are the two sides of delegation, and adds delegation_sequence_digest to the extended Attribution-Record so a verifier can check one against the other.
Tamper evidence against the recording agent. A new subsection () states the mechanism for a verifier that distrusts the holder: inclusion in a transparency log per , carried as log_inclusion, required where the deployment needs it and declared when absent. This answers the question put on the agentproto and WIMSE lists about self-held records.
Verification outcomes. The procedure is defined over a fixed input set with no local policy and returns intact, broken, or indeterminate (); step 3 verifies against the agent's agent_public_key of the Identity Document version current at the record's time.
Session root composition () with the session root of .
References: base to draft-hood-independent-agtp-10; AGTP-API replaced by AGTP-METHODS and AGTP-RCNS; AGTP-IDDOC added; AGTP-TRUST, AGTP-SESSION, and AGTP-CERT to current revisions. TLS-layer wording; house style pass.

Wire format compatibility: removing the Owner-ID header registration matches what already specifies, so no conformant v10 implementation changes. delegation_sequence_digest and log_inclusion are additive and conditional.

Changes from v01 Version 02 is a naming-consistency revision. The identifier stack and all underlying semantics are unchanged. One Attribution-Record field is renamed:

The acting_principal_id field on extended Attribution-Records is renamed to principal_id. The acting_ qualifier is implicit: the field always carries the principal who delegated a specific request to the agent, distinct from owner_id (the permanent principal on the Agent Genesis). The shorter name aligns with the wire and certificate naming conventions used elsewhere in the identifier chain; the semantics, the conditional presence rules, and the relationship to external-IdP composition are unchanged.

No semantic changes. Implementations on v01 migrate to v02 by renaming the field key on emitted Attribution-Records; the field value and lifting rules are unchanged.

Changes from v00 Version 01 is a drift-cleanup revision. The identifier stack is unchanged; corrections align spec wording with the deployed Agent-ID echo behavior documented in v08.

Substantive Changes The following substantive changes were made:

Agent-ID echo on responses corrected. The Agent-ID section () previously stated that responses carry the responding agent's identity in the Server-ID header in place of echoing the requester's Agent-ID. This was wrong on two counts: Server-ID is a host identifier and identifies no agent, and responses do echo the request's Agent-ID per . The corrected text states that responses SHOULD echo Agent-ID, that Server-ID names the host that processed the request, and that the canonical Agent-ID of the agent that produced the response is recorded in the agent_id field of the Attribution-Record payload.
Echo Rules section corrected. The same Server-ID-as- responder-identity confusion appeared in the Echo Rules section under Request-ID and has been corrected with parallel wording. The Request-ID echo guidance is unchanged in substance; only the surrounding identity framing has been fixed.
alg: none fallback documented. The Audit-ID Construction section () now includes an Unsigned Fallback subsection covering the case where a responding agent has yet to provision a manifest signing key. The fallback emits a JWS with alg: none per Section 4.1.1; the Audit-ID is still computed and the chain is still maintained. The fallback carries no anti-forgery claim and is bounded to development and transition deployments. Verifiers MUST treat alg: none records as unverified. This documents behavior already deployed in v07- conformant implementations and matches the corresponding tightening in v08.
INSPECT named as the standardized Audit-ID lookup interface. The Lookup Methods section is updated to specify the INSPECT method defined in v08 as the standardized AGTP lookup interface for Audit-IDs. A relying party that holds an Audit-ID invokes INSPECT target=audit audit_id={hex} on the responding agent's server and receives the JWS Compact serialization of the stored Attribution-Record. INSPECT additionally supports target=chain_head and target=lifecycle for chain walkers and lifecycle auditors. The earlier text that left lookup operator-defined and out of scope is superseded; HTTPS REST endpoints and out-of-band retrieval remain permitted as additional surfaces. The AGTP-MERCHANT informative seriesinfo is also updated to v02 to track the unification of merchant identity onto the Agent Identity Document.
prior_actions entries gain optional agent_uri. The schema for each prior_actions array entry is extended with an OPTIONAL but RECOMMENDED agent_uri field carrying the AGTP URI at which the referenced agent's audit store was addressable at the time the recording agent emitted the Attribution-Record. Verifiers SHOULD prefer the inline agent_uri over locally-cached agent locations on grounds that the recording agent authored the URI with first-hand knowledge of the upstream agent's location. The retrieval interface, regardless of how the agent is located, is INSPECT per entry #4. Cross-agent walkers MAY encounter diamond convergence (multiple prior_actions entries referencing the same (agent_id, audit_id) pair); verifiers MUST treat duplicates as references to a single upstream node and MUST NOT double-count traversal steps. This documents the cross-agent BFS walker shape that deployed chain inspectors have shipped.
Extended Attribution-Record gains four conditional companion-draft fields. The Identifier-Chain Fields table is extended with four new entries: requested_method (set when method-alias resolution per translated the wire method to a canonical method before dispatch); synthesis_id, contract_hash, and negotiation_origin (set when the action was dispatched under a synthesized contract (RCNS-spawned or PROPOSE-spawned) per the RCNS Attribution-Record extension fields in ). All four fields are conditional; absence is itself diagnostic. The base schema (audit_record_version, previous_audit_id, chain semantics) is unchanged.
principal_id field added for external-IdP composition. The Identifier-Chain Fields table is extended with principal_id, a conditional string field carrying the identifier of the principal on whose behalf the agent acted, lifted from a validated external-IdP credential (typically the OIDC sub claim) per the Composition with External Identity Providers section in . The field is distinct from owner_id (which identifies the agent's permanent principal on the Agent Genesis) and from the Agent-ID: it identifies the per-request acting principal, a different party from the agent itself and from its owner. Verifiers walking the chain SHOULD consider principal_id (when present) when reconstructing on-whose-behalf semantics. The raw credential the claim was lifted from MUST NOT appear on the Attribution-Record; only the validated claim does.

Wire Format Compatibility None. The corrections are editorial: they align this document's wording with the behavior already specified in and deployed by v07-conformant implementations.

Acknowledgments The identifier stack model was developed during the AGTP v07 revision cycle. Several reviewers and adjacent working groups shaped the architecture this document records. Scott Courtney (GoDaddy / ANS) provided early review on the identity model and surfaced concerns about dual-logging between identity-lifecycle and per-action audit records that ultimately drove the architectural separation between and the per-agent Attribution-Record chain defined here. Philip Griffiths (Cloud Security Alliance ZTCPP / ONUG AOMC) contributed feedback on zero-trust alignment that informed the verification procedure and chain-break framing. The IETF WIMSE working group's engagement on draft-klrc-aiagent-auth shaped the framing of agent-to-agent authentication boundaries that this document's per-interaction identifiers sit alongside. The authors of klrc-aiagent-auth (Pieter Kasselman, Jeff Lombardo, Yaroslav Rosomakho, Brian Campbell, Nick Steele) defined the adjacent problem space. The chain-of-custody framing draws on prior work in transparency logs (, ) and on the attestation model of . The Attribution-Record envelope on which this document builds is defined in . The regulatory mapping was informed by the record-keeping requirements of .