Activity and audit

Two records that people conflate, and should not.

Activity is what happened across your team's systems: messages, pull requests, issues, meetings. Evidence.

Audit is what the runtime decided: every action, its verdict, and why. Proof.

The timeline merges them, which is usually what you actually want, the decision, and the conversation that preceded it, in one column.

Two copies, one authoritative

The runtime writes its own hash-chained log on your machines. The console shows a mirror of it, scored for risk and merged with your source events.

The local log stays authoritative. That matters in one situation and it is worth knowing in advance: if the two ever disagree, the machine's copy is the one to trust, and the console tells you when its copy has fallen behind rather than showing you a gap as though it were quiet.

The chain

The ledger is append only, enforced by the database itself: an attempt to update a row is rejected by a trigger rather than by a convention somebody can forget.

An export of a period is signed, and states the range it covers and what was excluded from it. An export that quietly omitted a day would be worse than no export, because somebody would rely on it.

bash

memnox timeline --export bundle --out audit.json

1284 event(s) from 2026-08-01 to 2026-08-31, signed

The file is a JSON header, a blank line, then the events. The header states the range it covers, what was excluded from it, the digest of the body and the signature over that digest.

The signing key is Ed25519, generated locally and never sent. The public half travels with the bundle, so whoever checks it needs nothing from us and no command from us either: the header names the key, the body is the signed bytes, and any Ed25519 tool will do.

The audit report

The report is a file for an auditor: every event between two dates, as CSV or JSON lines. The console has no screen for it; a script downloads it from GET :ws/audit/report?from=&to=&format=csv (or format=jsonl) with an admin's session or key. The last line or row of the file is the verdict on the hash chain under those events, so a copy passed along carries the answer with it.

The verification says

chain

intact when every row hashes to itself and links to the one before, or broken with where it broke.

anchoredOn

Where the check starts. When retention has already removed earlier rows, it starts at the first row still kept, which is the honest limit of what the file can vouch for.

complete

False when a size bound stopped the read, with a cursor to continue it.

A message a connector delivered is listed with its hash and without its content, so the chain still reads and somebody's words stay in the ledger rather than in a file that travels. The report needs an admin and is part of the Team plan.

Sinks, shipping decisions out

Register a destination through the API, and every decision is delivered to it as it happens. Once one exists, Settings, under General, lists it.

Type

splunk

Splunk HTTP Event Collector

datadog

Datadog logs intake

ndjson

Newline-delimited JSON to any endpoint. Elastic, Sumo, your own collector

s3

One NDJSON object per batch, partitioned by workspace and day

kafka

One record per decision onto a topic, keyed by workspace

An S3 bucket with object lock, or a Kafka topic your security team owns, gives you the property the chain alone cannot: a copy nobody administering Memnox can rewrite.

CSV suits the auditor who wants a spreadsheet, and the signed bundle suits the one who wants a period and its proof at once.

Retention

Audit retention is set per deployment and pruned on an hourly sweep. The JSONL log rewrites into a sibling file and renames, so a reader never sees a partial chain.

bash

memnox config set retentionDays 365   # then "memnox purge" drops the rest

Set it to what your policy actually requires. "Keep everything" is a defensible choice; "we never decided" is not.

Narrowing the timeline

In the console, What was caught ends with every action a machine reported, newest first, and narrows by agent, machine, session, resource, surface, effect, and a from and to date. The resource is a prefix, so repo:acme/api answers every action on that repository and below it, and the effect matches either the verdict or what finally happened. Every filter is applied before the page is cut, so a short page is the end of what matched.

Replay and explain

bash

memnox timeline --session <id>   # every decision in one agent session, in order
memnox replay <session>          # the same session step by step, and what came before it failed
memnox why <id>                  # why that event got that verdict, in five lines

why reads the row back rather than evaluating it again against today's rules, so it says what was decided at the time. The local timeline also carries the config changes the daemon recorded, among the actions and in order; those stay on the machine. See Recover and decide ahead.

How a decision is made

The five stages every row in this ledger came from.

Security and privacy

What is kept, for how long, and how to erase a person from it.