01Critical
Repeated authentication failure
Failures grouped by source address rather than by account, so a few attempts spread across many accounts surfaces.
that shape is critical · flat volume against one account is a warning
01What an entry carries
Enough to answer a question months later.
Entries are written once and never updated — no edits, no soft deletes. Each names the actor by id; the name lives beside the trail, so the trail still reads after the account is removed, and the name can be erased on request without touching a single sealed record.
- atWhen the action was accepted or rejected, in UTC
- actorThe account, by id. Its name is kept beside the trail, so it can be erased without touching the record
- session · ip · agentWhere the action came from, trusted because the proxy chain is required to be configured
- channelThe console, or in Commercial an AI assistant through the MCP server, with the tool, the client and the token’s prefix
- privilegedWhether the actor held elevated rights at that moment
- environmentAnd the policy that environment carried at the time
- broker · clusterWhich platform and which connected cluster
- resourceTopic, stream, queue, exchange or address, and its classification
- action · changeWhat was attempted, and what it changed before and after. A credential is named, never shown; a message never enters
- reasonThe sentence the operator gave, where the operation requires one
- outcomeSuccess or failure, and for a refusal, the policy that refused it
One entry, as an operator reads it
at 2026-08-04 11:41:07 UTC
actor user 3f9c…0e21 (name shown from beside the trail)
session s-4f21… ip 10.42.6.18 agent broka-ui
privileged yes
env production policy: read-only
broker rabbitmq cluster: rmq-core-01
resource queue q.pay.us classification: confidential
action broker.queue.purge
outcome failure — blocked by environment policyAttribution across the boundary
A broker's own logs record the connection BROKA opened, not the person behind it — brokers have no field for one. So each connection is identified as itself on the wire, and the trail on BROKA's side is what turns that connection and moment into a named actor.
02Tamper-evident by construction
Why it is built this way
- —The chain lives beside the trail, not inside it, so linking never rewrites an entry.
- —Links are built by a sweep just after entries commit — writes are never serialised behind each other, and rolled-back operations leave no unverifiable gaps.
- —Each link seals the whole event in its RFC 8785 canonical form, so the bytes hashed are fixed by a standard rather than by a library setting.
- —Every record is an OpenAuditModel 1.0 event, one chain per installation, and an exported range passes the specification’s own verifier.
- —The specification’s check-profile reports three things BROKA states rather than meets: no multi-factor sign-in, a request refused before it ran that gave no reason, and a fact a failed operation names as one it cannot state.
Verification report
Verify any range and get a plain answer: entries checked, links verified, the first entry where the chain breaks if it does, and which ranges were pruned by retention rather than missing.
03Retention with brakes
Deleting history is itself an audited event.
Retention always runs and keeps at most six months — 180 days, which is also the default. The window can be shortened at runtime but never switched off, with a floor your deployment sets so it cannot be quietly lowered to nothing. Pruning is deliberately hard to get wrong.
- 01Zero and negative windows are rejected outright
- 02A sweep refuses to remove more than half the trail in one pass — a window a person shortened, with a reason, passes that check once
- 03Deletion happens in batches, each committing with its own record
- 04The floor is set by the deployment, not by whoever is logged in
- 05Pruning writes a chained destruction record naming the cutoff and the count
Older than six months
Only a forwarded copy still holds it. Forwarding to a file or an HTTP endpoint is set in the deployment environment and is in both editions. Forwarding to Kafka or RabbitMQ is Commercial: a registered connection, chosen in Settings › Security. A record that was never forwarded is still deleted at 180 days, and BROKA warns seven days before.
The destruction record
action audit.trail.prune
cutoff 2026-02-05T00:00:00Z
removed 182,417 records
window 180 days
outcome success — chain links marked prunedEach batch commits with its own record, so an interrupted sweep still leaves a witness. Surviving links are marked as pruned rather than broken, which keeps verification honest about the difference between deleted and altered.
04Evidence pack
One export, for the person who has to ask.
Pick a date range and get a single archive built from one consistent point-in-time read, so the files in it cannot disagree with each other. It is meant to be handed to an auditor as-is.
Stated plainly
The manifest carries a SHA-256 digest of every file, computed over the bytes actually written into the archive. Beyond those digests there is no cryptographic signing — a deliberate scope decision for a product that has to work air-gapped, and one we would rather state than blur.
evidence-pack.zip
- audit-trail.csvEvery entry in the range, in order
- authentication.csvSign-ins, failures and session activity
- privileged-actions.csvActions taken with elevated rights
- changes.csvWrite and administrative actions, with what each one set
- reads.csvMessage and resource inspection, recorded in Commercial — every read of masked contents shown unmasked among it
- events/The range’s sealed events, in files of at most 8 MiB, which the OpenAuditModel verifier checks as one chain
- checkpoint.jsonThe chain’s head at the end of the range, to keep outside the installation
- access-report.jsonWho held which role in which environment
- integrity.jsonChain verification result for the range
- retention.jsonWindows in force and pruning that happened
- manifest.jsonSHA-256 digest per file, plus plain-language warnings
05Signals worth waking up for
Four detectors, chosen for shape rather than volume.
The trail is swept every few minutes. Each detector is a plain rule an operator can reason about — no opaque scoring, and no claim to detect intent.
02Critical
Self-authorization change
An actor changing their own roles, team membership or environment rights.
legitimate sometimes · never uninteresting
03Warning
Unusual hour
Measured against a baseline learned per actor, not against fixed office hours.
a follow-the-sun team has no single working day
04Warning
Bulk consumption
Unusual volumes of message reads in a short window, judged by volume alone — in Commercial, where reads are recorded.
no data-sensitivity taxonomy is claimed or implied