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 and lies outside AGTP-LOG. 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 implements no specific regulatory framework itself; 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 a different problem 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, where the HTTP-based approach retrofits a data model onto a substrate designed without accountability in mind. 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 and attribution events.¶

The IETF audit discussion: the audit@ietf.org list and the BoF requested for IETF 127 are the venue in which this document and the identifier chain of [AGTP-IDENTIFIERS] expect review. The claim offered there is the one this document makes: audit is a structural property of the substrate when the record is written by a party other than the audited one, and the sharper question of a self-held record made tamper-evident to a distrusting verifier has the answer in Section 6.1.¶

3.1. AGTP Agent Identity Taxonomy

AGTP identity is composed of three distinct elements. The authoritative taxonomy is the Document Taxonomy of [AGTP], which also places the mutable Agent Identity Document ([AGTP-IDDOC]) beside the three elements restated here; this section restates only what the log depends on.¶

Agent Genesis:

The permanent, signed governance-layer document issued at registration, before ACTIVATE, 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. ACTIVATE is the later lifecycle transition that makes the agent reachable; it never mints a Genesis ([AGTP]).¶

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 and has no independent existence. Per [AGTP], the hash is computed over the canonical-form Genesis with the signature and log_inclusion_proof fields excluded, which is what lets the Genesis carry its own inclusion proof (Section 7).¶

Agent Certificate:

An optional X.509 v3 credential defined in [AGTP-CERT] that binds the Canonical Agent-ID to TLS mutual authentication for TLS-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, with the Genesis as its substrate; it references the Agent Genesis via the activation-certificate-id extension.¶

The relationship among these three elements:¶

Registration (governance platform)
   |
   +--issues------>  Agent Genesis (signed JSON document)
   |                     |
   |                     +--hashed to produce-->  Canonical Agent-ID
   |
   +--optionally, for Level 3 deployments-->  Agent Certificate (X.509)
   |                                               |
   |                                               +--references-->  Agent Genesis
   |
ACTIVATE (lifecycle method, later)
   |
   +--transitions the Agent-ID to Active; publishes it (ANS, presence)

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 withhold implicit trust from 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.¶

6.1. Attribution Statements

[AGTP-IDENTIFIERS] defines the per-agent attribution chain: each Attribution-Record is signed by the recording agent's server and linked to its predecessor by Audit-ID. Against a verifier that trusts the holder, the signatures and the linkage suffice. Against a verifier that distrusts the holder, they are insufficient, since the holder could re-sign a modified history from the head back. The remedy [AGTP-IDENTIFIERS] names is inclusion in a log the holder cannot rewrite, and this section is that log's side of it.¶

For audit-id-committed:¶

{
  "audit-id": <bytes>,                   ; 32-byte Audit-ID per
                                         ; AGTP-IDENTIFIERS
  "record-kind": <text>,                 ; "attribution-record" or
                                         ; "lifecycle-event"
  "recorded-at": <text>,                 ; RFC 3339, from the record
  "sequence": <uint>,                    ; position in the per-agent
                                         ; chain, 0-based
  "log-position": <uint>,
  "previous-tree-size": <uint>
}

For chain-head-committed:¶

{
  "head-audit-id": <bytes>,              ; Audit-ID at the chain head
  "sequence": <uint>,                    ; chain length at commit
  "period-start": <text>,                ; RFC 3339
  "period-end": <text>,                  ; RFC 3339
  "log-position": <uint>,
  "previous-tree-size": <uint>
}

The submitter is the AGTP server that produced the record, acting for the agent whose Canonical Agent-ID is the agtp-subject; the log operator signs the statement as issuer, so the committed statement is the operator's attestation that the Audit-ID existed at the commit time, which the holder can neither antedate nor revise afterward. The statement carries the Audit-ID alone; the Attribution-Record payload stays off the log, since it may hold operational detail unfit for a public log (Section 11).¶

A deployment that elects per-record commitment submits one audit-id-committed statement per Attribution-Record. A deployment that elects periodic commitment submits one chain-head-committed statement per period, at an interval it MUST state in its governance policy; between commitments, records are tamper-evident only to verifiers that trust the holder, and a verifier reporting on such a record MUST say so per [AGTP-IDENTIFIERS]. Omission is detectable under either election: a gap in sequence across consecutive statements for one subject, or a record whose log_inclusion is absent in a deployment whose policy requires it, is a break in the chain.¶

The receipt for either statement is referenced from the extended Attribution-Record's log_inclusion field, a JSON object:¶

{
  "log_uri": "https://log.acme.tld/agtp",
  "statement_position": 48213,
  "statement_hash": "<64 lowercase hex>",
  "receipt": "<base64url COSE_Sign1 receipt>"
}

receipt MAY be replaced by receipt_uri, an HTTPS URI from which the receipt is retrievable per Section 8.2, when the deployment prefers to keep records small. A verifier that distrusts the holder retrieves the STH per Section 8.5, verifies the receipt's inclusion proof against it, and confirms that the statement at statement_position carries the record's Audit-ID as audit-id (or, for periodic commitment, that the record's Audit-ID refolds into a committed head-audit-id through the chain the holder presents).¶

6.2. Statement Acceptance

The CBOR encoding MUST be deterministic per [RFC8949] Section 4.2 (Canonical CBOR). The signature is computed over the COSE_Sign1 Sig_structure per [RFC9052] Section 4.4.¶

A statement is accepted into the log only after the log operator has verified:¶

1. The signature is valid against the log operator's published key.¶

2. The agtp-issuer URI matches the log operator's identity.¶

3. The agtp-subject is a well-formed 32-byte Canonical Agent-ID.¶

4. The agtp-event-type is registered in the AGTP-LOG event-type registry.¶

5. The payload structure conforms to the schema for the declared event type.¶

6. For agent-genesis-issued, the hash of the embedded Agent Genesis, computed per [AGTP] with signature and log_inclusion_proof excluded, matches the agtp-subject byte for byte.¶

7. For audit-id-committed and chain-head-committed, the submitter is a server the log operator's governance platform recognizes as hosting the agtp-subject, and sequence is greater than that of the subject's previously committed statement of the same type.¶

Statements failing any of these checks MUST NOT be appended to the log. The log operator MUST record the rejection in its operational logs but MUST NOT commit the rejected statement to the verifiable tree.¶

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

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 in the structure of the protocol, with no policy control to rely on.¶

Statements in AGTP-LOG are signed by the governance platform that operates the log, never by the agent the statements concern. The log operator's signing key is outside the agent's control. 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 alone; for attribution statements, omission shows as a sequence gap per Section 6.1)¶

• 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); compromising the agent gains nothing. The bar is higher: 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; protecting those records from 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 outside its 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 the same as 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 deferred to a later 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, and an attribution statement carries an Audit-ID alone, with the record behind it held by the parties. AGTP-LOG is a public 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 remain possible under 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 the security considerations of [AGTP] and in [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 seven 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. This document makes no CBOR label assignments; implementations prior to a formal registry process SHOULD use string-form labels in the protected header in place of numeric labels, and MUST document their string-to-numeric mapping for downstream tooling.¶

12.4. Identity Document Field

The log_uri field is defined in the Agent Genesis by [AGTP] and in the Agent Identity Document by [AGTP-IDDOC]; this document defines its semantics (Section 9) and registers nothing further for it.¶

14.1. Substantive Changes

1. Attribution statements (Section 6.1). Two event types, audit-id-committed and chain-head-committed, by which an AGTP server commits Attribution-Record Audit-IDs or periodic chain heads to the log, and the log_inclusion reference object the extended Attribution-Record of draft-hood-agtp-identifiers-03 carries, which is the mechanism that document names for tamper evidence against a distrusting verifier. Acceptance check 7 added.¶

2. Agent-ID hash and receipt ordering. Version 02 embedded the receipt before hashing, which made the statement's subject depend on its own receipt. draft-hood-independent-agtp-10 excludes log_inclusion_proof from the hash alongside signature; the ordering in Section 7 and acceptance check 6 now follow it.¶

3. Genesis is issued at registration, before ACTIVATE. The taxonomy and the agent-genesis-issued trigger said ACTIVATE produced the Genesis; base AGTP v10 states that ACTIVATE never mints and is the publish transition. Diagram redrawn.¶

4. log_uri adopted. The field this document proposed is now defined in the Agent Genesis by draft-hood-independent-agtp-10 and mirrored in the Identity Document by draft-hood-agtp-identity-document-00; the interim-mechanism text is withdrawn and the bootstrap document's log_anchor is named for namespace-level discovery.¶

5. Audit venue noted in Section 2.3.¶

6. References pinned to draft-hood-independent-agtp-10, AGTP-CERT -03, AGTP-TRUST -02, AGTP-IDENTIFIERS -03; AGTP-IDDOC added. Hardcoded section numbers replaced. House style pass.¶

14.2. Wire Format Compatibility

The two attribution event types are additive. The Agent-ID hash exclusion is a base AGTP change and affects only Genesis documents that carry a log_inclusion_proof; see the compatibility note in draft-hood-independent-agtp-10.¶

15.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 and no 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.¶

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

17.1. Normative References

[AGTP]

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

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

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

17.2. Informative References

[AGTP-CERT]

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

[AGTP-IDDOC]

Hood, C., "AGTP Agent Identity Document", Work in Progress, Internet-Draft, draft-hood-agtp-identity-document-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-identity-document-00>.

[AGTP-IDENTIFIERS]

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

[AGTP-TRUST]

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

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