RFC 3161 is the IETF standard for trusted timestamping. A Time-Stamping Authority (TSA) receives a hash of your data and the current UTC time, signs them together, and returns a timestamp token. The token contains no copy of your data — only the hash and the signed time. Any third party can verify the token offline, against the TSA's public certificate, without access to your systems.

Why does an AI audit log need RFC 3161?

A hash-chained log proves internal consistency — the records have not been edited relative to each other. RFC 3161 adds external proof: at a specific moment in time, this exact hash existed. Without it, the chain is your word against an adversary's. With it, a regulator, auditor or court can independently verify the evidence.

Does RFC 3161 make AI audit logs court-admissible?

RFC 3161 tokens are accepted as evidence in EU and US courts under eIDAS qualified trust services and FRE 902(13) self-authenticating electronic records. Court admissibility ultimately depends on jurisdiction, evidentiary procedure and the specific TSA's status — but RFC 3161-stamped logs are routinely accepted as the technical foundation for proving record integrity.

Which Agent Audit tiers include RFC 3161 notarisation?

RFC 3161 notarisation is included on the Professional and Enterprise tiers. Every chain head advance is automatically notarised by the configured Time-Stamping Authority and stored alongside the receipt chain. The Free Dev and Starter tiers provide hash-chain integrity but not external notarisation.

Can I verify an RFC 3161 token without contacting Agent Audit?

Yes. The agentaudit-verify CLI decodes the base64 token, parses the RFC 3161 TimeStampResp, extracts the TSTInfo, and confirms the signed message imprint matches the chain head hash in your evidence pack. The verification is completely offline — no network call to Agent Audit is required.

RFC 3161 timestamping for AI audit logs

8 June 2026 · 9 min read · By Hak Bahsoon

For an AI agent audit log, RFC 3161 solves the "prove it existed then" problem. A hash-chained log gives you internal consistency: the records are mathematically bound to each other, so retroactive editing is detectable. What it does not give you is a binding to wall-clock time. A regulator can still ask "how do we know you didn't generate the whole chain yesterday, after the incident?" RFC 3161 is the answer.

The two halves of audit-log integrity.

A defensible AI agent audit log needs two distinct guarantees, and most teams confuse them.

Internal integrity. Has the log been edited since it was written? A SHA-256 hash chain — each receipt's body hash embedded as the next receipt's prev_hash — makes any in-place edit mathematically detectable. Even a single-byte change cascades and breaks every subsequent hash.
External integrity. Did the log exist at the time it claims to have existed? A hash chain alone cannot prove this. Without an external anchor, a sufficiently motivated adversary could generate the entire chain in a single afternoon after an incident. RFC 3161 timestamping is the standard anchor: the TSA's signed receipt is the cryptographic statement "at moment T, this hash existed".

Together they give you what regulators and auditors actually need: contemporaneous, tamper-evident evidence. Retention without notarisation is just expensive storage. Notarisation without retention is just a record of records that no longer exist.

How an RFC 3161 round-trip actually works.

The exchange between a client and a TSA is intentionally simple — designed in 2001 to be embedded in PKI and CMS pipelines.

The client computes a cryptographic hash of the data to be timestamped (SHA-256 is universal in 2026).
It builds a TimeStampReq ASN.1 structure containing only the hash algorithm OID and the hash bytes. No copy of the data leaves the client.
It sends the request over HTTPS to the TSA.
The TSA signs a TSTInfo structure containing the original hash, the TSA's policy OID, a unique serial number, and the current UTC time. The signature is wrapped in a CMS SignedData envelope and returned as a TimeStampResp.
The client stores the TimeStampResp alongside the original data. Verification is later done against the TSA's published signing certificate — no further contact with the TSA is required.

The whole exchange typically completes in 200-400ms. The token is compact (typically 4-8 KB) and self-contained, so storage cost is negligible relative to the data being timestamped.

What this looks like in an Agent Audit pack.

Every chain head advance — the rolling hash of the last receipt in a session — is sent to the configured TSA and the returned token is persisted in chain_notarisations. The Agent Audit export pack manifest carries every notarisation record:

{
  "notarisations": [
    {
      "head_hash":      "8f3e2a1b...",
      "timestamp_at":   "2026-06-08T11:14:22Z",
      "tsa_name":       "FreeTSA",
      "tsa_serial":     "29384756120",
      "token_b64":      "MIIIRgYJKoZI..."
    }
  ]
}

An auditor runs agentaudit-verify pack.json. The CLI decodes token_b64, parses the DER as an RFC 3161 TimeStampResp, extracts the TSTInfo, and compares the messageImprint.hashedMessage against the head hash in the manifest. On mismatch the CLI exits 1 with the failing event ID. No network round-trip to Agent Audit is involved.

Choosing a TSA — and why we let you choose.

Not all TSAs are equal. The decision points are:

Factor	What it means	What we default to
Jurisdiction	The TSA's signing certificate is issued under a national PKI. UK firms typically prefer a UK or EU TSA for evidentiary alignment.	FreeTSA (Germany) on Free Dev. Customer-configurable on Professional and above.
eIDAS qualification	Qualified Trust Service Providers under eIDAS are accepted as evidence across all EU member states without further proof of process.	Sectigo, GlobalSign and other qualified TSAs are first-class options on Professional+.
Cost per stamp	Free TSAs are subject to fair-use throttling; paid TSAs charge per stamp or per volume bundle.	FreeTSA covers Free Dev; bundled Sectigo allocation included with Professional.
Independence from vendor	If the TSA is operated by your audit-log vendor, the cryptographic argument is weaker. Independent TSAs are preferred.	Agent Audit does not operate a TSA. Every supported TSA is independent of us.

Common questions auditors ask about RFC 3161.

A short field guide.

"Is this the same thing as a blockchain?" No. Blockchain timestamping anchors a hash in a distributed ledger. RFC 3161 anchors a hash in a single signed message from a trusted authority. RFC 3161 is faster, cheaper, and has 25 years of legal precedent. Blockchain anchoring is occasionally added as a defence-in-depth measure but is not a substitute.

"What if the TSA is compromised?" A TSA compromise would let an attacker mint timestamps for arbitrary hashes — but only inside the compromise window, and only with the compromised TSA's identity. Using independent TSAs from different jurisdictions, or stacking eIDAS qualified TSAs with a separate root, mitigates this. The agentaudit configuration supports multiple TSAs per tenant for exactly this reason.

"Why not just sign with our own key?" Self-signed timestamps prove nothing to a third party — anyone can sign anything with their own key. The whole point of RFC 3161 is that the TSA is a trusted third party whose attestation is verifiable without the verifier needing to trust you.

Where RFC 3161 sits in the Agent Audit stack.

RFC 3161 is one layer of the integrity story. The full stack:

SDK: emits a hash-chained receipt for every agent action. Each receipt's body_hash is computed at capture.
Backend: on receipt ingest, advances the chain head per (tenant, agent, session) and persists it in chain_heads.
Notarisation: after every chain-head advance the new head hash is sent to the configured TSA. The returned RFC 3161 token is persisted in chain_notarisations.
Pack: the evidence pack manifest carries every receipt's hash, the chain head per session, and every notarisation token.
Verify: the agentaudit-verify CLI replays the chain offline and cryptographically validates every RFC 3161 token against the pack's head hashes.

The result is an evidence pack where every step from "agent action occurred" to "regulator presented with proof" is independently verifiable, without needing to trust anyone in the middle — including Agent Audit.

RFC 3161 timestamping for AI audit logs — why it matters.