Compared with your own logs
A signafAIde record is signed by two parties and fixed in time by public services, so an auditor does not have to take your word for it. This page sets it beside what teams already have or could build, and says what each does well.
Write-once storage and a SIEM are worth having. They answer a different question: they keep what you gave them, and they cannot show what you left out or when you wrote it.
Compared with a log you write yourself #
A log you control proves nothing to a third party, because you could have edited it.
| Your own log | A signafAIde record | |
|---|---|---|
| Signed by | nobody | the agent's key and the service's key |
| Edited later | leaves no trace | breaks the signatures and the chain |
| A record removed | leaves no trace | leaves a visible gap in the chain |
| Earliest time | what the clock said | after a public randomness round |
| Latest time | what the clock said | fixed by a public timestamp |
| Checked by | the people who wrote it | anyone, with the open verifier |
Why not WORM storage and our SIEM? #
Write-once storage, such as S3 Object Lock, does one thing well: once written, an object cannot be changed or deleted before its retention date, even by an administrator. A SIEM is good at collecting events and alerting on them. Both are worth having.
Neither proves anything to a third party. The bucket and the SIEM are yours, so an auditor has to take your word for what went in: a record you never wrote, or wrote late with an earlier date, or left out, looks the same as a complete log. signafAIde adds three things a store you control cannot: an independent co-signature on each record, public time bounds (not before a public randomness round, not after a public timestamp), and a completeness check on each agent's chain against the newest head the service signed. You can keep writing to your WORM store and SIEM as well; the records verify the same.
Why not an immutable database? #
An immutable database, such as immudb, keeps every row in a tamper-evident structure and can prove that a row has not changed since it was written. It runs inside your own network and it is a good store.
It has one party. The database, its keys and its checker are run by the company whose agents are being audited, so the proof says "this store was not altered", not "this is everything the agent did, written when it says". Whoever runs it can rebuild it from the start, unless someone outside holds its state. signafAIde keeps that outside state for you: each record carries a second signature from a party that is not you, and each agent's newest record is signed by that party, so a record left out or a history rebuilt shows.
Why not a public transparency log? #
A transparency log, such as Sigstore Rekor, is an append-only public log: an entry proves that something existed by the time it was logged, and nobody can quietly remove it. It is free and well run. signafAIde uses the same idea for its own public timestamps.
It was built for software releases, not for an agent's actions. On its own it gives a latest time and nothing else: no signature per agent, no link from one record to the next, no check that records are missing, no earliest time, and entries on a public log can be read by anyone. You would write the rest yourself, which is the next section.
Why not build the chain ourselves? #
You can, and the free version of that already exists: the signafAIde SDK. With no account and no API key it signs each record with the agent's key, links it to the one before, keeps it in .signafaide/ on your machine and verifies it offline. Nothing is sent. It is Apache-2.0, in Python and TypeScript, with a public specification, test vectors and three verifiers that must agree. Start with it for free, inside your own systems, and turn the service on when someone outside your company has to rely on the record.
A chain you keep yourself, anchored once a day, is still a log you control:
| Your own chain with a daily anchor | A signafAIde record | |
|---|---|---|
| Who signs | you | the agent's key and an independent service key |
| Rewritten before the next anchor | leaves no trace | breaks the second signature |
| Records left out | cannot be shown | checked against the newest record the service signed |
| Earliest time | none | after a public randomness round |
| Latest time | up to a day later | about an hour later |
| The checker | written by the party being audited | three independent open verifiers |
The service adds the parts a single party cannot give itself: the second signature, the two public time bounds and the completeness check. The records you wrote locally stay valid when you turn it on.
If nothing may leave your network #
By default only a hash of each record leaves your systems, with its tool name, agent name and time; inputs and outputs stay with you. Where even that is not allowed, Enterprise customers run the witness on their own infrastructure, on premises or in their own cloud account, with their own service key (self-host the witness). The SDKs, the verifiers and the auditor exports work the same.
The second signature only means something when the witness is run by someone other than the agents' owner, so have a separate team or an independent operator run it. Enterprise also covers single sign-on, your own encryption keys and audit packs mapped to the EU AI Act, ISO/IEC 42001 and SOC 2: see pricing.
Next: what this gives an auditor. Auditors and compliance