See the decision behind the action.
Know what an AI agent was permitted to do, why the policy decided it and what followed. One governance trail from verdict to response to evidence — across every agent you run, on every runtime.
dec-1182A payment above the agent's tier.
The action was held for a person. Who approved it, and how long it waited, stay attached to the decision.
- event
- action.evaluated
- agent
- billing-agent-v4 · prod
- tool
- erp.process_payment
- args_hash
- sha256:7c31…a904
- policy
- refund-approval-v4
- risk
- 74 · high
- decision
- require_approval
- reason
- above tier threshold
- seam
- gateway_execute
- latency_ms
- 6
- Evaluated
refund-approval-v4 matched; risk 74 is above the auto-approve tier.
- Execution held
erp.process_payment did not run. The request sits in the approval queue with its decision attached.
- Reviewer assigned
Routed to the finance approvers group; m.hoda picks it up.
- Approved · 41 s
Approver identity taken from the session, not the client. Decision latency recorded against the agent.
- Not released
The approval does not release the held call, so erp.process_payment did not run.
- Policy changed after review
After review, rev 13 raises the auto-approve tier. The revision is not yet linked to this decision in the record.
- Decision reference
- dec-1182
- Policy reference
- refund-approval-v4
- Audit event
- ev-2291
- Argument digest
- sha256:7c31…a904
- Recorded outcome
- approved · not executed
- Related
- apr-0417
The decision, the policy reference and the response belong to one governance trail — the same record enforcement wrote.
Enforcement decision → governance record. Sample records in the shape the product writes. Decision events carry a digest of the tool-call arguments.
The console
The operator view of every decision.
In the product
See decision observability in the console.
A recorded walk through the screens behind this page: governed decisions in one log, one denial opened to show the agent, the tool, the policy that decided and the trace, and the governance graph that links policies, agents, evidence and controls.
Observability, step by step
Real product screens from a demo tenant with seeded activity. Nothing was approved, denied, saved or reassigned while recording.
Keep your observability. Add governance context.
Keep the tools your teams use for traces, metrics and performance. GovernorAI decisions flow into that workflow through OpenTelemetry and standard exporters. Nothing leaves until you configure one.
Keep the trace. Add the decision, the response and the evidence.
Three ways to turn visibility into control.
The verdict is the record.
Go from a blocked or held action straight to the policy that matched, the risk score, the explain code and the approval path. The alert, the incident and the evidence entry hang off that one record.
action → policy → outcomeWatching can pull the brake.
Decision latency to p99 per agent, ranked against your own fleet. Drift against the baseline you approved. And rules that do more than page: each can open an incident with an owner.
fleet context, not isolated alertsOne trail, two readers.
Carry the investigation into the incident, the policy change and the audit record without losing context. The path a security engineer follows during an incident is the record an auditor is shown afterwards.
the investigation becomes the recordControl what happens next.
A warning is the beginning. A rule can open an incident with an owner in the same control plane, not a message someone reads on Monday. Stopping an agent stays an operator action.
Find the signal.
Denial spikes, p99 latency, policy drift, governance SLO breaches — thresholds you set, on the estate you run.
Put control in motion.
The rule opens an incident. An operator can stop one agent with the kill switch without touching the fleet.
Keep the context.
The affected agents, policies, owners and every status change, on one timeline with the decision that started it.
Change the next decision.
Root cause, action items with owners and due dates, and the reviewed policy change linked back to the post-mortem.
See what one decision touches.
A policy does not live alone. Every decision is joined to the agent it governed, the control it supports, the approval it waited on and the evidence a reviewer needs — derived from live state, not drawn by hand.
This policy governs billing-agent-v4 and supports the payment-authorization control. It is the node the decision, the approval and the evidence all point back to.
Every question has a home.
Right now
- Live decision feed
- What is being allowed, denied and held, against which tool calls
- Approval queue
- What is waiting on a person, and for how long
- Agent fleet health
- Which agents are slowest, ranked against your own fleet
- Kill switches
- What is quarantined, and the scope it applies to
Over time
- Drift
- Which policies changed since the baseline you approved
- Governance analytics
- Thirty days of actions evaluated, blocked and held, and the tools blocked most
- Governance graph
- How a policy, control, regulation, agent, incident and piece of evidence connect
- Agent topology
- Which agents call which, and the blast radius of any one of them
When it breaks
- Alerts and rules
- What pages a human, on which threshold, with which automatic response
- Incidents
- What is open, at what severity, owned by whom, on which agents and policies
- Tracing
- The decision path for one call — spans, timings, dependencies
- Post-mortems
- What happened, why, and the policy changes that came out of it
Built to be believed by an auditor.
Measured, or labelled as not measured.
Every number has a declared source. A widget with no live source says so instead of showing a plausible figure, and the console tells you whether your tenant's data is live, stale or historical.
Decision events carry a digest.
Gateway decision events record a SHA-256 digest of the tool-call arguments by construction — not a masking setting someone has to remember to turn on. An approval request keeps the arguments a person is asked to approve, so treat the approval queue as holding them.
Recorded where governance happens.
Decisions, approvals, kill-switch activations and incidents are written by the governance path itself, not collected afterwards from telemetry. Reviewer identity comes from the session, never the client, and retries are idempotent.
Where this fits.
Decision observability connects runtime governance to the operations your teams already run.
How is this different from agent tracing?
Tracing shows how a workflow ran — spans, tool calls, tokens, latency. GovernorAI adds the authority behind each governed action: the policy that evaluated it, the decision it produced, who approved it and what followed. Keep both: one explains behaviour, the other records authority.
Can an alert trigger a response?
An alert rule can open an incident with an owner. Pausing a policy, running a runbook or engaging a kill switch is an operator action today, not something the rule does.
How does this connect to audit evidence?
The investigation follows the governance record that enforcement wrote. That record is the same one the Evidence & Compliance layer maps to controls — there is no second pipeline to reconcile.
Do we need to replace our monitoring tools?
No. Keep your APM, tracing and SIEM. GovernorAI exports decisions and spans through OpenTelemetry with OTLP, Prometheus, Jaeger and Zipkin exporters, selectable per deployment.
Move from visibility to governed action
Bring one workflow. See the whole governance trail.
Walk through one of your own decisions, its response path and the evidence your team would need to explain it. A design-partner evaluation runs six weeks on your agents, your policies and your traffic.