inferXby CyberSecAI Request a licence
Threat model · Verified against the code

Why the record cannot be rewritten.

The question every reviewer asks first is not "what does the record say" but "who could have changed it". This page answers that in plain English. Four layers, each independent of the others, and then the honest list of what they do not cover. The line for a customer: the agent cannot rewrite, the operator cannot rewrite, and if anyone somehow did, the other side's verifier would show exactly where.

Four layers

Each layer assumes the one before it has failed.

Defence in depth is only worth the name if a single failure cannot defeat the whole. Here the agent, the database, the storage and the mathematics each refuse independently. Compromise one and the next still holds. Compromise all four and the change is still visible to anyone holding the public key.

01

The agent never holds the pen

The agent does not write evidence. It calls the gateway, and the gateway writes the record from its own process, with the signing key held behind a separate trust boundary: a key that never leaves that process, a KMS or HSM in production, or a single sealing authority the gateway forwards to. The agent holds no credential to the ledger, so there is no write path for a prompt injection or a hijacked model to use. For gated actions the approval record exists before the action is released. This is the "AI write blocker" principle, and it is how the code is built.

02

The database refuses changes, even from the owner

In the in-database enforcement stack the evidence table carries a trigger that fires before any DELETE, UPDATE or TRUNCATE and raises an exception: the evidence table is append-only, refused for all agents. A connection with a database credential can insert. It cannot alter or remove. Honest limit: a database superuser could drop the trigger. That is why the next two layers exist and why the first layer keeps agents away from database administration altogether.

03

The store is write-once

In production the evidence service writes to object storage with Object Lock in Compliance mode. Until the retention period expires nothing can be overwritten or deleted by anyone, including the root account of the cloud tenancy. The ledger code refuses any modify or erase call against a write-once store and says so in the error. Where law requires erasure, it is done by destroying the record's key, never by rewriting the record, and the erasure is itself recorded.

04

Any change is detectable anyway

Every record carries the hash of the record before it and an ES256 signature, with a post-quantum ML-DSA-65 signature alongside where the ledger has it enabled. Batches are Merkle-anchored and the root is timestamped by an RFC 3161 time-stamping authority. Change one byte and three things happen at once: the chain breaks at that record, the signature fails, and the external timestamp proves the original existed before the change. inferX and the standalone verifier both point at the exact record. This is what the live demonstration shows: tamper, rogue device, replay and suppression each turn red at the record where they happened.

What it does not cover

Three limits, stated plainly.

A threat model that claims to cover everything is not a threat model. These are the residual risks, what the design does about each, and what remains your responsibility.

Capture can be withheld

  • The risk. An attacker who controls the gateway host before capture can choose not to record an action at all.
  • What the design does. Sequence numbers, the hash chain and the external anchor make the gap visible: a missing record shows as a declared gap against an independent clock, not as silence.
  • What it does not do. It does not make the gap impossible. Visible, not impossible, is the honest claim.

Development stores are advisory

  • The risk. The local file store used for development and demonstrations is mutable, and the code labels it as such.
  • What the design does. A local store with write-once semantics enforced in-process is available for demonstrating the guard. It is still not tamper-proof against someone with the machine.
  • What it does not do. Production means Object Lock in Compliance mode. A deployment on a mutable store does not carry these guarantees.

Key custody

  • The risk. If a signing key leaks, forged records are possible from that moment forward.
  • What the design does. Forgeries cannot be backdated, because the RFC 3161 timestamp on each anchored batch fixes what existed before the leak. Key identifiers on every record make the affected window precise.
  • What it does not do. It cannot stop a holder of the live key from signing new records. HSM custody with rotation closes most of this, and is the production configuration.
Verification, not trust. Every claim on this page is checked against the code and against the live demonstration before it is written here. Where a protection is configurable, the page says which configuration carries the guarantee. Where a protection has a limit, the limit is stated. Immutability, encryption and custody on the main page describes the same controls from the evidence-handling side.