Governance · incident reconstruction
When an agent action is questioned, join it back into one signed thread: who was authorised, what context was retrieved, what memory changed, what action ran, what resulted, and what it cost. The reconstruction is a verifiable record you, your customer, and an auditor can each inspect offline. Governance here is the same machinery memory and retrieval already run on, not paperwork about it, diagrams first, depth as you scroll.
At a glance
Each subsystem answers one question an operator will eventually be asked under oath, and each writes its answer onto the same hash-linked chain. Click through to the mechanism.
every answer is itself a receipt, so the loop audits the loop
crown · ed25519 · blake3
Every state mutation is signed into a CROWN receipt. The signature binds to both the receipt id and the payload hash, so a receipt cannot be edited in place or transplanted into another trail; receipts are then sealed into segments whose seals commit to the seal before them. Flip the byte yourself.
corecruxctl verify-store --mode full --strict ok: true · 4 receipts · chain intact
Signatures bind to both the receipt id and the payload hash, so a receipt cannot be edited in place or transplanted elsewhere; ordering is carried by chained segment seals on the spine. You can run this exact experiment on your own machine: scripts/demo-receipt-tamper.sh in the Crux repo.
Verification is local and offline. The verifier rejects malleable signatures and small-order keys, and the whole export, verify, tamper-reject cycle is a release-blocking CI gate: every published build has passed its own exit test.
Within a segment, every record is covered by a sealed hash and ordered by a monotonic sequence; each segment seal then commits to the hash and sequence of the seal before it. That is the claim we make, no rounder: tamper anywhere and verification fails there, but it is the seals that chain, not receipt-to-receipt.
The daemon can submit seal-chain heads to the Sigstore Rekor transparency log and store the inclusion proof alongside your data. Anchored, even we could not quietly rewrite your history, because a third-party log has the head. Off by default; one flag turns it on.
Verifying keys are kept in a keyring indexed by key id, so receipts stay verifiable against retired keys after a rotation. Most systems discover this problem when their first rotation invalidates every historical signature; here it is handled by design.
A self-signed CROWN receipt is a verifiable record of what the daemon did: identity and constraint, not a claim about a model you do not control. For cloud model traffic the witness path goes further. crux-llm-shim captures each Anthropic /v1/messages or OpenAI call and signs a digest with an Ed25519 key the agent never holds, so that evidence is forgery-resistant. The honesty boundary is explicit: bypassing the witness is a detectable absence, not a forgeable presence. Which event classes are covered, and at what assurance level, is enumerated in the assurance & coverage matrix.
attribution
An API key says "something with this string called us". A passport says "this agent, at this trust tier, with these grants", which is identity and constraint, and every action it takes is bound into the verifiable record. Four verbs cover the lifecycle:
bind
The session handshake binds every connection to a passport. No anonymous writes.
carry
Every tool call rides the passport. RCX mints short-lived capability tokens against it.
earn
Verified receipts accrue as reputation. Five tiers climb the capability ladder.
answer
Any receipt, any time later, resolves back to who acted, at what tier, under which grants.
trust is a ledger, not a checkbox: what a passport earns in step 3 changes what step 2 allows
Verified receipts accrue to the passport as reputation, and reputation climbs a five-tier capability ladder, a policy the operator sets and not a claim about conduct. A new agent starts observed; a passport with a long unbroken receipt history can be granted more autonomy. What the receipts establish is the record (which operations ran, under which passport), not a verdict that the agent behaved well.
The ladder cuts both ways: any receipt, any time later, resolves back to the passport that produced it, at the tier it held that day, under the grants it had. Attribution does not fade as the fleet churns.
rcx
RCX turns the passport into per-request permission: short-lived capability tokens scoped to tools, tenant and tier, minted against policy on every call. Enforcement is a property of the wire, not a crippled binary: the same daemon runs on every tier, and what changes is the signed token. Refusals fail closed with a signed RefusalReceipt and a reason code.
request
agent/claude-fleet-02
passport tier 3
wants fs.write:/prod
RCX policy check
scope: tools · tenant · tier
per request, not per session
allow · capability token
short-lived, signed, scoped
verifiable offline; expires instead of leaking
deny · RefusalReceipt
signed, with a reason code
fail closed; never a bare 403
Both outcomes mint a receipt, so "who could touch what, when" is a query, not a reconstruction. Enforcement is a property of the wire, not a crippled binary.
The rollout story (off, observe, enforce, with a playable demo) lives on the RCX page.
human oversight
Autonomy is not all-or-nothing. Work carries a declared risk class, and high-risk transitions stop at a human gate that is passport-attributed like everything else. Two properties make the gate meaningful rather than ceremonial: it cannot auto-approve on a timeout, and its verdict becomes a signed fact.
agent proposes an action
deploy · delete · write · spend
risk class
declared on the plan or work item
low · proceeds
action runs
signed CROWN receipt minted
high · stops
human gate
passport-attributed approval · timeout cannot auto-approve · refusal fails closed
the gate becomes a signed fact
who approved, when, at which tier
Both branches end on the same hash-linked chain. An auditor cannot tell a quiet day from a deleted one: gaps are detectable, not deniable.
gate.revoked
Governance that cannot unwind access is advice. Here a revocation is an event that propagates: the pull is signed, every agent acknowledges with a receipt as the change lands, and an attestation records the moment zero holders remained.
The same mechanism covers credentials, capabilities and whole agents, so "we pulled that key" and "that agent is out of production" are claims with timestamps, not hopes with dashboards.
Fleet-wide revocation with proof is part of the Governance tier; pricing here.
vendor-api-key-3 held by claude-fleet-02, claude-fleet-07, gpt-ops
Somewhere in most fleets there is a key nobody can confidently say is dead. Here, pulling it is an event with a paper trail. Try it.
Under load, under failure
Governance claims are cheap in the happy path. What a cold external audit of the source found is that the security-critical paths keep their promises when things go wrong, which is the only time it matters.
A runtime middleware refuses unclassified routes with a 403 before any handler runs: forget to classify an endpoint and it is closed, not open. Ships observing in shadow mode; production should set CORECRUXD_ROUTE_AUTH=enforce.
Passports, sessions and ops state are forced private at the store level, seeded unconditionally at daemon boot. An operator who configures nothing still gets tenant isolation, because every current and future write path inherits it.
An over-capacity write returns a typed error your caller sees as a 429. For an append-only audit store, silently dropping records would be lying about history; rejecting loudly is the only correct behaviour, and it is the tested one.
Governance sub-track · EU AI Act, from 2027
This is a sub-track inside Governance, not the pitch: incident reconstruction earns its keep long before any regulator asks. When the deadlines land in 2027, the same machinery answers. The EU AI Act asks operators of consequential AI systems for risk management, logging, transparency and human oversight. Most stacks will answer with documents written after the fact. A receipted system answers with evidence generated during the fact: the compliance machinery is the same machinery everything else runs on, which means the evidence exists whether or not anyone remembered compliance that sprint.
Article by article, this is the mapping. Read the right-hand column as "what you can hand the auditor", because each row ends in something signed.
Art. 9
Risk management: documented processes for identifying and handling risk.
Risk classes are declared on plans and work items, not in a PDF. A high-risk transition demands a passport-attributed human gate, and the gate itself becomes a signed fact you can produce later.
Art. 10
Data governance: discipline over what personal data enters the system.
Private facts never leave the machine. Reserved prefixes are private at ingest, observation capture redacts, and reasoning is stored as references, never raw chain-of-thought.
Art. 12
Record-keeping: automatic logging of the system's operation.
Every state mutation emits a signed CROWN receipt and a timeline row. The chain is hashed, so a gap is detectable rather than deniable. Logging is not a feature that can be left off; it is how the store works.
Art. 13
Transparency: users can tell what the system did and why.
Agent passports attribute every mutation. AI-authored commits and pull requests carry agent attribution, so "which of these changes did a model make?" has an answer.
Art. 14
Human oversight: meaningful human control over high-risk operation.
Destructive actions need explicit, current consent. Gated transitions cannot auto-approve past a timeout: silence means no, and the refusal is signed too.
Art. 15
Accuracy and robustness: the system behaves as claimed, and you can show it.
Consequence enrichment runs before high-risk operations. Published benchmark packs carry corpus and commit SHA, and the store is tamper-evident end to end.
Art. 50
Output transparency: AI-made content is identifiable as such.
C2PA Content Credentials via output_attest: a verifiable cryptographic claim on the artefact itself, not a footer that disappears in a copy-paste. Receipts can be signed with a full x509 certificate chain, so the standard Content Authenticity toolchain verifies them. Ships behind a default-off flag.
GDPR Art. 17
Erasure: the right to be forgotten, demonstrably honoured.
memory_forget with dry-run: see exactly what would be deleted, then delete it auditably. The deletion leaves a receipt; the content does not.
These are engineering controls aligned with the Act, not a legal opinion, and conformity assessment for your deployment remains your responsibility. What the system gives you is the evidence layer: when the auditor asks, you answer with receipts, not screenshots.
Don't believe this page
A governance system you have to trust is a contradiction. Everything above is checkable on your own machine, offline, in about a minute: export the store, verify the bundle with no network, flip one byte, and watch the verifier refuse it.
The verifier is ~1,250 lines of auditable Rust; the tamper script is ~150 lines of bash using only documented subcommands. Read both first, then run them.
The claims police themselves, too. CI fails the build if the README's stated coverage drifts more than two points from the measured artefact, or if the claimed test count exceeds the measured one. And committed conformance vectors (expected digests for store and replay) are what keep the Python and TypeScript SDKs verifiable against the Rust core, rather than merely compatible with it.
Releases are signed and attested end to end: cosign keyless signatures, CycloneDX SBOMs, SLSA3 provenance. That is the checklist a third-party-risk review asks for, answered before it is asked.
corecruxctl context export --data-dir <dir> --out ./bundle
corecruxctl context verify ./bundle --json # ok=true, offlinegit clone https://github.com/CueCrux/Crux.git && cd Crux
cargo build --release --bin corecruxctl
bash scripts/demo-receipt-tamper.shThe free daemon ships the whole evidence layer: receipts, passports, gates and the verifier. The Governance tier adds the fleet-wide controls on top.