How SWT3 Aligns with IETF Agent Audit Trail Requirements

Audience: Standards body participants, protocol engineers, AI governance architects, and compliance tool vendors evaluating agent audit trail specifications. Also relevant for organizations implementing audit infrastructure ahead of formal standardization.

CRITICAL ASSESSOR NOTICE: SWT3 witness anchors are evidence artifacts, not compliance determinations. Each anchor records that a governance-relevant event occurred and preserves its cryptographic fingerprint. The assessor determines whether the evidence satisfies a given control requirement. The protocol does not make pass/fail compliance decisions on behalf of any regulatory body. Substance verification remains the assessor's responsibility.

Context: draft-sharif-agent-audit-trail defines a JSON-based logging format for AI agent operations. The draft expires September 29, 2026. SWT3 is a deployed, production-grade implementation that satisfies every mandatory field in the draft and exceeds it in four critical areas. This document maps the alignment field by field.

Also of note: draft-maintainer-1f916-agent-record describes "Witness-Countersigned Event Logs" with Ed25519 signatures and Merkle trees -- an architecture that closely parallels SWT3's existing implementation (deployed since early 2026).

1. IETF Draft Overview

The Internet Engineering Task Force (IETF) has published several Internet-Drafts addressing AI agent accountability. The most directly relevant is draft-sharif-agent-audit-trail, which defines a structured JSON format for recording agent actions, decisions, tool invocations, and outcomes.

The draft specifies mandatory fields for:

Agent identifier
Action type
Timestamp
Input/output hashes
Tool identifier
Decision rationale
Outcome status
Session identifier

Key design decisions in the draft:

Format: JSON (not binary)
Hashing: SHA-256 for content integrity
Chaining: Sequential chaining via previous-entry hash
Privacy: No privacy graduation mechanism
SDK: No multi-language SDK specification
Signing: No cryptographic signing requirement (recommended but optional)

The draft establishes a baseline. It answers "what fields should an agent audit record contain?" It does not answer how those records should be protected, graduated across jurisdictions, or verified independently. SWT3 answers all three.

2. Field-by-Field Alignment

The following table maps every field defined in draft-sharif-agent-audit-trail to its SWT3 equivalent. "Mandatory" and "Recommended" designations follow the draft's own requirement levels.

IETF Required Field	SWT3 Equivalent	Notes
`agent_id` (mandatory)	`agent_id` field on WitnessPayload	Populated via `AI-ID.1` or constructor config. Survives all clearing levels.
`action_type` (mandatory)	`procedure_id`	275 typed procedures across 9 namespaces vs a generic string. More granular than the draft requires.
`timestamp` (mandatory)	`anchor_epoch` + `fingerprint_timestamp_ms`	Millisecond precision. RFC 3161 TSA available on Merkle rollups for third-party non-repudiation.
`input_hash` (mandatory)	`factor_a`	Procedure-specific factor encoding. SHA-256 based. Semantics defined per procedure in the UCT Registry.
`output_hash` (mandatory)	`factor_b`	Procedure-specific factor encoding. Meaning varies by procedure (latency, hash, count).
`tool_id` (recommended)	`AI-TOOL.1` `tool_name` in `ai_context`	Dedicated procedure for tool witnessing. Records tool name, latency, and success/failure.
`decision_rationale` (recommended)	`ai_context` (clearing level <= 1)	Available at clearing levels 0 and 1. Stripped at higher clearing levels for privacy graduation.
`outcome_status` (mandatory)	Verdict (`PASS` / `FAIL`)	Computed from evaluation expression per procedure. Binary, deterministic, reproducible.
`session_id` (mandatory)	`cycle_id`	Links all anchors in a decision chain. Enables forensic reconstruction of multi-step agent workflows.
`previous_entry_hash` (recommended)	Merkle tree rollup	Domain-separated daily rollups (SWT3:LEAF: / SWT3:NODE: prefixes) vs sequential chaining. See Section 3.2.
`signature` (recommended)	`payload_signature`	HMAC-SHA256 with `signing_key`. Ed25519 for W3C Verifiable Credentials. Signing is a first-class feature, not optional.

Key observation: Every mandatory field in the IETF draft has a direct equivalent in SWT3. Every recommended field is implemented as a production feature. SWT3 has been recording these fields in production since early 2026 -- before the draft was published.

3. Where SWT3 Exceeds the Draft

The IETF draft establishes a minimum schema. SWT3 exceeds that minimum in four areas that address real-world deployment constraints the draft does not cover.

3.1 Clearing Levels (Privacy Graduation)

Gap in the draft: No privacy mechanism. Audit records are all-or-nothing. Every field is either present or absent. There is no way to produce different evidence fidelity for different jurisdictions or classification levels from the same event.

SWT3's 4-level clearing engine solves the fundamental tension between privacy regulation and audit requirements:

Level	Name	What Leaves the Wire
0	Analytics	Full metadata, model names, prompt context
1	Standard	Structured factors, model identifiers, no raw content
2	Sensitive	Hashed identifiers, numeric factors only
3	Classified	Cryptographic fingerprint and verdict only. All descriptive metadata stripped.

GDPR says "minimize personal data collection." SOX says "record everything material." The EU AI Act says "maintain detailed logs." These requirements appear contradictory. Clearing levels make all three satisfiable from a single witness pipeline by graduating what evidence leaves the wire based on jurisdiction and classification. The same governance event produces different evidence fidelity at different clearing levels, and the fingerprint remains verifiable at every level.

No competing implementation of privacy-graduated audit trails exists. Patented.

3.2 Merkle Rollups with RFC 3161 TSA

Gap in the draft: Sequential hash chaining. Each entry includes the previous entry's hash. This provides O(n) proof verification -- to verify entry #10,000, you must process all 9,999 prior entries.

SWT3 uses domain-separated Merkle trees with daily rollups:

Domain separation: SWT3:LEAF: and SWT3:NODE: prefixes prevent second-preimage attacks across tree levels
Proof complexity: O(log n) verification vs O(n) for sequential chains. Verifying one anchor in a tree of 10,000 requires ~14 hash operations, not 10,000
RFC 3161 timestamps: Daily roots are timestamped by trusted third parties (DigiCert, Sectigo, FreeTSA). This provides non-repudiation independent of the platform operator
Post-quantum signatures: ML-DSA-65 signatures on Merkle roots provide forward security against quantum computing threats

The draft's sequential chaining is simpler to implement but does not scale. For a ledger with millions of entries, proving the integrity of a single record requires replaying the entire chain. Merkle trees reduce this to a logarithmic proof path that any verifier can check independently.

3.3 Multi-Language SDK Parity

Gap in the draft: No reference implementation. The specification defines a JSON schema but provides no SDK, no library, and no test vectors. Implementers must build from scratch with no way to verify correctness against a canonical implementation.

SWT3 ships production SDKs in 10 languages:

Language	Package	Registry
Python	`swt3-ai`	PyPI
TypeScript	`@tenova/swt3-ai`	npm
Go	`swt3-ai-go`	pkg.go.dev
Rust	`swt3-ai`	crates.io
C#	`swt3-ai`	NuGet
Ruby	`swt3-ai`	RubyGems
Swift	`swt3-ai`	Swift Package Index
Kotlin	`swt3-ai`	Maven Central
MCP Server	`@tenova/swt3-mcp`	npm
K8s Agent	`swt3-witness`	GHCR (OCI)

Cross-language fingerprint parity is verified by 13 test vectors in test-vectors.json. The fingerprint formula is locked: SHA256("WITNESS:{tenant}:{proc}:{fa}:{fb}:{fc}:{ts_ms}").hex()[:12]. Every SDK produces identical output for identical input. An anchor minted in Python can be verified in Rust, Go, or any other implementation without ambiguity.

3.4 W3C Verifiable Credential Export

Gap in the draft: No interoperability mechanism beyond JSON. Audit records are platform-specific. There is no way for a third party to independently verify an audit record without trusting the platform that produced it.

SWT3 exports compliance evidence as W3C Verifiable Credentials:

Signing: Ed25519 with eddsa-jcs-2022 proof suite
Issuer DID: did:web:sovereign.tenova.io -- resolvable DID document at /.well-known/did.json
Verification: Any standards-compliant W3C VC verifier can validate the credential without contacting the issuing platform
Revocation: StatusList2021Entry with public status endpoint for credential lifecycle management

This bridges the gap between internal audit records and external trust. A regulator, auditor, or counterparty can verify the credential independently using any W3C VC toolkit. The evidence is portable, self-verifiable, and not locked to any vendor's API.

The IETF has published several additional Internet-Drafts relevant to AI agent accountability. SWT3's architecture predates these drafts but addresses many of the same requirements.

draft-maintainer-1f916-agent-record

This draft describes "Witness-Countersigned Event Logs" with Ed25519 signatures and Merkle trees, drawing parallels to RFC 6962 (Certificate Transparency). The architecture it proposes -- cryptographic witnesses that countersign agent event logs and roll them into Merkle trees for tamper-evident storage -- closely mirrors SWT3's existing implementation. SWT3 has been deploying this exact pattern (Ed25519 signing, domain-separated Merkle trees, daily rollups with RFC 3161 timestamps) since early 2026. The draft validates the architectural direction. The implementation already exists.

draft-ihsanullah-dnsid

DNSid proposes DNS-anchored agent identity, using DNS TXT or SRV records to associate agent identifiers with domain-verified operators. This is complementary to SWT3's did:web approach. Both use DNS as a trust root -- did:web resolves via HTTPS to a DID document; DNSid resolves via DNS records directly. The approaches are not mutually exclusive. An agent could carry both a did:web identifier (for W3C VC ecosystems) and a DNSid record (for DNS-native verification).

draft-somoza-dmsc-atn-agent-trust-negotiation

The Agent Trust Negotiation (ATN) protocol addresses how agents establish trust with each other before exchanging data or delegating tasks. SWT3's AI-TRUST.1 and AI-TRUST.2 procedures (trust verification and credential presentation) address the same problem space at the evidence layer. ATN defines the negotiation handshake; SWT3 witnesses and records the outcome of that handshake for audit purposes.

5. Implementation Status

SWT3 is not a proposal. It is a deployed system with production usage across multiple registries.

Capability	Status
Production deployment	Since early 2026
SDKs published	10 languages across 11 package registries
Total downloads	42,000+
Procedures	275 across 9 namespaces
MCP tools	63
Frameworks crosswalked	77
Daily Merkle rollups	Active with RFC 3161 TSA
W3C VC export	Live (Enclave+ tier)
Fingerprint formula	Locked, cross-language parity verified (13 test vectors)
Post-quantum signatures	ML-DSA-65 on Merkle roots

Deployment timeline: SWT3's witness architecture, Merkle rollups, and Ed25519 signing were deployed before the IETF drafts referenced in this guide were published. The alignment documented here is convergent -- the IETF working groups arrived at similar architectural conclusions independently, validating the design decisions SWT3 made in production.

6. References

IETF draft-sharif-agent-audit-trail -- JSON-based audit trail format for AI agent operations
IETF draft-maintainer-1f916-agent-record -- Witness-Countersigned Event Logs with Ed25519 and Merkle trees
RFC 3161 -- Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
RFC 6962 -- Certificate Transparency
W3C Verifiable Credentials Data Model v2.0 -- https://www.w3.org/TR/vc-data-model-2.0/
SWT3 Protocol Specification -- https://sovereign.tenova.io/docs/
UCT Registry -- https://sovereign.tenova.io/registry/