Audit chain
Every administrative act hash-chained, and anchored with a signature your auditor can check alone.
The threat model has to include your own operator.
An audit log earns its place by answering who widened this policy, when, and whether anybody edited the record afterwards. So the threat model has to include the administrator who can relax a policy, run an agent against it, then delete the row that says so.
A bare chain is evidence only against an attacker who cannot recompute it, and a test in the repository asserts it: the forged chain passes on a default install and fails once a key is set. Everything above it moves the target rather than removing it.
How it works
- 01
Append, then seal
Both hash fields are excluded from the digest input, so a recomputation covers exactly what the original write covered. With an audit MAC key set, every boot also writes a checkpoint MAC over the head it reached. Entries written before the key cannot be re-MAC'd, so that checkpoint vouches for them. - 02
Verify
A walk checks every link, recomputes every content digest and finds sequence gaps, then reports where the chain broke and whether it was keyed. - 03
Anchor
With a signing key set, Token Observe signs a canonical statement of the head daily and on demand, and refuses to sign when the chain does not verify. - 04
Publish, then check
Each anchor goes to a file sink, an HTTP sink or both, from a cursor that advances only once that sink acknowledges it. An auditor verifies it with a public key that arrived out of band, using a script needing no install and no network.
The chain says where it broke.
A walk names which of three failures it found: a link mismatch, a content mismatch, or a sequence gap where a row was removed, missing prefix included. What it cannot see is truncation with nothing logged afterwards, so record the head and entry count outside the deployment and hand them back.
Set an audit MAC key and entry digests become HMAC-SHA256, so rewriting an entry needs the key as well as database access, but only if that key comes from a secret manager the database administrator cannot read. A missing key and an altered entry produce the same bytes and mean opposite things, so a failure with no key configured is reported as a suspected missing key, a diagnosis rather than proof.
unkeyed keyed
edit a row, do not re-hash detected detected
delete a row from the middle detected detected
delete the tail, keep logging sequence gap sequence gap
delete the tail, stop logging off-box head off-box head
rewrite and recompute every hash UNDETECTED detected
delete the checkpoints n/a boot refuses
read the key out of the host UNDETECTED UNDETECTEDAn anchor your auditor can check alone.
A MAC has a structural problem as evidence: the key that verifies the chain is the key that can forge it, so handing it to an auditor hands them the power to fabricate the record. Ed25519 splits those powers. Anchors are chained and numbered contiguously, so a deleted one is a visible break rather than a re-numberable hole.
Anchoring refuses to sign when the chain does not verify, and that refusal is the feature: signing over a forged head would launder the rewrite under a key the auditor was told to trust, while refusing leaves the previous anchor to contradict it.
- Key theft
- Whoever reads the private key out of the process or the KMS can sign any history they like.
- Pre-anchor history
- Anchor 1 attests the head as it stood when anchor 1 was made, and nothing beneath it.
- Sink collusion
- Suppression is detectable only if a copy sits somewhere the install cannot reach.
- Workspace configuration, registry, policies and decisions
- Billing evidence from the connections and imports you supply
- Supplied connection credentials, encrypted at rest
- Request metadata for traffic routed through the workspace
- Bounded, redacted prompt and reply text when capture is enabled
- Billing queries using the reporting permissions you supply
- Routed model payloads after the applicable policy checks
- Model-assisted search using a separately configured inference key
- Authorized evidence reads and CSV exports to your client
The cloud service processes and stores workspace evidence and supplied credentials. Supabase handles account authentication; Railway runs the cloud pilot. Cloud hosting does not keep all data inside your network.
Billing cannot recover historical conversations. Activity covers routed traffic or supported evidence supplied to the workspace. Text capture is off by default, and redaction is heuristic.
Customer hosting is an optional, separate deployment choice. Its infrastructure and data boundary differ from the cloud pilot.
Each line closes off an assumption a reader would otherwise carry into a proof of concept.
What this does not doWhat this leans on
Flight recorder
Every governed request in a timeline a compliance officer can read, and a search box that never writes SQL.
Human approvals
One human decision, bound to one exact payload, spendable once.
Policy engine
One deterministic verdict on every governed request: allow, block, redact, or park it for a human.
Where this comes up
Jobs that draw on it
Guides that lean on it
The term, defined
An audit chain is a record of administrative actions in which every entry carries a cryptographic digest computed over its own content and over the digest of the entry before it, so the entries form one linked sequence rather than a set of independent rows. Editing, reordering or removing an entry breaks that sequence at an identifiable point, which is what lets anyone recomputing the digests check the record’s integrity.
Is the audit log tamper-proof?
No, and Token Observe will not use the word. Unkeyed, which is the default, it is tamper-evident: any edit that does not also recompute every downstream hash breaks verification at a named sequence number. An operator with write access can recompute it, and the repository's own forgery test asserts the forged chain passes. Configure an audit MAC key and a rewrite needs the key too; keep an anchor off the box and any later rewrite is contradicted by it.
What does an auditor need in order to verify an anchor?
Two things, and the second must arrive out of band: the anchor export, and the current Ed25519 public key plus every retired one, from a key ceremony rather than from the anchor file. A pass says those keys signed every anchor, the anchors are contiguous, and attested heads only move forward. It cannot vouch for the history beneath the first anchor.
Prefer to ask a person? Write to James
Bring us the agent you are least comfortable with.
Create a cloud account and workspace. No card or server installation. Model calls and Google BigQuery scans can incur separate provider charges.