AGTP Transparency Log Protocol

2.1. Scope: Post-Hoc Audit

AGTP-LOG addresses post-hoc audit: the recording of what has happened, after it has happened, in a form that can be verified later. This is the audit problem regulatory frameworks and compliance systems typically address.¶

Pre-commitment intent declaration — recording what an agent declares it is about to do, before action evaluation, with ordering guarantees that prevent ex-post fabrication of intent — is a distinct concern with different threat-model properties. AGTP-LOG does not address pre-commitment intent declaration. The AGTP framework treats pre-commitment intent declaration as adjacent work; see Section 2.3.¶

2.2. Regulatory Context

Audit infrastructure for agent operations is increasingly subject to regulatory requirements. The EU AI Act Article 12 requires automatic recording of events for high-risk AI systems with cryptographically verifiable provenance. Similar frameworks are emerging in other jurisdictions, and industry-specific regulations (financial services, healthcare, aviation, government) add their own requirements for agent attribution and audit trails.¶

AGTP-LOG provides the protocol-layer infrastructure these regulatory frameworks require: tamper-evident records of agent identity events, signed by accountable governance platforms, verifiable by independent third parties, bound to the wire-level identity used in agent operations. AGTP-LOG does not itself implement any specific regulatory framework; it provides the audit primitives that compliance systems built on AGTP can use to satisfy regulatory requirements.¶

2.3. Related Audit Work

Multiple parallel efforts in the agent infrastructure space address adjacent audit concerns. AGTP-LOG positions explicitly relative to:¶

Pre-commitment intent declaration: [IDP] defines intent declaration committed to a tamper-evident log before policy evaluation executes. The ordering guarantee (declaration < evaluation < execution) is structurally different from AGTP-LOG's post-hoc recording. AGTP-LOG and pre-commitment intent declaration are complementary: both can operate against the same governance platform, recording different categories of agent events.¶

HTTP-based audit data models: Work in progress in the IETF (e.g., [AUDIT-ARCH]) proposes audit data models layered over HTTP and existing token formats. AGTP-LOG's architectural commitment is different: audit is a structural property of the protocol substrate, not a data model retrofitted onto a substrate that was not designed for accountability. Both approaches may coexist for the agent traffic each substrate carries.¶

Transparency standards (SCITT, RFC 9162): AGTP-LOG reuses these verifiable data structures and receipt formats. AGTP-LOG is a profile and deployment pattern for SCITT-aligned audit infrastructure specific to AGTP agent identity events.¶

3.1. AGTP Agent Identity Taxonomy

AGTP identity is composed of three distinct elements. This taxonomy was formalized concurrent with the v07 revision of [AGTP] and is normatively adopted throughout the AGTP draft family.¶

Agent Genesis:

The permanent, signed governance-layer document produced at ACTIVATE time that establishes an agent's identity. The Agent Genesis is the origin record from which all other identity artifacts derive. It is issued by the governance platform, signed with the governance platform's key, and archived on revocation. An Agent Genesis is never reissued; the identity it establishes is permanent for the life of the agent.¶

Canonical Agent-ID:

A 256-bit cryptographic hash of the Agent Genesis, used as the agent's identifier in all AGTP protocol operations. The Canonical Agent-ID is the value carried in the Agent-ID header on every request, the key in the registry, and the subject of transparency log entries. The Canonical Agent-ID is derived from the Agent Genesis; it is not an independent value.¶

Agent Certificate:

An optional X.509 v3 credential defined in [AGTP-CERT] that binds the Canonical Agent-ID to TLS mutual authentication for transport- layer verification and O(1) scope enforcement at Scope-Enforcement Points. Agent Certificates are renewable and revocable, with a recommended 90-day validity period. The Agent Certificate is a derived credential, not an identity substrate; it references the Agent Genesis via the activation-certificate-id extension.¶

The relationship among these three elements:¶

ACTIVATE (method call)
   │
   ├──produces──►  Agent Genesis (signed JSON document)
   │                    │
   │                    └──hashed to produce──►  Canonical Agent-ID
   │
   └──optionally, for Level 3 deployments──►  Agent Certificate (X.509)
                                                  │
                                                  └──references──►  Agent Genesis

3.2. Log-Specific Terminology

Log:

An append-only, tamper-evident record of AGTP-LOG statements operated by a governance platform. The log implements the verifiable data structure of [RFC9162] and issues SCITT receipts per [RFC9943].¶

Log Operator:

The party that operates a log. In this revision the log operator is normatively the governance platform that issued the Agent Genesis statements committed to the log. Future revisions MAY permit log operation to be delegated to a separate entity.¶

Statement:

A single AGTP-LOG entry: a signed assertion by a log operator about an agent identity event. Each statement has an event type, subject, payload, issuer, and signature. See Section 6.¶

Receipt:

A COSE_Sign1 envelope per [RFC9943] issued by a log against a statement, attesting that the statement has been committed to the log. The receipt is the consumable proof for verifiers. See Section 7.¶

Inclusion Proof:

A cryptographic proof per [RFC9162] demonstrating that a given statement is present at a specific position in the log's tree structure. Embedded within a receipt or retrievable independently via the log protocol.¶

Consistency Proof:

A cryptographic proof per [RFC9162] demonstrating that two signed tree heads at different sizes are consistent (the smaller tree is a prefix of the larger). Used by monitors to detect split-view attacks.¶

Signed Tree Head (STH):

The log operator's signed assertion of the current tree size and root hash per [RFC9162] Section 4.10.¶

Witness:

A third party that countersigns the log's signed tree heads to attest that it has observed the log in a consistent state. The witness role is defined informally here and normatively specified in a future revision; see Section 13.¶

Monitor:

A party that polls the log's STHs and consistency proofs to detect split-view attacks or operator misbehavior. The monitor role is defined informally here and normatively specified in a future revision; see Section 13.¶

Verifier:

A consumer of an AGTP-LOG receipt that confirms a given Agent Genesis is committed to a log. Any party holding a Canonical Agent-ID and a log_uri can act as a verifier.¶

5.1. Per-Platform Logs (Default)

Each AGTP governance platform MUST operate a log if it issues Agent Genesis statements with verification_path: log-anchored. The governance platform is the log operator. Statements committed to the log are signed by the governance platform's key as recorded in the Agent Genesis issuer field.¶

A governance platform operating a log advertises the log's URI in the log_uri field of every Agent Genesis it produces under the log-anchored path. See Section 9.¶

Per-platform logs follow the SCITT issuer-local convention: each issuer commits its own statements to its own log, signed with its own key, with receipts referencing that issuer's identity. This matches typical deployment patterns and minimizes operational coupling between governance platforms.¶

5.2. Federation via Cross-Witnessing

When a deployment requires that statements from one governance platform be verifiable by participants who do not implicitly trust that platform's log operator, the platform MAY invite a witness to countersign its signed tree heads. The witness adds a second signature over the STH, attesting that the witness has observed the log in a consistent state at that tree size.¶

The cross-witnessing model preserves per-platform log operation while introducing third-party attestation. A verifier presented with an Agent Genesis from platform A and the corresponding receipt MAY require the STH to be countersigned by a witness whose key the verifier trusts before accepting the inclusion proof.¶

The witness protocol, witness selection, witness key publication, and the schema of countersigned STHs are deferred to a future revision per Section 13.¶

8.1. Submit Statement

POST {log_uri}/statements¶

Request body: a single COSE_Sign1 statement per Section 6. Content-Type application/agtp-log-statement+cose.¶

Response on success: HTTP 201 with the resulting receipt per Section 7. Content-Type application/scitt-receipt+cose.¶

Response on signature failure: HTTP 400 with body indicating which validation step failed (signature, issuer match, subject format, event type, payload schema, or genesis hash mismatch).¶

Submission is normatively restricted to the log operator itself: external parties MUST NOT be able to submit statements directly. The log operator validates and signs internally, then commits. This preserves the log's role as an attestation of the operator's own governance decisions.¶

8.2. Retrieve Receipt

GET {log_uri}/receipts/{statement-hash}¶

Path parameter: hex-encoded SHA-256 hash of the canonical CBOR statement.¶

Response on success: HTTP 200 with the receipt per Section 7.¶

Response on miss: HTTP 404 with body indicating whether the hash is unknown to this log or refers to a statement that has not yet been committed.¶

8.3. Retrieve Inclusion Proof

GET {log_uri}/proofs/inclusion?leaf-index={index}&tree-size={size}¶

Query parameters:¶

• leaf-index: the position of the statement (zero-indexed)¶

• tree-size: the STH tree size against which the proof is computed¶

Response on success: HTTP 200 with a CBOR-encoded inclusion proof per [RFC9162] Section 4.11. The proof is the audit path; the caller is responsible for verifying it against the STH at the requested tree size.¶

This operation duplicates information already in receipts; it exists for clients that hold a position and need a fresh proof against a different STH than the one originally bound in the receipt.¶

8.4. Retrieve Consistency Proof

GET {log_uri}/proofs/consistency?first-tree-size={n}&second-tree-size={m}¶

Query parameters:¶

• first-tree-size: the smaller tree size¶

• second-tree-size: the larger tree size¶

Response on success: HTTP 200 with a CBOR-encoded consistency proof per [RFC9162] Section 4.12. The proof attests that the tree at size n is a prefix of the tree at size m.¶

Used by monitors to detect split-view attacks. A monitor that observes two different signed tree heads from the same log operator at the same tree size MUST treat that as evidence of operator misbehavior.¶

8.5. Retrieve Signed Tree Head

GET {log_uri}/sth¶

Response on success: HTTP 200 with the current STH per [RFC9162] Section 4.10. The response is a CBOR-encoded structure carrying tree size, root hash, timestamp, and the log operator's signature over those fields.¶

The STH is the anchor for all inclusion and consistency proofs issued by the log. Verifiers MUST retrieve and cache the STH before validating any proof.¶

10.1. Per-Agent Local Lifecycle Stream

In addition to the public append-only transparency log, AGTP servers maintain a per-agent local lifecycle stream recording the lifecycle events emitted for each agent the server hosts. Each entry in the stream is a signed envelope carrying the event-type, subject, payload, issuer, and signature. The stream is retrievable via INSPECT target=lifecycle per [AGTP].¶

The local stream MAY use either of two envelope formats, selected by operator policy:¶

• JWS Compact per [RFC7515]. The signed envelope is the same JWS Compact serialization used for Attribution-Records. Each stream line carries a jws: prefix followed by the JWS Compact form. This is the default format and the simplest for operators without SCITT integration.¶

• COSE_Sign1 per [RFC9943]. The signed envelope is a COSE_Sign1 structure matching the statement format in Section 6. Each stream line carries a cose: prefix followed by the base64url-encoded COSE_Sign1 bytes. This format is appropriate for deployments aligning with SCITT.¶

The two formats MAY coexist within a single agent's stream when an operator flips the configured format between events; the per-line prefix disambiguates parsing. An INSPECT response that returns entries from a mixed stream MUST carry the per-entry format field defined in [AGTP] so clients can route each entry to the correct parser.¶

The Audit-ID for a lifecycle event is the SHA-256 of the serialized envelope bytes regardless of format: for JWS the hash covers the JWS Compact serialization; for COSE_Sign1 the hash covers the raw COSE_Sign1 bytes. The Audit-ID participates in the per-agent chain on the same terms as Attribution-Record Audit-IDs per [AGTP-IDENTIFIERS].¶

An AGTP server that operates an AGTP-LOG transparency log client MUST convert local lifecycle entries into COSE_Sign1 statements conforming to Section 6 before submission. The local stream and the transparency log are independent stores; the local stream is operator-controlled and per-server, while the transparency log is the governance-platform-operated public record.¶

11.1. Audited Party Forgery

A common threat model for audit systems is the audited party forging, altering, or omitting their own audit records. AGTP-LOG addresses this structurally rather than through policy controls.¶

Statements in AGTP-LOG are signed by the governance platform that operates the log, not by the agent the statements concern. The agent does not control the log operator's signing key. An agent cannot:¶

• Forge a statement attributing actions to a different agent identity (statements bind to agtp-subject and are signed by the log operator)¶

• Omit an event from its own audit trail (commit decisions are made by the log operator, not by the agent)¶

• Alter a committed statement after the fact (the verifiable data structure of [RFC9162] prevents retroactive modification without breaking tree consistency)¶

• Replace its audit history with a forged sequence (statements are identified by position in an append-only log; replacing history is detectable by monitors observing the log)¶

The threat shifts to compromising the governance platform itself (Section 11.2) rather than compromising the agent. This is a higher bar architecturally: the governance platform's signing key is a long-lived infrastructure credential typically protected with hardware security modules and key ceremonies, while agent credentials may be more numerous and shorter-lived.¶

This structural property distinguishes AGTP-LOG from audit approaches where the audited party participates in writing the audit trail. In application-layer audit logging on HTTP-based substrates, an agent or its operator typically generates audit records about its own behavior; ensuring those records cannot be altered by the audited party requires additional cryptographic machinery layered on top of the substrate. In AGTP-LOG, the separation is built into the protocol architecture.¶

11.2. Log Operator Compromise

The log operator is also the issuer of statements in the AGTP-LOG model in this revision. A compromised log operator could:¶

• Sign a fraudulent Agent Genesis for an Agent-ID it does not control, commit it to the log, and present the resulting receipt as proof of a non-existent agent's existence.¶

• Refuse to commit valid statements, denying agents legitimate Trust Tier 1 standing.¶

• Backdate statements by manipulating its internal clock prior to signing.¶

• Operate two parallel logs presenting different signed tree heads to different verifiers (a split-view attack).¶

The first three threats are inherent to any single-issuer log model and are partially mitigated by the witness mechanism (deferred to a future revision) and by external monitors that detect inconsistency. The split-view attack is specifically detectable via the consistency proof operation: a monitor that observes a second STH at the same tree size as a previously-observed STH from the same operator MUST treat the divergence as evidence of compromise.¶

Deployments that require defense against log operator compromise SHOULD require witness countersignatures on STHs (when a future revision specifies the witness protocol) and SHOULD subscribe to independent monitors that surface inconsistency evidence.¶

11.3. Witness Collusion

In a future revision incorporating witnesses, two or more witnesses colluding with a malicious log operator could countersign inconsistent STHs. This threat is structurally identical to log operator compromise from the verifier's perspective: the verifier trusts the witness set, and a colluding witness set is no better than a colluding operator. Mitigations are deferred to a future revision along with the witness protocol itself.¶

11.4. Private Key Handling

The log operator's signing key is the root of all trust in AGTP-LOG. Operators MUST protect this key with controls appropriate to a long-lived signing identity: hardware security modules, key ceremonies for key generation and rotation, and documented operational procedures for key recovery.¶

Key rotation procedures and the binding of historical STHs to retired keys are not specified in this revision; see Section 13.¶

11.5. Statement Privacy

Statements in AGTP-LOG are public by design. The Agent Genesis itself is published as the canonical identity record of an agent; the lifecycle events that follow it are operational facts. AGTP-LOG is not a confidential audit log.¶

Operators MUST NOT commit statements containing secrets, operational credentials, or other sensitive material. The validation gates in Section 6 are insufficient to filter privacy violations; preventing privacy leaks in statement payloads is the operator's responsibility.¶

11.6. Replay and Statement Substitution

A statement signed by a valid log operator and committed to a log is durable: the log operator cannot retroactively replace it without breaking the consistency property of the tree. However, duplicate submissions of the same logical statement at different positions are not prevented by the protocol; the log operator SHOULD deduplicate statements before commit, using the canonical CBOR encoding as the deduplication key.¶

11.7. Threat Model Reference

The full Trust Tier 1 threat model is specified in [AGTP] Section 7 and [AGTP-TRUST]. AGTP-LOG is one of three equivalent verification paths; the threat model considers attacks against the log-anchored path within the broader context of dns-anchored and hybrid alternatives.¶

12.1. AGTP-LOG Event Types

The five event types defined in this revision form an extensible event-type set:¶

New event types MUST be defined in a published specification that describes the triggering condition, subject, payload schema, and the validation rules a log operator applies before commit. Implementers introducing event types prior to a formal registry process SHOULD prefix experimental types with x- to avoid namespace collisions with future registered types.¶

12.2. Media Types

This document defines two media types for AGTP-LOG message serialization:¶

application/agtp-log-statement+cose

AGTP-LOG statement envelope (COSE_Sign1 per [RFC9052]).¶

application/agtp-log-statement+cbor

AGTP-LOG statement payload (CBOR, deterministic encoding per [RFC8949] Section 4.2). Used as the payload of the COSE_Sign1 envelope.¶

The SCITT receipt media type application/scitt-receipt+cose is defined in [RFC9943] and reused without redefinition.¶

12.3. COSE Header Parameters

The following protected-header parameter names are introduced by this document. CBOR label assignments are not made by this document; implementations prior to a formal registry process SHOULD use string-form labels in the protected header rather than numeric labels, and MUST document their string-to-numeric mapping for downstream tooling.¶

12.4. Identity Document Field

The log_uri field defined in Section 9 is proposed as an addition to the Agent Identity Document defined in [AGTP]. Its adoption is anticipated in a future revision of [AGTP] and will be reflected in whichever field-management mechanism the AGTP family adopts for the Agent Identity Document schema.¶

14.1. Substantive Changes

The following substantive changes were made:¶

1. Lifecycle event triggering methods aligned with [AGTP] v08 eighteen-method floor. [AGTP] v08 promotes five Lifecycle methods to the protocol-level method floor: ACTIVATE, DEACTIVATE, REINSTATE, REVOKE, and DEPRECATE. The Event Types table is updated to name each as the triggering method for its corresponding event: agent-genesis-issued by ACTIVATE, agent-genesis-revoked by REVOKE, agent-lifecycle-suspended by DEACTIVATE (replacing the v01 SUSPEND triggering method, which is a Mechanics in-session pause method, not a lifecycle transition), agent-lifecycle-reinstated by REINSTATE, and agent-lifecycle-deprecated by DEPRECATE. The five event types themselves are unchanged; only the method-to- event mapping is corrected and finalized.¶

2. Per-Agent Local Lifecycle Stream section added. A new section (Section 10.1) specifies the per-agent lifecycle stream maintained by AGTP servers as distinct from the public transparency log defined in this document. Local streams MAY use either JWS Compact (with a jws: prefix) or COSE_Sign1 (with a cose: prefix) envelope per operator policy; mixed-format streams are permitted and clients distinguish per line. An AGTP-LOG client submitting local lifecycle entries to the transparency log MUST convert to the COSE_Sign1 statement format specified in Section 6. The Audit-ID derivation rule covers both envelopes. This documents the SCITT-aligned implementation that ships with v07/v08 conformant deployments.¶

3. Normative reference to [AGTP] updated to v08. Informative references to [AGTP-CERT] and [AGTP-TRUST] updated to v01.¶

14.2. Wire Format Compatibility

None. Statement and receipt formats are unchanged. Logs that have admitted statements under the v01 triggering-method mapping continue to operate; the event types they hold are valid under v02 (only the triggering-method documentation changed).¶

16.1. Normative References

[AGTP]

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

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

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

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

[RFC9943]

"*** BROKEN REFERENCE ***".

16.2. Informative References

[AGTP-CERT]

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

[AGTP-IDENTIFIERS]

Hood, C., "AGTP Identifier Stack and Attribution-Record", Work in Progress, Internet-Draft, draft-hood-agtp-identifiers-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-identifiers-01>.

[AGTP-TRUST]

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

[AUDIT-ARCH]

Kuehlewind, M. and H. Birkholz, "AI Agent Auditing Architecture", Work in Progress, Internet-Draft, draft-kuehlewind-audit-architecture-00, 2026, <https://datatracker.ietf.org/doc/html/draft-kuehlewind-audit-architecture-00>.

[IDP]

Sato, T., "Intent Declaration Protocol", Work in Progress, Internet-Draft, draft-sato-soos-idp-00, 2026, <https://datatracker.ietf.org/doc/html/draft-sato-soos-idp-00>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.