A composite 0–100 score computed at evaluation time and attached to the verdict, with the factors that produced it.
risk enginePLATFORM / RISK
Risk that decides, not risk that reports.
A risk score that lives in a register is read once a quarter. GovernorAI scores the action, and hands that score to the policy engine as a decision input — so the assessment is applied at the moment it matters, on the same path that stops the call.
Composite 0–100, eight weighted factors Available to policy as decision input Mapped to NIST AI RMF functions
A composite score computed at evaluation time from eight weighted factors — the eight RiskCategory values the risk engine declares, all of which are scored in non-test code.
composite 0–1008 weighted factorsNIST AI RMFdecision input
THE DIFFERENCE
Assessed from execution, not from a questionnaire.
Conventional GRC risk is gathered by asking people what they think is risky, on a cadence, and recorded away from the systems it describes. Here the inputs are the governed calls themselves — what was attempted, by which agent, against which data, how far outside its baseline.
Register an AI system and receive a tier from a scored classifier, with obligations tracked against a requirement library — EU AI Act Articles 6, 9–16, 26, 50 and 52.
triage, not a legal determinationControls scored from real system state rather than a questionnaire, resolving to pass, fail, partial or not_assessed.
MCP servers scored on provenance, supply chain and declared capability before they are approved or blocked.
at approval timeHigh-risk system records across the seven consequential-decision domains, with impact assessments covering bias risk, mitigation, human oversight, consumer notice and appeal.
Colorado SB 24-205Permissions, Grounding, Robustness, Security, Privacy and Efficiency, each with a preregistered scenario battery and deterministic scoring. An unwired domain reports not_assessed rather than a pass.
THE RISK ENGINE
What goes into the score.
Weighted, deterministic, and inspectable. No model sits in this path any more than it sits in the enforcement path.
Factor
What it contributes
Role
Action sensitivity
How consequential the operation itself is — a read against a delete against a transfer.
weighted
Data sensitivity
What the call touches: the classification of the records in scope.
weighted
Agent trust
What this agent has earned, from its registration, provenance and governed history.
weighted
Temporal context
When the action is attempted, against the pattern for this agent and this estate.
weighted
Compliance context
Which obligations are in force for the system taking the action.
weighted
Pattern deviation
How far the call sits from the learned baseline for this decision metric.
weighted
MCP server risk
The provenance, supply chain and declared capability score of the server behind the tool.
weighted
Financial impact
The eighth factor, resolved from source:
CategoryFinancialImpact in internal/risk/types.go. Eight RiskCategory values are declared and all eight are referenced in non-test scoring code.financial_impact
The weights are the policy decision, not ours to assert. They are not configurable per deployment. The vector is a compile-time constant in NewEngine — action sensitivity 0.20, data sensitivity 0.15, agent trust 0.15, and 0.10 each for temporal context, financial impact, compliance context, pattern deviation and MCP server risk. No config file, environment variable, database column or API writes them; the only risk settings an operator can change are the band thresholds and the MCP assessment TTL. The weighting is published rather than opaque: every assessment returns each factor with its weight and its weighted value, the composite is the weighted mean over the factors that apply, and the MCP factor is removed from the denominator rather than scored zero when no MCP server is involved. Two things an assessor should be told with it: the vector and the Critical cutoff are uncalibrated — chosen so a maximally egregious action could reach Critical at all, not fitted to traffic — and the calibration harness can re-derive every stored composite under a candidate vector, but it does not choose one and nothing applies one at runtime.
EVENT TO TREATMENT
How an event becomes something someone owns.
The chain already exists end to end. It is described across Decision Observability and Evidence today rather than named as a risk lifecycle.
01
Every governed action writes a typed event
requested, evaluated, executed, denied, paused — alongside approvals, session lifecycle, kill-switch activations and policy changes. Call arguments are recorded as SHA-256 digests, never raw values.
02
The action carries its score
The composite risk score is attached to the decision, with the factors that drove it, so the judgement is inspectable rather than asserted.
03
Thresholds turn a pattern into an alert
Deny rate, error rate, p95 and p99 latency, request count and queue depth — scoped globally or to a namespace, agent or policy.
04
The alert acts
Open an incident, pause a policy, or engage a kill switch. This is the step most risk tooling does not have: the finding changes what the estate is permitted to do.
05
The incident carries an owner
Incidents hold severity and assignment. In the governance graph the relationship is a typed
assigned_to edge, joined to policies, controls, regulations, agents and evidence.06
The post-mortem closes it
What happened, what caused it, and which action items came out of it — with
triggered_by and derived_from edges preserving the causal chain.STATED PRECISELY
Risk assessment, and risk-informed enforcement.
Stated precisely GovernorAI assesses risk continuously from governed execution, and applies that assessment inline at the action seam.
Coverage follows enforcement coverage and does not exceed it. Where there is no supported action seam there is no decision, therefore no score — and the console says so rather than filling the gap with an inferred value.
Honesty note
This is not a risk management system in the ISO 31000 sense, and the page does not claim to be one. Three things a GRC assessor will ask for are not evidenced here. There is no likelihood dimension — the composite scores consequence and context, not probability. There is no risk register as a first-class object: the governance graph declares a risk node type alongside policies, controls, regulations, models, agents, groups, evidence, incidents, approvals and kill switches — but nothing projects one. The constant appears only in its own declaration and in the list of valid types, so the register is a declared shape with no rows behind it. And there is no acceptance path — no way to record that a risk was accepted, by whom, with an expiry and a review date.
Those are gaps in the claim, not necessarily gaps in the product. Confirmed against the codebase, and the page is correct. Nothing persists a risk with an owner: the risk store holds assessments, per-agent profiles and MCP server profiles, and none of them carries an owner, an accepted state or a review date. The acceptance path is absent by the product’s own admission — the assurance API declares a risk-acceptance record and then reports supported: false on every response, because no approver, timestamp or justification is stored and no endpoint creates or revokes one. Two adjacent mechanisms exist and should not be mistaken for it. A governance exception does carry a mandatory reason, a requester, an expiry and an approval path — but it exempts a binding from a policy, not a risk from treatment, and no one is named as owning the residual. And an MCP server score expires on a configurable TTL, which forces re-assessment of a supplier but is not a review cadence over a register. The register, the owner and the acceptance record are the roadmap item.