AGTP Identifier Chain

1.1. 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 rather than a reconstruction.¶

The accountability gap matters in three settings:¶

• Regulatory examination under frameworks such as the EU AI Act [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 rather than as application-level metadata.¶

1.2. A Layered Model Over Existing Primitives

The identifiers defined by this document are not new inventions. The AGTP draft family already provides most of them. Agent-ID is defined in [AGTP] and derived from the Agent Genesis per [AGTP-LOG]. Owner-ID resolves to the principal recorded in the Agent Genesis. Session-ID is defined in [AGTP] and given session semantics by [AGTP-SESSION]. Task-ID is defined in [AGTP] for workflow correlation. The Attribution-Record envelope is defined in [AGTP] 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 does not yet 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 does not introduce a new transparency log. The identity-lifecycle transparency log defined in [AGTP-LOG] records Agent Genesis issuance and lifecycle events; this document operates against the per-response Attribution-Record envelope of [AGTP]. The two are complementary records of different concerns.¶

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

1.4. Relationship to the AGTP Draft Family

This document is the connective specification across the AGTP draft family. It does not replace any existing draft.¶

• [AGTP] provides the Attribution-Record envelope, the Agent-ID, Session-ID, and Task-ID headers, and the manifest signing infrastructure on which Attribution-Records are signed.¶

• [AGTP-TRUST] 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.¶

• [AGTP-LOG] 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, but Audit-IDs themselves are not committed to the AGTP-LOG transparency log.¶

• [AGTP-CERT] carries the Agent-ID in the subject-agent-id X.509 v3 extension. The Agent Certificate's TLS binding makes the wire identity verifiable at the transport layer.¶

• [AGTP-MERCHANT] 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.¶

• [AGTP-SESSION] introduces ESTABLISH semantics for Session-ID. This document treats Session-ID as a context identifier within the chain.¶

1.5. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

4.1. 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 [AGTP-LOG]. Agent-ID is permanent for the operational lifetime of the agent; revocation produces a revoked state in the registry but does not retire or reissue the identifier.¶

Agent-ID MUST be:¶

• Derived from the Agent Genesis via the procedure specified in [AGTP-LOG]: 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 [AGTP]. Responses carry the responding agent's identity in the Server-ID header rather than echoing the requester's Agent-ID.¶

• Resolvable to an Agent Identity Document by any AGTP-aware infrastructure component, via the resolution mechanics specified in [AGTP].¶

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

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

• Carried in the Owner-ID request header on every AGTP request, alongside the Agent-ID header.¶

• 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 [AGTP-TRUST], regardless of any other trust signals it carries.¶

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

5.1. 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 [AGTP] and given establishment semantics by [AGTP-SESSION].¶

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 [AGTP-SESSION].¶

• 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 not itself an action; it is the context within which actions occur.¶

5.2. 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 [AGTP].¶

For the purposes of the identifier chain:¶

• Task-ID MAY be absent. Many actions are not part of a multi-request task.¶

• When present, Task-ID MUST be carried on every request and response that participates in the task, per [AGTP].¶

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

6.1. 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 [RFC9562] 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, not 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 not what initiated it.¶

6.2. 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 [AGTP] 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.¶

6.3. 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 (but not limited to) EXECUTE, DELEGATE, ESCALATE, CONFIRM, SUSPEND, PURCHASE, and the identity-lifecycle methods that trigger AGTP-LOG events (ACTIVATE, REVOKE, REINSTATE, DEPRECATE per [AGTP-LOG]). 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.¶

7.1. 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 Section 7.1.1 that captures the inputs evaluated, the dimensional scores computed, the confidence level, and the verdict produced.¶

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

8.1. 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 Section 8.3.¶

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

8.2. Extension to the Base Attribution-Record

The base Attribution-Record envelope defined by [AGTP] 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:¶

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

8.3. Audit-ID Construction

The Audit-ID is computed as follows:¶

1. The responding agent assembles the extended Attribution-Record payload as a JSON object containing the base AGTP fields, the identifier-chain fields from Table 1, and any other companion-draft extensions applicable to the response.¶

2. The payload is signed using the responding agent's manifest signing key per [AGTP]. The result is the JWS that the Attribution-Record response header carries.¶

3. 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 [RFC7515]).¶

4. 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, not the JSON payload. This ensures that any modification of the signature, the protected header, or the payload invalidates the Audit-ID.¶

8.4. 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 [AGTP-TRUST].¶

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

{
  "agent_id": "<64 hex>",
  "audit_id": "<64 hex>"
}

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: Agent-ID resolves to the Agent Genesis per [AGTP-LOG], the Genesis names the governance platform that issued it, and the Audit-ID is retrievable from that platform's audit infrastructure for that agent. No additional wire identifier is required to locate the referenced record.¶

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

8.6. 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 do not record actions, as specified in Section 6.3.¶

• session_id MAY be absent when the request was not part of a session.¶

• task_id MAY be absent when the request was not part of a multi-request task.¶

• All other fields MUST be present. A field that MUST be present but is absent constitutes a chain break.¶

8.7. Verification Procedure

A verifier reconstructs the chain by:¶

1. Retrieving the terminal Audit-ID from the agent's audit store or from a counterparty's record of the Attribution-Record it received.¶

2. Fetching the full Attribution-Record JWS and verifying its hash matches the Audit-ID.¶

3. Verifying the JWS signature against the responding agent's manifest signing key, per [AGTP].¶

4. Following previous_audit_id backwards through the agent's chain, verifying each hash and each signature, until the chain head is reached.¶

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

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

7. Confirming the Agent-ID resolves to a valid Agent Genesis per [AGTP-LOG], that the Owner-ID 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 not revoked or suspended at the time of action).¶

8. 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 is a chain break and invalidates the audit value of the record.¶

9.1. New Headers Defined by This Document

Action-ID, Evaluation-ID, and Decision-ID are primarily carried as fields inside the extended Attribution-Record payload, not as standalone wire headers. The Action-ID MAY appear as a convenience header on the response for clients that need to reference it without parsing the JWS.¶

9.2. ABNF Grammar

The header values follow this grammar:¶

owner-id       = 1*256(ALPHA / DIGIT / "-" / "_" / ":" / ".")
request-id     = uuidv7 / ulid
response-id    = uuidv7 / ulid
audit-id       = 64HEXDIGLOWER
action-id      = uuidv7 / ulid

uuidv7         = 8HEXDIGLOWER "-" 4HEXDIGLOWER "-" "7" 3HEXDIGLOWER
                 "-" 4HEXDIGLOWER "-" 12HEXDIGLOWER
ulid           = 26BASE32

HEXDIGLOWER    = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
BASE32         = ALPHA / DIGIT

A header value that does not conform to this grammar SHALL be treated as malformed and the request or response SHALL be refused with status 400 Bad Request.¶

9.3. Echo Rules

The responding agent SHOULD echo the request's Request-ID unchanged in the response. This follows the echo convention [AGTP] uses for Task-ID and avoids introducing a separate correlation header. The responder's own identity is carried in Server-ID per [AGTP]; 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.¶

10.1. Resolution Targets

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

10.2. Lookup Methods

The default lookup method is the responding agent's audit store, which MUST be addressable by Audit-ID. The specific lookup protocol is operator-defined and out of scope for this document; implementations MAY expose an AGTP method for Audit-ID lookup, expose a REST endpoint over HTTPS, or rely on out-of-band retrieval. Future revisions of [AGTP-API] or this document MAY standardize a lookup interface.¶

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 [AGTP]. Identity-lifecycle events for Agent-ID are stored in the AGTP-LOG transparency log per [AGTP-LOG]; the lookup is via the AGTP-LOG protocol.¶

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

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

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

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

11.4. 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 [AGTP-LOG] 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.¶

11.5. 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 not personal 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.¶

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

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

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

13.1. EU AI Act

The EU AI Act [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.¶

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

14.1. AGTP Header Field Registry Additions

Registration of the following entries in the AGTP Header Field Registry (established by [AGTP]):¶

14.2. 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 (Table 1), the merchant-identity fields specified in [AGTP-MERCHANT], and the base fields specified in [AGTP].¶

Registration Procedure

Specification Required¶

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

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

17.1. Normative References

[AGTP]

Hood, C., "Agent Transfer Protocol (AGTP)", Work in Progress, Internet-Draft, draft-hood-independent-agtp-07, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-independent-agtp-07>.

[AGTP-LOG]

Hood, C., "AGTP Transparency Log Protocol", Work in Progress, Internet-Draft, draft-hood-agtp-log-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-log-01>.

[AGTP-SESSION]

Hood, C., "AGTP Session Protocol", Work in Progress, Internet-Draft, draft-hood-agtp-session-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-session-00>.

[AGTP-TRUST]

Hood, C., "AGTP Trust and Verification Specification", Work in Progress, Internet-Draft, draft-hood-agtp-trust-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-trust-00>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

17.2. Informative References

[AGTP-API]

Hood, C., "AGTP API Contract Specification", Work in Progress, Internet-Draft, draft-hood-agtp-api-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-api-00>.

[AGTP-CERT]

Hood, C., "AGTP Agent Certificate Extension", Work in Progress, Internet-Draft, draft-hood-agtp-agent-cert-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-agent-cert-00>.

[AGTP-MERCHANT]

Hood, C., "AGTP Merchant Identity for Agentic Commerce", Work in Progress, Internet-Draft, draft-hood-agtp-merchant-identity-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-merchant-identity-01>.

[EU-AI-ACT]

"Regulation (EU) 2024/1689 of the European Parliament and of the Council on artificial intelligence", 2024, <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9943]

"*** BROKEN REFERENCE ***".