AGTP Transparency Log Protocol

Introduction recognizes log-anchored as one of three equivalent Trust Tier 1 verification paths defined in . This document specifies the log protocol that path depends on. Earlier draft material that referred to an inline AGTP Certificate Transparency Log (AGTP-CTL) in early revisions of is superseded by this document, and now references AGTP-LOG in place of a log of its own. AGTP-LOG inherits the verifiable data structure of and the receipt format of . This document leaves the cryptographic primitives and the underlying append-only log construction as those documents define them; it specifies how an AGTP governance platform operates a log over those primitives, what kinds of statements the log accepts, how verifiers discover the log, and how AGTP-LOG receipts are bound to the Agent Identity Document. The key requirements language follows and .

AGTP-LOG as Audit Infrastructure AGTP-LOG is the audit infrastructure for AGTP-based agent operations. Entries committed to the log constitute the post-hoc record of agent identity events (creation, lifecycle transitions, and revocation) and, where a deployment elects it, of the Audit-IDs of the actions those agents take. These records carry the structural properties that distinguish protocol-layer audit from application-layer audit logging: Audited party cannot forge own trail. Statements are signed by the governance platform that issued the Agent Genesis, never by the agent. The log operator's signing key is outside the agent's control, so the agent can neither forge, alter, nor omit its own audit records. This is a structural property of the architecture; no policy constraint needs enforcing to obtain it. Audit records are append-only and tamper-evident. The verifiable data structure of guarantees that committed statements cannot be retroactively altered without breaking the cryptographic consistency of the log. A log operator that publishes inconsistent tree heads is detectable by monitors observing the log. Audit records carry cryptographic provenance. Receipts per are independently verifiable: a party holding a Canonical Agent-ID and the corresponding receipt can confirm the audit record exists in the log without trusting any single party's assertion that it does. Audit records are bound to wire-level identity. The agtp-subject field of every statement is a Canonical Agent-ID that ties the audit record to the protocol-level identity used in every AGTP request. The audit trail and the operational identity are the same identity, with no separately maintained representations to correlate after the fact.

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 .

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.

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: 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., ) 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 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 .

Terminology

AGTP Agent Identity Taxonomy AGTP identity is composed of three distinct elements. The authoritative taxonomy is the Document Taxonomy of , which also places the mutable Agent Identity Document () 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 ().
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 , 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 ().
Agent Certificate:: An optional X.509 v3 credential defined in 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: 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) ]]>

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 and issues SCITT receipts per .
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 .
Receipt:: A COSE_Sign1 envelope per 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 .
Inclusion Proof:: A cryptographic proof per 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 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 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 .
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 .
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.

Log Scope A log MUST accept statements for at least the following five identity event types, and a log serving a deployment that requires tamper evidence against the recording agent per MUST also accept the two attribution event types of . The event type is recorded in the statement envelope (see ). The triggering methods for the lifecycle events are the Lifecycle methods on the AGTP method floor (see ). AGTP-LOG Event Types

Event Type	Triggered By	Subject
`agent-genesis-issued`	Agent Genesis issuance at registration	Canonical Agent-ID derived from the new Agent Genesis
`agent-genesis-revoked`	REVOKE method completion	Canonical Agent-ID being retired
`agent-lifecycle-suspended`	DEACTIVATE method completion	Canonical Agent-ID entering Suspended state
`agent-lifecycle-reinstated`	REINSTATE method completion	Canonical Agent-ID returning to Active state
`agent-lifecycle-deprecated`	DEPRECATE method completion	Canonical Agent-ID entering Deprecated state

AGTP-LOG Attribution Event Types

audit-id-committed	Attribution-Record production, when the deployment requires tamper evidence	Canonical Agent-ID of the recording agent
`chain-head-committed`	Periodic, at the interval the deployment states	Canonical Agent-ID of the recording agent

These seven event types form the initial AGTP-LOG event-type registry (see ). Future event types MAY be registered as new operational categories arise without requiring revision of this document. Implementations MAY log additional event types beyond the above five. Agent Certificate issuance and revocation events, defined in , are explicit candidates: a deployment that operates both AGTP-LOG and an Agent Certificate authority MAY log certificate-lifecycle events to the same log. Whether a deployment logs certificate events is a deployment decision; this document leaves it optional. When logged, the event types MUST be registered in the AGTP-LOG event-type registry; ad-hoc event-type strings MUST NOT be admitted. Statements MUST NOT carry secret material. The Agent Genesis is public by design; the Canonical Agent-ID is derived from a public hash; lifecycle states are operational facts. A log operator that finds itself wanting to commit a secret to the log is misusing the protocol.

Log Architecture

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

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 .

Entry Format Every statement is a SCITT-aligned signed envelope per . The envelope is a COSE_Sign1 structure per containing the following protected and unprotected header parameters and payload. The entry format specified in this section is the transparency-log statement format that the AGTP-LOG operator admits to its append-only log. It is distinct from the per-agent local lifecycle stream maintained by AGTP servers (), which MAY use either a JWS or a COSE_Sign1 envelope. AGTP servers that submit lifecycle events to an AGTP-LOG transparency log MUST convert the local event into a COSE_Sign1 statement conforming to this section before submission. The protected header MUST carry: AGTP-LOG Statement Protected Header

Parameter	CBOR Label	Value
`alg`	1	Signing algorithm. MUST be `ES256` (-7), `ES384` (-35), `ES512` (-36), or `EdDSA` (-8).
`kid`	4	Key identifier of the log operator's signing key (governance platform key).
`cty`	3	Content type. MUST be `application/agtp-log-statement+cbor`.
`agtp-event-type`	TBD	One of the event-type strings registered in the AGTP-LOG event-type registry.
`agtp-subject`	TBD	Canonical Agent-ID, encoded as a 32-byte CBOR byte string.
`agtp-issuer`	TBD	URI of the governance platform issuing this statement.
`agtp-issued-at`	TBD	Statement issuance time as an RFC 3339 timestamp.

The unprotected header MAY carry implementation-specific parameters; verifiers MUST ignore unrecognized unprotected parameters. The payload MUST be a CBOR-encoded map whose contents depend on the event type: For agent-genesis-issued: , ; the canonical CBOR-encoded ; Agent Genesis document "log-position": , ; assigned by log operator ; on entry commit "previous-tree-size": ; tree size before this entry } ]]> For agent-genesis-revoked, agent-lifecycle-suspended, agent-lifecycle-reinstated, and agent-lifecycle-deprecated: , ; matches event-type "reason": , ; operator-supplied reason "previous-state": , ; lifecycle state prior to event "new-state": , ; lifecycle state after event "log-position": , "previous-tree-size": } ]]>

Attribution Statements 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 names is inclusion in a log the holder cannot rewrite, and this section is that log's side of it. For audit-id-committed: , ; 32-byte Audit-ID per ; AGTP-IDENTIFIERS "record-kind": , ; "attribution-record" or ; "lifecycle-event" "recorded-at": , ; RFC 3339, from the record "sequence": , ; position in the per-agent ; chain, 0-based "log-position": , "previous-tree-size": } ]]> For chain-head-committed: , ; Audit-ID at the chain head "sequence": , ; chain length at commit "period-start": , ; RFC 3339 "period-end": , ; RFC 3339 "log-position": , "previous-tree-size": } ]]> 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 (). 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 . 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: ", "receipt": "" } ]]> receipt MAY be replaced by receipt_uri, an HTTPS URI from which the receipt is retrievable per , when the deployment prefers to keep records small. A verifier that distrusts the holder retrieves the STH per , 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).

Statement Acceptance The CBOR encoding MUST be deterministic per Section 4.2 (Canonical CBOR). The signature is computed over the COSE_Sign1 Sig_structure per Section 4.4. A statement is accepted into the log only after the log operator has verified:

The signature is valid against the log operator's published key.
The agtp-issuer URI matches the log operator's identity.
The agtp-subject is a well-formed 32-byte Canonical Agent-ID.
The agtp-event-type is registered in the AGTP-LOG event-type registry.
The payload structure conforms to the schema for the declared event type.
For agent-genesis-issued, the hash of the embedded Agent Genesis, computed per with signature and log_inclusion_proof excluded, matches the agtp-subject byte for byte.
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.

Receipt Format A receipt is a COSE_Sign1 envelope per attesting that a statement has been committed to the log. Receipts are the consumable proof for AGTP verifiers. The receipt's content type is application/scitt-receipt+cose per . The receipt's payload references the statement's position in the log and embeds an inclusion proof against a signed tree head. The protected header MUST carry: AGTP-LOG Receipt Protected Header

Parameter	CBOR Label	Value
`alg`	1	Signing algorithm; same constraint as statement signing.
`kid`	4	Key identifier of the log operator's signing key.
`cty`	3	Content type. MUST be `application/scitt-receipt+cose`.
`verifiable-data-structure`	TBD	MUST be `RFC9162_SHA256` per .
`agtp-statement-position`	TBD	The log position (zero-indexed) of the committed statement.
`agtp-statement-hash`	TBD	SHA-256 hash of the canonical CBOR-encoded statement.
`agtp-signed-tree-head`	TBD	The STH the inclusion proof attests against.

The payload MUST be a CBOR-encoded map carrying the inclusion proof: , ; STH tree size "leaf-index": , ; position of statement "audit-path": [, , ...] ; Merkle audit path per RFC 9162 } ]]> Receipts MUST be retrievable by any party that holds the Canonical Agent-ID and the log_uri. The receipt MUST NOT contain the statement itself; verifiers requiring the statement MUST retrieve it separately. This separation keeps receipts small enough to embed in the Agent Genesis (log_inclusion_proof field) without bloating the Agent Identity Document. The receipt for an agent-genesis-issued event MUST be embedded in the Agent Genesis's log_inclusion_proof field at the moment the Agent Genesis is finalized. The governance platform computes the Canonical Agent-ID over the Genesis with signature and log_inclusion_proof excluded (), commits the statement (whose subject is that Agent-ID and whose payload is the Genesis without those two fields), retrieves the resulting receipt, embeds the receipt in the Agent Genesis, and only then signs it. The Agent-ID is therefore stable across the embedding, and a verifier recomputing it from the finished Genesis obtains the same value the statement names. Version 02 of this document described the hash as taken after embedding, which was circular with the statement's subject; the exclusion rule in resolves it.

Log Protocol The log operator exposes four operations to clients. All operations MUST be available over HTTPS at paths relative to the log's base URI (the log_uri value advertised in the Agent Genesis). Implementations SHOULD also expose these operations over AGTP at the same logical paths.

Submit Statement POST {log_uri}/statements Request body: a single COSE_Sign1 statement per . Content-Type application/agtp-log-statement+cose. Response on success: HTTP 201 with the resulting receipt per . 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.

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 . Response on miss: HTTP 404 with body indicating whether the hash is unknown to this log or refers to a statement that awaits commitment.

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

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

Retrieve Signed Tree Head GET {log_uri}/sth Response on success: HTTP 200 with the current STH per 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.

Discovery A verifier holding a Canonical Agent-ID locates the log containing the relevant inclusion proof via the log_uri field of the Agent Genesis, defined in and mirrored into the Agent Identity Document by so that a verifier holding only the Identity Document can find the log. Version 02 of this document proposed the field; adopts it. The log_uri field carries an absolute HTTPS URI pointing to the base of the log's protocol surface. All log protocol operations defined in this document are exposed at paths relative to this URI. A verifier that has retrieved an Agent Genesis (whether via canonical Agent-ID resolution per , via the AGTP DISCOVER method, or via any other means) MUST:

Read the log_uri field.
Validate that the URI uses the https:// scheme.
Open a TLS connection to the log endpoint.
Retrieve the STH, verify its signature against the governance platform's published key.
Retrieve the inclusion proof for the Agent Genesis (either by parsing the embedded log_inclusion_proof receipt or by requesting a fresh proof from the log).
Verify the inclusion proof against the STH.

If the log_uri field is absent from an Agent Genesis whose verification_path is log-anchored, the Agent Genesis is malformed and the verifier MUST reject the agent identity. If the log_uri is present but the log is unreachable at verification time, the verifier MAY fall back to the cached inclusion proof embedded in the Agent Genesis's log_inclusion_proof field if such a cached proof exists and remains valid against the verifier's last-known good STH. At the namespace level, the organization's bootstrap document at /.well-known/agtp () carries the log URI in its verification.log_anchor field, so a resolver learns where an organization's log is before it holds any Genesis from it. The per-agent log_uri remains authoritative: where the two differ, the Genesis governs for that agent. No separate well-known path for AGTP-LOG is defined.

Integration with AGTP The log_inclusion_proof field of the Agent Genesis () and of the Agent Identity Document () references the inclusion proof produced by this log. A verifier retrieves the proof, validates it against the log's signed tree head, and confirms the Agent Genesis is committed to the log. The verification_path: log-anchored value defined in indicates that the agent's Trust Tier 1 verification depends on a log-committed Agent Genesis. Verifiers consuming such an agent MUST perform the inclusion-proof verification described in before granting Authority-Scope decisions on the agent's behalf. The log_inclusion field of the extended Attribution-Record () references the receipt for an audit-id-committed or chain-head-committed statement (). The two references serve different verifiers: log_inclusion_proof answers whether this identity was issued, and log_inclusion answers whether this action was recorded when its holder says it was.

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 . The local stream MAY use either of two envelope formats, selected by operator policy:

JWS Compact per . 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 . The signed envelope is a COSE_Sign1 structure matching the statement format in . 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 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 . An AGTP server that operates an AGTP-LOG transparency log client MUST convert local lifecycle entries into COSE_Sign1 statements conforming to 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.

Security Considerations

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 )
Alter a committed statement after the fact (the verifiable data structure of 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 (); 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.

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.

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.

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 .

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 are insufficient to filter privacy violations; preventing privacy leaks in statement payloads is the operator's responsibility.

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.

Threat Model Reference The full Trust Tier 1 threat model is specified in the security considerations of and in . 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.

Future Registry Considerations The AGTP family includes several constructs (status codes, header fields, identity document fields, method names, media types) whose long-term stewardship will require coordinated management once the ecosystem matures. Several of these constructs are AGTP-specific and have no current home in existing standards-body registries. The appropriate venue for AGTP registry stewardship (IANA, an AGTP governance forum, a foundation, or some combination) is an open question for the broader AGTP family; this document takes no position on it. This section enumerates the registry-shaped artifacts AGTP-LOG defines, so that whichever stewardship model the AGTP family eventually adopts has a clear inventory of what AGTP-LOG contributes. No commitment to any specific registry venue is made by this document.

AGTP-LOG Event Types The seven event types defined in this revision form an extensible event-type set: AGTP-LOG Event Types Registry

Event Type	Reference
`agent-genesis-issued`	This document,
`agent-genesis-revoked`	This document,
`agent-lifecycle-suspended`	This document,
`agent-lifecycle-reinstated`	This document,
`agent-lifecycle-deprecated`	This document,
`audit-id-committed`	This document,
`chain-head-committed`	This document,

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.

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 ).
application/agtp-log-statement+cbor: AGTP-LOG statement payload (CBOR, deterministic encoding per Section 4.2). Used as the payload of the COSE_Sign1 envelope.

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

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. AGTP-LOG Protected Header Parameter Names

Parameter Name	Use
`agtp-event-type`	Event type string for the AGTP-LOG statement.
`agtp-subject`	Canonical Agent-ID (32 bytes) the statement concerns.
`agtp-issuer`	Governance platform URI signing the statement.
`agtp-issued-at`	Issuance timestamp per RFC 3339.
`verifiable-data-structure`	Receipt parameter; MUST be `RFC9162_SHA256`.
`agtp-statement-position`	Log position of the statement the receipt covers.
`agtp-statement-hash`	SHA-256 of the canonical statement encoding.
`agtp-signed-tree-head`	The STH the receipt attests against.

Identity Document Field The log_uri field is defined in the Agent Genesis by and in the Agent Identity Document by ; this document defines its semantics () and registers nothing further for it.

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

Witness protocol. Witness selection, key publication, countersigned STH schema, witness inclusion in receipts, and the failure modes when witness signatures are inconsistent.
Monitor role. Formal monitor specification: polling cadence, consistency-proof retention, split-view reporting protocol, and monitor discoverability.
Federation across governance platforms. Cross-platform agent identity resolution when multiple governance platforms operate independent logs and an agent originates from one but is invoked via another. This revision assumes per-platform isolation.
Key rotation. Procedures for rotating the log operator's signing key, binding historical STHs to retired keys, and ensuring older inclusion proofs remain verifiable across key rotations.
Log operator delegation. Whether and how a governance platform may delegate log operation to a separate entity while preserving the issuer-equals-operator property.
Statement deduplication. A normative deduplication algorithm that is robust to byte-level variations in CBOR encoding (the protocol currently relies on deterministic encoding to make this tractable).
Discovery via well-known URI. Specification of a well-known discovery endpoint per once the broader AGTP family adopts well-known URI conventions.
CBOR label assignments for AGTP-LOG header parameters. The table in marks these as TBD pending the outcome of AGTP family registry stewardship decisions. Until numeric labels are assigned, implementations SHOULD use the string-form parameter names and document their string-to-numeric mapping for downstream tooling.
Registry stewardship venue. Whether AGTP-LOG registries (event types, media types, header parameters, identity document fields) are stewarded through IANA, an AGTP governance forum, or another mechanism is an open question for the AGTP family. This document enumerates the registry-shaped artifacts it contributes without committing to a venue.

Changes from v02 Version 03 adds the attribution statements and resolves two inconsistencies with the base document; the identity statement format, receipt format, log protocol, and discovery mechanics are otherwise unchanged.

Substantive Changes

Attribution statements (). 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.
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 and acceptance check 6 now follow it.
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.
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.
Audit venue noted in .
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.

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.

Changes from v01 Version 02 is a drift-cleanup revision. The log scope, statement format, receipt format, log protocol, and discovery mechanics are unchanged.

Substantive Changes The following substantive changes were made:

Lifecycle event triggering methods aligned with v08 eighteen-method floor. 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.
Per-Agent Local Lifecycle Stream section added. A new section () 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 . The Audit-ID derivation rule covers both envelopes. This documents the SCITT-aligned implementation that ships with v07/v08 conformant deployments.
Normative reference to updated to v08. Informative references to and updated to v01.

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

Contributors Feedback from Scott Courtney (GoDaddy / ANS) on SCITT alignment and production deployment considerations informed this draft. The event-type registry structure follows the SCITT philosophy of deterministic CBOR statement envelopes with externally-managed event-type names, allowing the AGTP ecosystem to add new event categories without spec revisions.