Every Blackbox entry is hash-chained to the one before it, so an edited or deleted row breaks the chain. That proves the record was not changed, unless someone with superuser access rewrites the rows and recomputes every hash after them.
Anchors close that gap. Every few minutes, or every 500 new entries, FoxByte writes a checkpoint of the chain, a Merkle root over a range of rows, to a file outside the database, signed with a key the database cannot read. Rewriting anchored rows makes them stop matching the anchor, however carefully the chain was rebuilt.
Where the line goes
When FoxByte became two editions, writing anchors on a schedule moved to Enterprise. Checking them did not. fox blackbox integrity, the public key, and the standalone verifier fox-verify are free in every edition, and so are the security log’s own anchors.
An independent verifier you have to buy is not much of an independent verifier. And anyone who anchored before upgrading, or who lets a licence lapse, must still be able to prove what they hold.
Keep them somewhere the admin cannot reach
Anchors are only as safe as where they live. By default they are written read-only beside the install, which proves nothing against the person who runs that machine. Point them at a bucket with Object Lock in compliance mode, ideally in an account the database administrators do not control, and nobody can delete or overwrite them before the retention ends, the bucket’s owner included.
$ fox blackbox anchor-target set s3://audit-anchors … # next release $ fox blackbox anchor-key $ fox blackbox integrity
The format is public
The anchor file format, ledger-anchor/1, is specified in the repository, so a security team that does not trust FoxByte can write its own verifier from the document alone.