Platform / Risk

Risk that decides, not risk that reports.

Where risk scoring is enabled for the deployment, GovernorAI scores each governed action as it's attempted and hands the score to your policy. Routine work moves. Sensitive actions wait for a named approver. Prohibited actions stop, with the policy and the evidence attached.

Request a briefing Try a risk decision

Where enabledScored at evaluation time, inline with the decision
8 factorsPublished weights, returned with each verdict
0 modelsDeterministic scoring. Same inputs, same score
Patent pending2 U.S. provisional applications · 66 claims. NVIDIA Inception member

Illustrative exampleSample data

refund-agent refunds $250 to the original payment method, inside its baseline, through the payments MCP server.

25Risk / 100, Medium

Allowed

Under $5,000 and composite below 55. Allowed and written to evidence.

Policyrefund-oversight

Matched ruleallow-routine-refund

Human authorityNot required by this rule

Execution evidenceAwaiting target receipt

A policy verdict, a human approval and a confirmed execution are three separate records.

A policy verdict and a confirmed execution are different facts.

Inspect the factors and the calculation

Action sensitivity350.20
Data sensitivity400.15
Agent trust200.15
Temporal context100.10
Financial impact150.10
Compliance context400.10
Pattern deviation100.10
MCP server risk150.10

Composite is the weighted mean of the factors. Higher factor values mean more risk, including for agent trust. The score informs the policy decision; it does not grant permission.

Risk informs the decision. Your policy grants permission.

Risk-informed. Policy-controlled.

The score is an input. Your policy is the authority.

Turn risk context into business rules without handing policy ownership to another system. Keep your existing OPA server, repository and review process, or write rules in GovernorAI's own engines. Mix engines per policy. One policy identity carries its revisions into the sidecar, the SDK and the tool gateway.

Your OPARegoGovernorAI native

Allow
Keep routine work moving.
Actions that satisfy your policy proceed without a human in the loop, and still land in evidence.
Pause
Bring the right human in.
Hold a sensitive action for a named approver. Nothing is dispatched. An authorised reviewer’s decision is recorded; it does not release the call.
Deny
Make prohibited mean prohibited.
A forbidden action stays forbidden, whatever its score. An approver cannot release it.

Explore Policy & Governance

Native policy, example

# refund-oversight, revision 7
# Rules run in priority order. The first match decides.
id: refund-oversight
governance_mode: enforcement
fail_closed: true
rules:
  - id: deny-destination-not-original
    priority: 10
    match:
      tool: "payments.refund"
      condition: { field: "args.destination", operator: "!=",
                   value: "original_payment_method" }
    action: deny
  - id: hold-high-value-refund
    priority: 20
    match:
      tool: "payments.refund"
      condition: { field: "args.amount", operator: ">=", value: 5000 }
    action: require_approval
  - id: allow-routine-refund
    priority: 100
    match: { tool: "payments.refund" }
    action: allow

# Approval workflow "finance-review": the composite pauses a
# refund the rules would allow. Every condition must match.
trigger_conditions:
  - { field: tool,       operator: eq, value: "payments.refund" }
  - { field: decision,   operator: eq, value: "allow" }
  - { field: risk_score, operator: gt, value: "54" }
steps:
  - name: "Finance review"
    type: group
    groups: ["finance-review"]

The rules behind the three examples above, in GovernorAI’s native policy format. Rules run in priority order and the first match decides, so the destination deny wins even when the refund is also high-value. Amount and destination are read from the call’s arguments at the action boundary; the composite reaches the same decision through the approval workflow’s risk_score trigger.

In the product

See risk across the estate in the console.

A recorded walk through the risk perspectives behind this page: every MCP server scored on provenance, supply chain, capability and behaviour before it is approved, AI systems classified by EU AI Act risk tier, and the obligations each tier carries.

Inside GovernorAI/ RiskRecorded demo tenant

Risk, step by step

Real product screens from a demo tenant with seeded activity. Nothing was approved, blocked or reclassified while recording.

Watch the full 2-minute walkthrough →

Recorded against a demo tenant with seeded activity. Real product screens, not a mock-up.

Explain the risk, not just the number

Eight factors, four business questions. Published, deterministic, inspectable.

No model sits in the scoring path, any more than one sits in the enforcement path. The composite is a weighted mean over the factors that apply, and the weights ship with every assessment.

Weight of each factor in the composite: action sensitivity, data sensitivity, agent trust, then temporal context, financial impact, compliance context, pattern deviation and MCP server risk. When no MCP server is involved, that factor leaves the denominator instead of scoring zero. Risk bands are separate from the policy decision.

What could it do?

The consequence, not just the command.

Action sensitivity 0.20: Read a record, delete it, or move money.
Financial impact 0.10: The value at stake if the action completes.

What is exposed?

Data and obligations in the same decision.

Data sensitivity 0.15: The classification of the records in scope.
Compliance context 0.10: The obligations in force for the system taking the action.

Who and what are involved?

Agent provenance and tool supply chain.

Agent trust 0.15: Registration, provenance and governed history.
MCP server risk 0.10: Provenance, supply chain and declared capability of the server behind the tool.

Is this normal?

When and how this agent usually operates.

Temporal context 0.10: Timing against the expected pattern for this agent and estate.
Pattern deviation 0.10: Distance from this agent's learned baseline.

Same inputs, same score

Deterministic by construction, so a number holds up when leadership or an auditor asks why.

Nothing hidden in a model

The factor vector is public. You can reproduce any composite from the record by hand.

A low score never overrides a prohibition

Bands are yours to set and policy can key on them, but a mandatory rule wins whatever the number says.

From business risk to accountable action

One policy object. A connected trail.

The requirement, the assessment, the runtime decision and the evidence all hang off the same policy identity; decision records name the policy, not yet its revision. Security, GRC and Engineering read the same record.

refund-oversight

DiscoverBind the workflow

refund-agent, payments MCP server

AssureTest the scenarios

assessment passed, r7

GovernReview the rule

approved for production, r7

EnforceDecide the action

$12,400 refund paused, r7

ProveFollow the evidence

decision record, control-linked, r7

One actionRisk plus policy: allow, pause or deny.

The composite and its factors enter the policy decision at the action boundary. Authorisation and execution are recorded as separate typed events; gateway decision events store a SHA-256 digest of the call arguments, and approval requests keep the arguments a person is asked to approve.

Operational patternConfigured alert: incident.

Metrics and anomaly signals across many actions raise alerts you configure. An alert can open an incident with an owner; pausing a policy or engaging a kill switch is an operator action.

Security

Know why an action stopped.

The context and the rule behind a deny, a pause or an escalation, on the same path that stopped the call.

GRC

Trace the control into practice.

Policy and ownership connected to the evidence of an actual decision, mapped to the obligation it serves.

Engineering

Debug the decision, not a score.

See which factors contributed and which rule determined the outcome, without touching the agent.

From understanding risk to controlling action

Assess the estate. Govern the next action.

Three risk questions, each answered in context, and the last one answered with a decision.

System context

Should this AI be deployed?

Purpose, obligations, ownership and assurance results establish the governance context.

Tier, obligations, owner

Exposure context

What could go wrong?

Tools, permissions, data and dependencies show where an agent can create risk.

Controls, suppliers, assurance

Action decision

May this action proceed?

Assess the attempted call, apply the business rule and record the outcome.

Allow, pause, deny

Six risk perspectives. One governance graph.

Each perspective has its own assessment. All of them connect through the same policy object and the governance graph.

Per action

Risk score on the decision

Composite 0–100 at evaluation time, with the factors that produced it.

NIST AI RMF

Per system

Risk tier on the AI system

EU AI Act Art. 6, 9–16, 26, 50, 52

Per control

Control effectiveness

Controls scored from real system state, resolving to pass, fail or partial.

SOC 2, HIPAA, PCI DSS

Per supplier

Tool and server risk

MCP servers scored on provenance, supply chain and declared capability before they're approved or blocked.

At approval time

Per agent

Assurance domain scores

Permissions, grounding, robustness, security, privacy and efficiency, each from a scenario battery with deterministic scoring.

Gated per environment

Per deployment

Impact assessment on record

High-risk system records with bias, mitigation, human oversight, consumer notice and appeal.

Colorado SB 26-189

A few useful answers

Built to work with the governance you have.

How does this fit with the AI security tools we already run?

Detection asks whether an interaction is malicious or unsafe. Risk governance asks whether this agent should take this action, with this data, this amount and this destination, and who has to approve it. GovernorAI brings that context into your policy and records the decision. It sits beside your existing stack rather than replacing it.

Can we keep our existing OPA and policy process?

Yes. Point GovernorAI at your OPA service and keep your repository, ownership and review workflow. GovernorAI connects the policy to the action and writes the evidence. Native rules are there when you want them, and engines can be mixed per policy.

Does a low score allow an action?

No. The score is an input your policy reads, not a permission and not a probability of harm. Mandatory rules apply whatever the score, and an approval requirement still needs an authorised response.

See it on your own workflow

See a score change a verdict.

A 30-minute briefing walks through the risk engine on one consequential workflow from your own estate. Design partners get a six-week evaluation on the agents they already run.

Request a briefing Design partner program →

Continue

Platform overviewFive stages, seven product surfaces, one policy object Policy & GovernanceOne policy, from intent to evidence Runtime EnforcementDecide at the action boundary Decision ObservabilitySee the decision behind the action Evidence & ComplianceHash-chained audit record, mapped to controls ContainmentAgent-scoped kill switches

Find and qualify

Decide and enforce

Prove and observe

Risk and security

By persona

By risk

By platform

By cloud and runtime