Every action recorded.
Never erased.
Every agent action lands in a tamper-proof log. Provider key events ride a hash chain anchored every hundred entries. One API call confirms the chain never changed.
One chain. No edits.
Every key event is hashed and linked to the one before it. The chain only grows forward. Any tamper attempt breaks the math at the next check.
A signed chain means an operator cannot quietly edit a record after the fact. If the body of an old entry changes, the hash chain after that point breaks. The verification API surfaces the break and identifies the exact entry where the chain diverged.
General activity events use TimescaleDB hypertables with seven-day compression so query latency stays low on multi-month windows. Provider-key events are mirrored into the SHA-256 chain so an auditor can prove that a key rotation, an envelope re-wrap, or a signature delegation was not retroactively rewritten.
Four event types. Full coverage.
Four event classes cover everything an auditor or fleet operator needs. Together they describe every state change in the system.
Transactions
Every payment authorized, settled, or blocked is recorded with the agent identifier, counterparty, amount, chain, and the policy version that ruled on it. Regulators see the full payment ledger without separate reconciliation.
Policy evaluations
Each policy evaluation writes a row capturing inputs, evaluated rules, latency, and verdict. Evaluations are stored on a TimescaleDB hypertable so a year-long query on a single agent still returns within seconds.
Key mutations
Every provider-key event (creation, rotation, envelope re-wrap, signing delegation) lands in the SHA-256 chain. These are the events an auditor will challenge first, so they live in the chained store rather than the regular log.
Agent state changes
KYA upgrades, suspensions, reactivations, and policy reassignments are recorded with the operator identity that authorized the change. Investigators can reconstruct the full operational history of an agent over its lifetime.
Anchored every 100 entries.
The chain head writes to a versioned Vault path every hundred entries. Even an admin cannot silently rewrite an anchor without leaving a second trail.
The anchoring rule is simple. Every hundredth chain entry writes its hash to a versioned Vault KV path. Vault retains every prior version of that path, so the anchor history itself becomes tamper-evident.
During verification, the chain replays from genesis. The hash at each anchor point is compared against the corresponding Vault KV version. A mismatch signals tampering, identifies the affected segment, and surfaces the divergence in the verification response.
Verify in two calls.
The SDK exposes verify and query directly. Drop them into audit scripts, regulator portals, or operator dashboards. No custom plumbing.
The verify call replays the entire chain server-side and confirms each anchor against Vault KV. The list call returns filtered activity rows from the TimescaleDB hypertable. Both calls inherit your developer scope and respect tenant isolation.
oris.audit.verify(developer_id="dev-acme") # { # "valid": true, # "chain_length": 4821, # "anchor_matches": true, # } oris.audit.list( agent_id="agent-procurement-bot", action="payment.settled", start_date="2026-05-01", )
Ship with a trail
you can prove.
Every agent action recorded and chained. Hand the regulator one verify call. Sleep through the audit.