correlation_id
Your workflow run
Spans the whole workflow, possibly several agents.
Every decision leaves a record.
Not a log written afterwards on a best-effort basis. The record commits in the same transaction as the decision, before the answer is returned - which is what makes it worth quoting in an incident review.
decisionapproval_required
agenttreasury-agent
tool_namepayments.create_transfer
policy_versionv12
risk_score87 / 35 threshold
correlation_idwf-3081
writtenbefore the response returned
An unrecorded allow is not an allow.
Every accepted evaluation commits its runtime event, its approval if the call was held, and its audit entry in one transaction, before the decision is returned to the caller. That ordering is the whole guarantee.
A decision Anubis could not record is not returned as an allow. Persistence failure surfaces as 503 runtime_persistence_unavailable, which is a refusal. There is no window in which an agent was permitted to act and no trace of it exists.
Control-plane mutations follow the same rule. A policy edit, a lifecycle transition or a credential operation whose audit entry cannot be written is rolled back - an action that was not recorded did not happen.
The runtime event itself is immutable. An approval resolution is written beside it, never over it, enforced by database guards rather than application convention: the record that policy did hold the action survives whatever a reviewer later decides.
What a decision carries.
| Runtime event | The tool call that was evaluated, the decision, the risk score, the reason, the policy provenance, and the correlation and session context. |
|---|---|
| Approval | Only when the decision was approval_required. |
| Audit entry | The governance record of the same event. |
| Your tool's arguments | input is handed to the decision engine and discarded. Only a non-reversible fingerprint of its shape reaches the row, so the audit trail does not become a second copy of the data your agents touch. |
|---|---|
| Your credential | Never logged, stored or returned after issue. Evidence rows carry a key prefix, never the secret. |
| The outcome of your execution | Anubis records the decision it made, not whether you ran the tool or what happened when you did. Record that on your side against event_id. |
Ids : safe to log, safe to quote
event_idThe runtime evidence row this call produced.
evidence_idServer-assigned evidence identifier.
request_idServer-assigned request identifier.
approval_idThe approval, when the decision held the call.
policy_id + policy_versionWhich policy content decided. Log both.
idempotent_replayTrue when a retry was absorbed rather than re-evaluated - nothing was written a second time.
Evidence is a control-plane read.
Evidence retrieval is a control-plane operation behind a signed-in session. A runtime credential cannot read evidence - not its own, not anyone's. There is no agent-facing evidence route, and therefore no SDK method for one.
Both routes are organization-scoped from the verified session. An agent_id filter can narrow the result but never widen it, and a malformed, unknown or foreign event id returns the same 404 - so the response never reveals that an event exists in another organization.
| Runtime | Recent runtime decisions for your organization, with agent, decision, risk and policy. |
|---|---|
| Approvals | Everything held by approval_required, for a security lead to resolve. |
| Audit log | Registration, scoring, lifecycle transitions, policy edits, credential issue and revoke, approvals, containment. |
| Agent detail | The same, narrowed to one agent. |
Context : what makes evidence answerable
session_id
One agent invocation
Groups the tool calls of a single agent execution inside that run.
context.user
Who the work is for
The end user or ticket requester. Recorded, not authenticated.
None of them changes a decision. Together they are what lets an operator pull every decision in one workflow run, in order, with the reason and the policy version attached to each - which is the difference between an audit log and a pile of rows.
What the audit trail does not claim.
The audit trail is not hash-chained. There is no tamper-evident chain today. Immutability is enforced by database guards, which is a different and weaker claim.
There is no SIEM export. Evidence is read through the control plane, not streamed to your log platform.
It is not a record of what your tool did. Anubis records its own decision. Whether the tool then succeeded is yours to log.
It is not a copy of your data. Tool arguments are evaluated and discarded, deliberately.
anubis doctor deliberately does not evaluate anything, for the same reason you should not poll: a diagnostic must not manufacture audit records.
Private access
Ask the hard audit questions.
Bring the question your auditor asks that nobody can currently answer. We will show you what the record holds.