Bairav
Pillar — Prove

What the registry says should happen, and what actually did

The registry records what exists. Policy records what's allowed. Prove is the only one of the three that records what happened — every request, every query, every path data could take — in real time, not in hindsight.

TrafficData FlowAudit Ledger
Traffic

The individual request, not the rolled-up number

Two views, two different problems: model calls and data access. Aggregated metrics show the shape of activity; Traffic shows what happened in one specific request.

LLM calls

Requests
69
all time
Allowed
44
passed guardrails
Blocked
25
by guardrails / kill-switch
Avg latency
2,245 ms
per request
Tokens
634,754
630,728 in · 4,026 out
Traffic screen showing LLM call stats, a throughput chart of allowed versus blocked requests over the last 24 hours, and a per-agent breakdown of models and token use.
Prove — TrafficIllustrative data from a demo environment.Swipe the panel to read it.

Data access

Queries
543
last 24h
Writes
63
insert / update / delete
Tables
15
distinct touched
Avg time
3 ms
per query
Slowest
52 ms
single query
Data access screen showing query and write volume, distinct tables touched, average and slowest query time, and per-hour query volume.
Prove — Traffic (Data access)Illustrative data from a demo environment.Swipe the panel to read it.
Data Flow

What's reachable, not what's declared

An agent's registered capabilities say what it's allowed to touch. Data Flow shows what actually happened — every source pulled from, every tool called, everywhere the result could go.

Places data is stored
16
last 7 days
Paths to critical data
0
last 7 days
Unprotected paths
31
no rule can stop them
Ways data can leave
9
last 7 days
Issues found
0
last 7 days
Data Flow map showing places data is stored, unprotected paths, and per-agent source/tool/destination counts, ordered by what needs attention first.
Prove — Data FlowIllustrative data from a demo environment.Swipe the panel to read it.
Declared versus reachable

A capability the registry lists as read-only doesn't guarantee that data can't reach an uncontrolled destination three hops later. This page exists to catch that gap.

Agent Audit Ledger

Evidence, not just visibility

Actions recorded
69 of 69
matching current filters
Blocked
9
denied at guardrail
Awaiting review
16
pending / quarantined
Critical-risk actions
0
high-scrutiny events
Agent Audit Ledger with stat cards, filters, a chain-verified indicator, a CSV export control, and an event table listing timestamp, event ID, agent, owner, action, target system, risk, decision, approval and outcome.
Agent Audit LedgerIllustrative data from a demo environment.Swipe the panel to read it.
What gets recorded

Nine questions, answered for every single action

An audit record is only useful if it survives contact with someone who was not there. These are the fields the ledger writes for every governed agent action.

ColumnWhat it establishes
TimestampWhen the action occurred.
Event IDA unique ledger reference that can be cited outside the product.
AgentWhich agent performed the action.
OwnerThe accountable person on record — set as a required field at intake, not inferred later.
ActionWhat was attempted, in plain language rather than an opaque event code.
Target systemWhich system or database was touched.
RiskThe risk tier at the time of the action, not the tier the agent carries today.
DecisionAllow or deny.
ApprovalWhether human approval was required, and whether it was given.
OutcomeExecuted or blocked — what actually happened, as distinct from what was decided.
Why decision and outcome are kept separate

"Policy denied it" and "it didn't happen" are two different claims. An auditor is right to treat them differently — conflating them becomes a large problem under a follow-up question.

Nobody edits history, including us

Entries chain to each other rather than sitting as editable table rows — verification reports how many were checked and confirmed intact: 69 of 69, last run. That's load-bearing, not a nice-to-have.

Evidence that leaves the product

Filtered results export to CSV, so the record can go to an auditor, a regulator, or an internal investigation without a single screenshot in the chain of custody.

Filterable by the questions people ask

Search by agent, owner, action or event ID, with independent filters for agent, owner, risk, decision and outcome — the shape of a real audit request.

How the product is ordered

Verdict first, action second, audit trail third.

Applied the same way, every time

Watch a decision happen

In a live session we trigger a policy against a real agent and follow the decision through the enforcement feed — evidence the moment it lands in the Audit Ledger below.

Book a Demo