Trusted timestamps for AI agent logs: what RFC 3161 proves, and what it does not

Every record an AI agent leaves behind carries a time. A tool call was logged at 14:02:11, a file was written at 14:02:13, a receipt was signed at 14:02:14. When an action is disputed, the time is often the first thing that matters: was the agent's change made before or after the incident, before or after the approval, before or after the policy changed? Most of those times were written by the system under question, using its own clock. This piece looks at what it takes to make a time on an agent record something a third party can rely on, starting with the standard most people search for, RFC 3161.

A signature tells you who, not when

A digital signature binds a key to a sequence of bytes. If the bytes include a time, the signature covers that time, but it says nothing about whether the time was true when the signer wrote it. An operator who wants to backdate a record simply writes an earlier time and signs it. The result verifies perfectly.

Our own receipts have exactly this property, and the receipt specification says so. A receipt carries execution.timestamp and attestation.attested_at, both ISO 8601 UTC strings supplied by the operator. Section 6.3 notes that a verifier with access to the operator's hash-chained audit log can detect replayed or out-of-order receipts, while "a verifier without audit log access cannot detect replays; they can only verify that the receipt is internally consistent." A valid signature on a receipt proves which key signed it and that nothing has changed since. It does not prove the moment of signing to anyone who does not already trust the operator's clock.

Closing that gap needs a party other than the signer to say something about time. There are two well-established ways to get one: a time-stamping authority, or a public append-only log that someone else is watching.

What RFC 3161 actually specifies

RFC 3161, published in August 2001, defines the Time-Stamp Protocol. In its words, a time-stamping authority (TSA) "is a TTP that creates time-stamp tokens in order to indicate that a datum existed at a particular point in time." The client sends a hash, the TSA returns a signed token over that hash and the time. Section 2.1 lists what the TSA is required to do, and several of those requirements matter for agent records:

• It sees only a hash. The TSA must "only time-stamp a hash representation of the datum" and must not examine the imprint beyond checking its length. You can timestamp a receipt that contains sensitive inputs without sending the inputs anywhere.
• It does not record who asked. Tokens must not include "any identification of the requesting entity". The token says that this hash existed at this time, not who held it.
• It must use a trustworthy time source and include a unique serial number in every token, a property the RFC says must survive a crash of the service.
• It names a policy. Each token carries an identifier for the security policy it was issued under. The RFC deliberately leaves operational security to that policy rather than to the protocol, so what a token is worth depends on which TSA issued it.

Inside the token, the genTime field holds the time in UTC, and an optional accuracy field gives the margin either side. RFC 5816 updated the protocol in 2010 so that the TSA's certificate can be identified with a hash other than SHA-1.

Producing a request

OpenSSL ships a client and a minimal TSA in openssl ts. Building a request is local and sends nothing over the network. This is the output on our build box with OpenSSL 3.5.7, with the ASCII column trimmed:

$ openssl ts -query -data receipt.json -sha256 -cert -no_nonce -out receipt.tsq
$ openssl ts -query -in receipt.tsq -text
Version: 1
Hash Algorithm: sha256
Message data:
    0000 - 03 07 47 87 d1 95 c2 ff-03 66 c8 a4 5f 44 90 e6
    0010 - 83 86 00 6b 26 dc 60 2a-0e 2a 3d ef a1 06 00 43
Policy OID: unspecified
Nonce: unspecified
Certificate required: yes

The request is posted to a TSA, which returns a response file. Verification takes the original data, the response and the TSA's CA certificate. The manual requires at least one of -CAfile, -CApath or -CAstore:

$ openssl ts -verify -data receipt.json -in receipt.tsr -CAfile tsa-ca.pem

We have not sent a request to a public TSA for this article, so the response side is shown as the documented command rather than captured output. The -no_nonce option we used for the local example removes the nonce; against a live service you would normally keep it, because the nonce is how a client with no reliable clock of its own checks that the response is fresh.

What a token proves, and what it leaves open

A valid token establishes one thing: the hashed data existed no later than genTime, give or take the stated accuracy. That is a useful property, and it is narrower than it first looks.

• It is an upper bound only. The token says the receipt existed by 14:02:15. It does not say the agent acted at 14:02:11, or that the receipt was not prepared hours earlier and stamped later. If you also need a lower bound, the record has to contain something that could not have been known before a given moment, such as a value published by an outside party at a known time.
• It says nothing about the content. The TSA never sees the receipt. A false record stamped promptly is still false; the token only fixes when it existed.
• Ordering is limited by accuracy. Section 2.4.2 states that, unless the TSA sets the ordering flag, two tokens can only be ordered when the gap between their times is greater than the sum of their accuracies. Two agent actions a few hundred milliseconds apart may not be orderable from their tokens alone.
• It depends on one key. The security considerations warn that if a TSA's private key is compromised, "any token signed by the TSA using that private key cannot be trusted anymore", and backdated tokens become possible. They suggest tokens from two different TSAs as one defence.
• It ages. The same section notes that a TSA key "will have a finite lifetime", so tokens that must outlast it should be time-stamped again later. Agent records kept for regulatory retention periods fall into this category.

Where the law gives timestamps weight

In the EU, the eIDAS Regulation (Regulation (EU) No 910/2014) gives electronic time stamps a defined legal status. In the text as adopted, Article 41(1) says an electronic time stamp "shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements of the qualified electronic time stamp." Article 41(2) goes further for qualified stamps, which "shall enjoy the presumption of the accuracy of the date and the time it indicates and the integrity of the data to which the date and time are bound."

A qualified stamp has to meet the requirements in Article 42(1): it binds date and time to the data so as to "reasonably preclude the possibility of the data being changed undetectably", it is "based on an accurate time source linked to Coordinated Universal Time", and it is signed or sealed by a qualified trust service provider. The practical difference is the burden of proof. A self-asserted time can be argued about. A qualified time stamp is presumed correct unless someone shows otherwise.

The other route: a log someone else is watching

A transparency log gets a time bound differently. Records are appended to a Merkle tree, and the log periodically publishes a signed checkpoint: its size and root hash. On its own, the log operator's checkpoint is another self-asserted statement. It becomes evidence about time when an independent witness cosigns it.

The C2SP cosignature format puts a timestamp inside the witness's signature and defines what it means: "as of the specified time, the consistent tree head with the largest size the cosigner has observed for the log identified by the origin line has the specified root hash." Any entry included in that tree therefore existed no later than the cosigned time, on the word of a party that is not the log operator.

Our own log works this way. At the time of writing, the checkpoint at log.traceseal.io/checkpoint is at tree size 24, and the copy held by the Markovian Protocol witness carries a cosignature with the timestamp 1787078705, which is 18 August 2026, 18:45:05 UTC. We checked the log signature and the cosignature against the published keys before publishing this article. So any of the first 24 entries existed by that moment, whatever times their own records claim. Our piece on transparency log witnesses explains the checks a witness performs.

The two routes are not equivalent. A TSA commits to a time-source policy, and a qualified one carries a legal presumption. A witness makes no claim about the quality of its clock beyond what its operator publishes; what it adds is that it refuses to cosign a tree that is inconsistent with one it has already seen, which defends against an operator showing different histories to different people. A TSA token does not give you that.

A workable setup for agent records

For a team that needs agent actions to be datable by someone outside the team, the pieces fit together in a fairly direct way:

1. Sign each record at the point of action, with a key the agent cannot reach, so the content and the signer are fixed. Our primer on signed receipts covers why the key placement matters.
2. Get an independent upper bound on time. Either request an RFC 3161 token over the record's hash, or append the hash to a log whose checkpoints an independent witness cosigns. Where records may be used in EU proceedings, consider a qualified TSA.
3. Add a lower bound if the order of events matters, by including in the record a value that only became public at a known time.
4. Plan for renewal if retention runs for years, by re-stamping before the TSA key or certificate expires.

Traceseal currently covers the first step with signed receipts and the second through log inclusion and witness cosigning. It does not attach RFC 3161 tokens to receipts, and the receipt's own time fields remain operator-asserted. Anyone who needs a qualified timestamp today can request one over a receipt's hash, since the receipt is a stable file and the TSA never needs to see its content.