signafAIde
Start free

How it works

Your agent signs each decision, the service co-signs it and gives it a public timestamp, and anyone can check the result with the open verifier. The content stays with you.

One record on a time line. The agent calls a tool. The record is signed by the agent and co-signed by the service, not before a public randomness round and not after the hourly public timestamp. Later an auditor checks it with the open verifier.

Your agent calls a tool

approve_payout(claim, amount)

The call is recorded before the tool runs. Only a salted hash of the content leaves your systems.

approve_payoutclaims-bot, record 42, 13 Nov 2026
Input
9f2c41ab…e07d
Output
41ab77c0…2b9e
Record before
c3d019fa…5a10

Salted hashes, not the content

Agent key
signafAIde

The record is signed twice and bounded in time

  • Signed by the agent12:58:36With its own key, which never leaves your machine.
  • Co-signed by signafAIde12:58:37So neither you nor the service can change it alone.

Not beforea public randomness round12:58:33

Not afterthe hourly public timestamp13:00:00 UTC

An auditor checks it

PASS: 12 of 12 checks passed

With the open verifier, signafaide verify, and the public services. Not the service's word.

An example record.

Your systems

Where your agent runs

  • The SDK wraps the tools that act
  • Each record is signed with the agent's own key
  • Records and content stay in .signafaide/

signafAIde

The service

  • Co-signs each batch and the agent's latest record
  • Adds a public randomness round: not before
  • Adds an hourly public timestamp: not after

Anyone

You, your auditor, a regulator

  • Gets one verification pack
  • Runs signafaide verify with the open verifier
  • Sees which checks passed and which could not run

The four steps

They run in the background. Nothing waits for the network unless you turn on strict mode.

  1. The agent signs

    Each call of a wrapped tool writes a decision record before the tool runs and an outcome after it. Both are signed with the agent's key and chained to the record before.

  2. Only hashes travel

    The service receives the envelope: the tool name, the time, the chain links and a salted hash of the content. Inputs and outputs, and the salt, stay with you unless you choose to store them, so the service cannot work out the content from the hash.

  3. The service co-signs and timestamps

    It signs each batch and the agent's latest record, notes a public randomness round, and adds the batch to the next hourly public timestamp.

  4. Anyone can check

    signafaide verify checks every signature, chain link, receipt and timestamp, and says how many of its 12 checks passed; a check still waiting (a public timestamp confirms within a few hours) is shown as pending, never as passed. Most run offline; the public timestamp check needs a network lookup or a saved block header. An auditor relies on the open verifier code and the public drand and timestamp services, not on your word or ours.

Records written offline

An agent that is offline, or that has not opted in yet, keeps signing and chaining records on its machine. They are sent when it can reach the service, with the time the agent wrote them. The service accepts records up to 7 days old, and never a record dated more than 5 minutes after it receives it.

Such a record has two times. The claimed time is the agent's own clock, signed into the record. The proven window starts at the randomness round of the batch it was sent in and ends at the public timestamp. For a record sent late the claimed time is earlier than the window, and the console, the auditor view and audit packs show both, with the note "written offline, sent later".

The 7 days are also a backdating window. Whoever holds an agent's key, and the operator of the witness, can make a record claim a time up to 7 days before the service first saw it. That is why the evidence is the proven window, not the claimed time: the record cannot have been written before its batch's randomness round or after its public timestamp, whatever it claims.

Compared with a log you write yourself

A log you control proves nothing to a third party, because you could have edited it.

PropertyYour own logA signafAIde record
Signed bynobodythe agent's key and the service's key
Edited laterleaves no tracebreaks the signatures and the chain
A record removedleaves no traceleaves a visible gap in the chain
Earliest timewhat the clock saidafter a public randomness round
Latest timewhat the clock saidfixed by a public timestamp
Checked bythe people who wrote itanyone, 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.