Two standards bodies have spent the last three years answering the same question from opposite directions. The European Parliament, under Article 12 of the EU AI Act, mandated that high-risk AI systems produce automatic, tamper-evident, traceable event logs conformant to recognised standards or common specifications. The IETF, under the SCITT working group, has been building exactly that standard — a Supply Chain Integrity, Transparency, and Trust architecture for cryptographic evidence that anyone with the public keys can verify offline.

The two haven't been publicly connected. Microsoft and Google have shipped SCITT-aligned transparency for software supply chain (binary attestations, package signing). Compliance vendors have written about Article 12 in generic terms (use a log shipper, use an SIEM). The intersection — SCITT-shaped cryptographic notarization as the Article 12 implementation pattern for autonomous AI agents — has no shared vocabulary yet. This post is an attempt to give it one.

Below: the actual Article 12 requirement, the SCITT primitive that satisfies each part, the gaps SCITT explicitly leaves open, and a concrete implementation pattern. References at the end are primary sources only (IETF drafts, EU Regulation text, RFC numbers).

What Article 12 actually demands

Article 12 of Regulation (EU) 2024/1689 requires that high-risk AI systems “technically allow for the automatic recording of events (logs) over the lifetime of the system.” The text requires that those capabilities conform to recognised standards or common specifications (Art. 12(1)) and that the resulting logs ensure a level of traceability appropriate to the intended purpose of the system (Art. 12(2)).

For the practitioner, this distills into five operational requirements:

Automatic. Events are recorded by the system, not by a person after the fact.
Traceable. Logs must allow reconstruction of who acted, when, on what input, with what outcome. Article 14 (human oversight) and Article 26 (deployer obligations) sit on top of this.
Ordered. Chronology must be verifiable, not merely asserted.
Tamper-evident. Mutation of a prior log entry must be mathematically detectable, not merely policy-prohibited.
Exportable. Logs must be made available to authorities under Article 72 (incident reporting) and to deployers and downstream users in a format that supports independent inspection.

The “recognised standards or common specifications” phrasing is load-bearing. The regulation does not specify the standard. It places the burden on the provider to choose one that is recognised, and on auditors to validate against it. Picking a proprietary log format does not satisfy this. Picking unsigned application logs does not satisfy this. Picking a standard that was designed for static artifacts and not for streaming transactional evidence does not satisfy this.

Why retrofitting application logs fails for autonomous agents

Traditional software has deterministic execution paths. Instrument those paths, ship to a centralised log store, and you can reconstruct events with high fidelity. Autonomous AI agents break this assumption in three specific ways, covered in detail in an earlier post and summarised here for completeness:

Context resets. LLM-driven agents have bounded context windows. Mid-task, the context compacts or the session ends. If you ask the agent later what it did, the answer is plausible reconstruction, not recall. Logs reconstructed after the fact are log-shaped fiction.
Delegation handoffs. Agents hand work to other agents, to tools, to services. Application logs scatter across whichever systems happened to be touched. No single system holds the attribution chain.
Cross-organisational work. When agents from two organisations collaborate, each side's logs are attributable only to the system that wrote them. Neither party can prove to the other what happened without a shared, verifiable source of truth.

The fix at all three layers is structural rather than behavioural: sign the record at the moment of the event, with cryptographic material that anyone with the public key can verify, and make mutation mathematically detectable. That is exactly what SCITT specifies.

What SCITT specifies

SCITT — the IETF Supply Chain Integrity, Transparency, and Trust working group — defines an architecture and an API surface for registering, retrieving, and verifying signed claims about things. The architecture is currently published as draft-ietf-scitt-architecture-22 (October 2025); the wire-format API is at draft-ietf-scitt-scrapi-10 (latest revision). Neither is an RFC yet, but the architecture text is past working-group last call and the substantive design is stable enough that Microsoft and Google have shipped production implementations against it.

SCITT's four primitives map directly onto the five requirements of Article 12:

Signed Statement. A statement-of-fact about a subject, wrapped in a COSE_Sign1 envelope ( RFC 9052, tag 18). The signer is identified in the COSE protected header; the subject is identified in the payload. Encoded in deterministic CBOR per RFC 8949 §4.2.1.
Transparency Service. A registry that accepts Signed Statements, anchors them in an append-only Merkle tree, and issues a Receipt that proves the inclusion.
SCITT Receipt. A cryptographic inclusion proof (RFC 9162-style Merkle proof, encoded in COSE per draft-ietf-cose-merkle-tree-proofs) that anchors a specific Signed Statement to a specific tree head. Receipts are independently verifiable against the Transparency Service's published keys.
Transparent Statement. The bundle: Signed Statement plus one or more Receipts. Suitable for handing to a third-party verifier who does not need to trust the originating system.

The four-endpoint SCRAPI surface is small on purpose: POST /entries to register a Signed Statement and receive a Receipt; GET /entries/{id} to retrieve a Transparent Statement; GET /.well-known/scitt-keys and GET /.well-known/scitt-keys/{kid} to publish verification material. There is no permission model in the spec; there is no business-logic vocabulary in the spec. That makes the spec composable on top of whatever payload schema the application needs.

The mapping: Article 12 → SCITT primitives

Each Article 12 obligation has a SCITT primitive that satisfies it directly. The right-hand column cites the specific standards-level element that does the work.

Article 12 requirement	SCITT primitive	Standards element
Automatic recording of events	A Signed Statement is emitted by the system at every state transition; registration with the Transparency Service is non-optional in the agent flow.	COSE_Sign1 (RFC 9052), POST /entries (SCRAPI)
Traceability of who, what, when	Issuer identified in the COSE protected header; subject identified in the in-toto Statement payload; timestamp in the Statement; chain of references for multi-step work.	CWT claims (RFC 8392), in-toto Statement v1
Ordered chronology	Append-only Merkle tree maintained by the Transparency Service; each Signed Statement gets an inclusion Receipt anchoring it to a tree head.	RFC 9162 Merkle proofs in COSE (draft-ietf-cose-merkle-tree-proofs)
Tamper-evidence	Ed25519 signature on the COSE_Sign1 envelope plus the Merkle proof witnesses both the content and its position in the global log. Mutation of either is mathematically detectable.	EdDSA (RFC 8032), RFC 9052, RFC 9162
Exportable for audit	Transparent Statements travel in standard COSE_Sign1 wire format and can be verified by any SCITT-aware verifier without coordination with the originating system.	GET /entries/{id} (SCRAPI), GET /.well-known/scitt-keys
Conformance to recognised standards	SCITT itself is the IETF-track standard. The constituent specifications (COSE, CBOR, RFC 9162 Merkle proofs, in-toto Statement, EdDSA) are published RFCs or stable drafts.	draft-ietf-scitt-architecture, draft-ietf-scitt-scrapi, RFC 9052, RFC 8949

Note what is not in the mapping. The regulation does not require any specific signature algorithm; SCITT does not mandate one either. The regulation does not specify what counts as “an event”; SCITT leaves the payload schema to the application. The regulation does not specify retention; SCITT leaves it to the Transparency Service operator. The two specifications align on the cryptographic and structural plumbing and leave domain decisions to the implementer, which is the right boundary.

What SCITT does not address (and what to build on top)

SCITT is small on purpose, and the working group has been explicit about scope. The following are deliberately out of scope, and an AI-agent deployment that needs to satisfy Article 12 (and the surrounding Article 14, 26, 72 obligations) will need to add them on top of SCITT, not inside it:

Cross-Transparency-Service coordination. draft-ietf-scitt-architecture-22 is explicit in its scope statement: “how participating entities discover and notify each other of changes is out-of-scope of this document.” SCITT accommodates the same Signed Statement being registered with multiple Transparency Services (§5, §6.3, §7) and bundling those Receipts together. What SCITT leaves out is cross-TS coordination: propagating state transitions or verdicts across TS boundaries, and discovery between TSs. That gap is the federation layer.
Domain-specific payload schemas. SCITT carries an opaque payload inside the Signed Statement (in-toto v1 Statement is the convention, but the predicate is application-defined). For Article 12 compliance, you will need a versioned, content-addressed schema for the predicate describing your specific record class. An “automated decision” predicate looks different from a “content moderation outcome” predicate looks different from a “loan recommendation” predicate.
Verdict and dispute structure. SCITT registers signed claims. It does not model the lifecycle of those claims (created, accepted, completed, verdict rendered, disputed, remediated). Article 12 requires recording events over the lifetime of the system; a lifecycle model on top of SCITT is what allows the chain to express what the system did from end to end.
Downstream commercial integration. When a verdict is rendered on a cross-organisational record — say, a federated agent transaction where money moves — the verdict needs to flow into the payment, ERP, or ticketing system that actually authorises value transfer. SCITT does not specify this. An outbound webhook layer keyed to verdict-state transitions is needed.
Operator deployment shape. SCITT specifies the API; it does not specify whether the Transparency Service is hosted by the application provider, by the regulator, by a third party, by the customer themselves. For Article 12 compliance under typical deployer-obligation structures, customer-hosted is the right answer; SCITT accommodates this but does not require it.

None of these gaps are problems with SCITT. They are application decisions that any implementation has to make, and the SCITT architecture is explicit about not making them for you. The useful framing is: SCITT is the cryptographic and structural substrate; the lifecycle model, the cross-org transport, and the downstream integration are the layer above.

A concrete implementation pattern

Below is the minimum-viable shape of an Article-12-conformant event record for an autonomous AI agent, expressed in pseudo-code. The record is what the system would register with its Transparency Service when the agent begins work on a task.

# Signed Statement registered at POST /entries

# COSE_Sign1 envelope (RFC 9052, tag 18)
protected_headers = {
  alg:  -8,                                   # EdDSA
  kid:  "did:web:agledger.example.com#k-1",   # signer key
  cty:  "application/vnd.in-toto+json",       # payload type
  iss:  "did:web:agledger.example.com",       # CWT claim, RFC 8392
  sub:  "agent://[email protected]",       # CWT claim
}

# Payload — in-toto v1 Statement (canonical CBOR per RFC 8949 §4.2.1)
payload = {
  _type:       "https://in-toto.io/Statement/v1",
  subject:     [{
    name:   "task://customer-refund/2026-05-20T14:32:11Z/r-9f7e",
    digest: { sha256: "9c4f..." }
  }],
  predicateType: "https://agledger.ai/predicate/record-state/v1",
  predicate: {
    phase:          "intent",
    contractType:   "REFUND-WORKFLOW-v1",
    contractDigest: "sha256:8e2a...",
    criteria:       { customerId, refundAmount, reasonCode },
    principal:      "agent://[email protected]",
    performer:      "agent://[email protected]",
    notarizedAt:    "2026-05-20T14:32:11Z",
  }
}

signature = Ed25519_sign(SigStructure(protected_headers, payload))

The agent registers this record with the Transparency Service at the moment it begins work. The Service returns a Receipt — a Merkle inclusion proof anchored to the current tree head — which the agent stores alongside the original Statement. When the agent finishes, it registers a second Signed Statement (predicate type record-state/v1 with phase: "result" and the completion evidence) referencing the first. Two registrations, both signed, both proven into the same tree, with a verifiable chain of references. That is the Article 12 spine for a single agent task.

For a workflow that delegates, where agent A hands part of the task to agent B, the same primitives compose. Agent B registers its own Signed Statements with its own keys; the reference field in the predicate links back to agent A's statement. The chain spans both agents and is independently verifiable end to end.

For cross-organisational work, the chain crosses Transparency Service boundaries. SCITT does not specify how. An implementation must choose: replicate Signed Statements directly between Services (federated registration), exchange Receipts only (federated witness), or transport state transitions as signed messages with the underlying data staying local (federated message passing). Each has different evidence and data-sharing properties; that choice is the federation layer above SCITT.

Why this matters now, regardless of the enforcement date

EU AI Act high-risk-system obligations technically apply from 2 August 2026. A November 2025 European Commission proposal to slip those obligations to late 2027 exists but has not been enacted as of this writing; counsel guidance from major firms continues to treat August 2026 as binding. Whether the date holds or slips, three converging signals suggest the engineering work is not optional:

Microsoft Signing Transparency has shipped a SCITT-aligned, COSE-based attestation surface in Azure (announced 2025). That production deployment validates that the architecture is stable enough to bet on, even before the IETF documents become RFCs.
Google Android Binary Transparency went live in production on 1 May 2026, a SCITT-shaped transparency log over Merkle-anchored signed claims. Different use case, same architecture.
OECD AI Principles (2024 revision) moved traceability and accountability provisions out of Robustness and into Accountability, reflecting a global consensus that signed audit trails are about who is on the hook, not about whether the system performs.

The convergence is the point. Whether the enforcement deadline for Article 12 is August 2026, late 2027, or some later date the Commission settles on, the engineering pattern — signed, chained, independently verifiable records of automated work — is what every regulatory frame is asking for. Build for the pattern; the date becomes a calendar issue, not a re-platforming issue.

One implementation

AGLedger is one implementation of this pattern. The chain envelope is COSE_Sign1 (RFC 9052, tag 18) over in-toto v1 Statement payloads, deterministically CBOR-encoded per RFC 8949 §4.2.1, Ed25519-signed. The SCRAPI surface is at /v1/scitt/entries with verification keys at /.well-known/scitt-keys. SCITT Receipts are opt-in via ?receipts=true on audit-export. The lifecycle model on top of SCITT is the two-mode (Notarize / Verify) structure described on /how-it-works; the federation layer is at /federation; the downstream commercial bridge is Settlement Signals, a three-state webhook (SETTLE / HOLD / RELEASE) tied to terminal verdicts, filed under US patent application 19/565,072.

Other implementations exist for adjacent use cases: Microsoft Signing Transparency for software supply chain, Google Android Binary Transparency for binary integrity. As the SCITT specifications converge to RFC status, more should follow. The question for an enterprise running autonomous AI agents in production is not whether to pick a SCITT-aligned implementation but which one fits the operational and governance constraints of the deployment. Self-hosted matters when the regulator's view of the deployer obligation favours customer-owned evidence; cross-org coordination matters when agents work across organisational boundaries; downstream commercial integration matters when verdicts authorise value movement.

The point of writing this post is not to sell an implementation. It is to put a name to a category. Article 12 does not require SCITT specifically; the regulation requires conformance to recognised standards. SCITT is the IETF-track standard that was designed for exactly this evidence shape, and it is the standard that is most likely to be the one a future-regulator recognises. Building toward it now, regardless of which implementation, is the engineering bet that survives any specific enforcement timeline.

Sources and further reading

Regulation

SCITT

RFCs

Payload format

in-toto Statement v1 specification

Production deployments

Companion frames

SCITT as the Article 12 Implementation Pattern for Autonomous AI Agents