Tamper-evident action log

Every agent action is hashed with SHA-256 as it is written, sealed with a server-held key, and linked by hash to the action logged before it. Re-verify anytime: an action whose logged fields were changed fails its check.

THE PROBLEM

“The agent did it” is not an audit trail.

When an autonomous agent exports an invoice, changes a record, or emails a customer, someone will eventually ask: what exactly happened, and can you prove the log wasn't cleaned up afterwards? An ordinary application log can be edited by anyone with database access, so it proves nothing.

CanaryAudit hashes each action as it is written: the account, the agent, the action type, the trigger, the detail, the outcome and the time, plus the hash of the action logged before it. A server-held key seals that hash. Anyone with the record can recompute the hash: you, your customer, an auditor, opposing counsel. Change any of those fields afterwards and the record fails its check; take an action out of the middle of your trail and the export shows a break at the one after it. Metadata you attach is kept beside the hash, not inside it.

Send actions to the API

One call per action from your agent framework: actor, action, payload. One HTTPS call with your API key.

Records are hashed and linked

Each record's SHA-256 covers its logged fields and the hash of the record before it, and a server-held key seals it.

Re-verify on demand

One click, one API call or the public verifier recomputes a record's hash and checks its seal. The JSON export and the legal PDF also check that the record before each one is still there and still matches its hash, or was removed by your retention setting.

WHAT YOU GET

Everything reports into the same console.

curl -sS -X POST https://api.canaryvaults.com/canaryaudit/log \
  -H "X-API-Key: $CV_KEY" -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "user_id": "<your-user-uuid>",
  "agent_id": "billing-agent",
  "action_type": "invoice_export",
  "input_trigger": "cron:invoice-run",
  "action_detail": "Exported invoice batch 2026-08 to S3",
  "outcome": "success"
}
JSON
# → record id + content hash, returned for independent verification

The response carries the record id and a 64-character content hash. Hand over the content hash: the public verifier takes that and rejects a record id.

Is this court-admissible evidence?

It's tamper-evident, not automatically admissible: we prove a record hasn't changed since logging. Whether that satisfies a court is a legal question for your counsel; the PDF export gives them everything they need to make that argument.

Where is my data stored?

In your workspace. Verification only needs the hashes, so you can keep payloads in your own systems and send content hashes alone if your data can't leave.