Proofs, not promises
Agents act on their own. The record of what they did is the only control surface you keep, and a record that can be rewritten is not evidence, it is a story. As of v1.17.0, xNAUT can sign that record on a Securosys HSM in Switzerland. This is the full reasoning: what a hash chain honestly proves, where it stops, why hardware closes the gap, and what a signature still cannot do.
The problem a launch post exposed
When I posted about launching NautGate, someone at Securosys read it and put her finger on the weak spot within a day. NautGate chains every routing decision into a tamper-evident log: each row carries the hash of the row before it, so editing any row breaks every hash after it. That is real protection, and it is also a promise with a hole in it. A chain proves nobody edited a row. It cannot prove nobody rewrote the whole file from the first row on. Anyone with write access to the database can regenerate the entire chain in seconds and the result is internally perfect.
Our own documentation for the privacy log said it plainly: no key management, no PKI. The gap was known. What she supplied was the reason to close it now rather than someday.
Why hardware, specifically
The rewrite attack works because everything the log's integrity depends on lives inside the same trust boundary: the database, the operator, the machine. Move one thing outside that boundary and the attack dies. That thing is a private key that physically cannot leave a hardware security module.
The HSM signs the head of the chain. One signature over the head covers every row before it, because the chain already binds them together; signing every row would put a network round trip on the hot path and prove nothing extra. To forge history now, an attacker needs more than database access. They need Securosys' hardware to sign their rewritten head, and the hardware will not, because the key never leaves it. Not policy. Physics.
This is also why we did not reach for a software signing key in a file or a cloud KMS entry. A key on disk sits inside the same trust boundary as the database it is supposed to check. A cloud KMS is better, but you are trusting an account, and accounts get owned. An HSM's private half is not readable by anyone, including us, including Securosys.
One key, many subjects
The first design draft had a key per use case. We deleted that. One configured key signs whatever it is handed, and the subject is a label on the receipt: nautgate.privacy_log for the chain head, xnaut.agent-work for an agent's finished work, a release digest, anything. A receipt is small: subject, digest, algorithm, key name, signature, timestamp. More keys would mean more custody problems and nothing extra proven.
Verify it without trusting us
A proof you can only check through the party who made it is a promise wearing a costume. So verification deliberately needs nothing from us:
- xnaut.dev/attest verifies a receipt in your browser with WebCrypto, against the published public key.
- If you do not trust the page either, download the public key and the receipt and run one line of stock OpenSSL:
openssl dgst -sha256 -verify XNAUT_ATTEST_KEY.pem -signature sig.bin digest.binNo account, no API, no xNAUT install. The math answers.
What a signature does not prove
Honesty is the whole product here, so the limits get stated as clearly as the claims.
- It does not prove the log told the truth when it was written. The signature covers the record from the moment of signing onward. If the software lied into the log before that, the lie is signed along with everything else. The chain narrows the window for tampering to the gap between an event and the next seal; it does not eliminate the need for the logging code to be honest. That code is open source, which is the other half of the answer.
- It cannot prove what never entered the system. "We can prove nothing was sent to the model" holds only if all traffic actually goes through the gate. That is an architecture decision you make, and then the signed chain covers it.
- A receipt is only as meaningful as its subject. Signing a typo produces a signature that verifies perfectly and means nothing, which is why the plugin refuses anything that is not a proper digest.
The regulators got there first
This is not a future concern. The EU AI Act's high-risk provisions entered full application on 2 August 2026, two weeks before this post. Article 12(1) is one sentence long:
— Regulation (EU) 2024/1689, Article 12(1)
Article 19 then makes providers keep those logs "for a period appropriate to the intended purpose of the high-risk AI system, of at least six months", and deployers carry a mirror duty under Article 26. Manual notes do not count; the recording must be automatic, by the system itself. Non-compliance fines in the Act run to 15 million euro or 3 percent of global turnover.
Notice what the Act asks for and what it quietly assumes. It demands logs exist and survive. It assumes they can be believed. An auditor cannot make that assumption, and the audit literature is blunt about why: a log whose integrity can be challenged is not evidence. Tamper-resistance (making changes hard) is not tamper-evidence (making changes mathematically detectable), and compliance frameworks from SOX to ISO 27001 to Germany's GoBD ask for the second. SOX Section 802 goes further and criminalises altering records relevant to an investigation. A signed chain head is the cheapest way to make six months of agent logs demonstrably unaltered instead of hopefully unaltered.
There is also a separation-of-duties argument hiding in here that auditors care about deeply: the people who can change a system must not be able to quietly change the record of those changes. Inside one database, that separation is an access-control policy. With the signing key in an HSM, it is structural. The operator of the log can no longer be its forger, even in principle, and that is a sentence you can say to an auditor with a straight face.
Upgrades are attestations too
The same mechanism covers a question every enterprise change process asks and almost none can answer cryptographically: is the software running in production the exact thing that was reviewed and approved? Change-management audits trace who approved what change and when, and the classic failure is that the evidence is a timestamp, and timestamps are forgeable; a backdoor implanted yesterday can carry last year's date. A digest cannot be backdated, and a hardware signature over that digest cannot be minted after the fact by anyone who rewrote history.
So every xNAUT release now attests itself: the release digest is signed on the HSM at ship time, and the receipt is public. The second entry on xnaut.dev/attest is v1.17.0's own attestation, minted the day it shipped. Upgrade attestation is not a feature we describe. It is a receipt you can open.
Who actually needs this
Crypto foundations run large parts of their operations through LLMs now. Route it all through one gate and the signed chain shows exactly what left the house and what never did. When someone asks whether treasury data went to a model provider, you do not argue. You show the receipt.
Accountants and auditors are in the same position from the other side: everyone is using the models already, and the question nobody can answer is what exactly was sent. With an attested chain, compliance stops being a process you promise and becomes a property anyone can verify.
How it ships
In xNAUT v1.17.0 it is a plugin in the library: Securosys Attestation, a dependency-free MCP server that talks straight to the TSB REST API. Configure a TSB endpoint plus an API key or JWT, and the same plugin works against a CloudHSM partition, the free 90-day sandbox, or an on-prem Primus. Receipts append to a local attestations.jsonl. In NautGate it is the sb-attest extension, which signs the privacy chain head server-side so a receipt can never be minted for a head that was not in the table.
Enterprises bring their own partition: your key, your receipts, your hardware if you want it on-prem. We verified the whole path against a real partition before shipping, and the receipt on our launch card is that verification. Scan it.