Skip to content
AEGIS

Self-review · the audit surface

Don't trust the agent. Verify it.

Every intent, decision, consent, diff, command and network call AEGIS makes is appended to a ledger that is append-only, hash-chained and Ed25519-signed. The agent can't edit it — it can't even read it. Four commands turn that record into answers.

Free to share — plain markdown, no tracking, no sign-up.

ciarustcode usage output: hash chain verified, ledger entries, sessions, steps, model calls, prompt tokens, estimated cost $0, and a histogram of every network host contacted.
The whole session in one report — cost, egress and integrity. Real output, not a mock-up.

Integrity

$ ciarustcode verify

Re-computes the ledger's hash chain from entry #0 and checks every Ed25519 signature. If anyone — including the agent, including you — edited, deleted or reordered a single entry, the chain breaks and verify exits non-zero. Pin your device key with --device <hex> to also authenticate who wrote it.

When to reach for it: Run it after any session you care about, in CI after agent jobs, or before trusting a ledger someone hands you.

ciarustcode verify output: ledger intact, 435 entries, hash chain verified; signatures valid 435/435; device identity key shown.
Hash chain verified · 435/435 signatures valid — real output, not a mock-up.

The transcript

$ ciarustcode replay

Prints the full session transcript from the ledger — one timestamped line per event: session start, every model egress with byte counts, every intent proposed with the policy rule that classified it, every execution, every consent decision, every checkpoint. It's the agent's black-box flight recorder, in plain JSON.

When to reach for it: Use it for post-incident review, code review of the agent's process, or just to see why the policy engine denied something.

ciarustcode replay output: numbered timestamped JSON events — session_start, model_egress, intent_proposed with policy tier, intent_executed, signed_checkpoint.
One timestamped JSON line per event — session start, egress, intents, checkpoints.

Cost & egress

$ ciarustcode usage

Aggregates the ledger into a usage report: sessions, steps, model calls, prompt egress in bytes and tokens, estimated cost (local models are $0), how many intents were refused or denied, a histogram of every network host contacted, and intents by verb. If a host you don't recognise appears in that list, you'll see it here first.

When to reach for it: Weekly cost/egress reviews, or as the honest answer to 'what has this agent been doing on this repo?'

ciarustcode usage output: hash chain verified, 435 ledger entries, 7 sessions, 74 steps, 82 model calls, ~1 million prompt tokens, est. cost $0.0000, egress hosts: 82 localhost:11434.
Sessions, tokens and every egress host, aggregated from the ledger. Local models: $0.

Portable proof

$ ciarustcode attest --out proof.json

Exports a portable, signed proof bundle: file hashes of what changed plus the complete egress manifest, signed with the device key. Anyone can check it later — offline — with ciarustcode attest --verify proof.json. Pass --device <hex> to pin the expected signer so a forged-identity bundle is rejected outright.

When to reach for it: Hand it to a client, an auditor or a regulator as evidence of exactly what an agent engagement did — and didn't do.

ciarustcode attest output: wrote signed proof bundle, then attest --verify shows session id, files changed, egress entries, signature VALID, chain VERIFIED.
A signed proof bundle — verified offline, no access to the original machine needed.

How the ledger resists tampering

Three locks on one file.

01

Every entry links to the one before it

Each entry carries a fingerprint — a cryptographic hash — of the entry before it, so the whole log links together like a chain. Change a single byte anywhere and every later link stops matching, and verify points to exactly where it broke.

02

Every entry is signed, and a fake can't be forged

Each entry carries an unforgeable digital signature (using Ed25519, a standard signing algorithm). The signing key is unique to the session and vouched for by a key tied to your machine — so a signature proves which device and session wrote it. A log that's been altered or rebuilt from scratch has no valid keys, so verify rejects it.

03

The agent can't write to the log

The log lives in a folder (.aegis/) that the agent's write permissions structurally exclude. The one process with a motive to lie about the record is never handed a pen.

# In CI: run a task headless, then gate the pipeline on ledger integrity
$ ciarustcode run --headless --approve apply_diff,run_command "fix the failing test"
$ ciarustcode verify # exits non-zero if the chain is broken
✓ ledger intact: hash chain verified · ✓ signatures valid

Take the commands with you.

One markdown file: all four commands, real output shapes, the CI recipe and the threat model they defend against. Share it with your team — that's what it's for.