One policy.
From intent
to evidence.
GovernorAI puts a single policy record at the center of agent governance — from the first discovery to the last line of the audit log. Author it in native rules or Rego; CEL authoring is planned. Evaluate it with the OPA you already run, or ours. Learn it from traffic. Test and version it before it ever decides — and prove afterwards exactly which rule decided what, under whose approval, against which control, with every gap visible.
# the condition is on the action's own value, not the prompt
- id: hold-medium-refund
match:
tool: "finance.process_refund"
conditions:
- { field: "args.amount", operator: ">", value: 1000 }
- { field: "args.amount", operator: "<=", value: 10000 }
action: require_approval
approver_role: finance-managerpackage governor.refunds
# the same revision, projected to Rego for your OPA
decision := "require_approval" if {
input.tool == "finance.process_refund"
input.args.amount > 1000
input.args.amount <= 10000
}
approver_role := "finance-manager"// the same rule, transpiled from Rego to a CEL subset
// (deploying it to Envoy is planned)
request.tool == "finance.process_refund" &&
request.args.amount > 1000 &&
request.args.amount <= 10000
// match → hold, enforced at a seam that can hold itFive stages. One record. Reconciled by the system, not by you.
Most governance stacks hold a policy in a register, a different rule in a gateway, a third in a detector profile, and reconcile them in a spreadsheet before an audit. GovernorAI carries one policy object through the whole life of an agent action, so the question "which rule decided this, and which reviewed control mapping does its evidence support?" has one answer.
In the product
Follow one policy through the product.
Recorded on a demo tenant: the policies hub with each policy's engine and mode, one policy's approval rules, what the runtime enforces now, and the policy graph flagging uncovered agents.
Policies, step by step
Four screens from a recorded demo tenant.
Write policy in the language your team already speaks.
Security teams want readable rules. Platform teams have a Rego codebase and a review process. GovernorAI accepts both, mixes them per policy and per scope, and keeps the engine you already operate in the decision path.
GovernorAI rules
A tool pattern plus a condition on the call's own arguments — field, operator, value — with allow, deny or hold for a named role as the outcome. The language the AI Policy Lab drafts in.
OPA inside the box
OPA runs as a Go library in the decision path. Policies managed here or loaded from your filesystem. Nothing external to operate.
Keep the engine you run
Point GovernorAI at your OPA server. Your policies stay in your repository under your review process. GovernorAI contributes the action seam and the evidence. You write no policy here.
CEL authoring is planned
CEL policies can be stored and compiled in the policy registry today; evaluating them at a seam is planned. Rego already compiles to a CEL subset for Envoy, Kubernetes admission and the Google Cloud edge.
A Native refund rule and a Rego data-governance policy from your platform team can both bind to the same agent. The seam evaluates each of them and records which rule decided. A mandatory deny wins; every required authorization must be satisfied; a missing decision never becomes allow; a hold stays pending until it is satisfied at a capable point. A target that cannot express a mandatory control blocks whole-policy publication — nothing is weakened silently.
The usual objection to a governance platform is that it asks a team to move its policy into a new system and learn a new language. In remote mode none of that happens. It becomes an integration: keep your OPA, your repository and your review process, and connect its decisions to agent assurance, controlled rollout and evidence.
Observe before you enforce. Then let the evidence draft the policy.
Nobody knows on day one which tools an agent really calls, with which arguments, in which order. So don't guess. Run the new candidate in observe mode for a few days while your existing controls stay active. The Lab learns what normal looks like, drafts a least-privilege candidate in the engine you choose, and shows every observed call behind every rule. Observed behaviour is evidence, not permission: frequency never grants authority, denied actions become negative tests, and business limits come from a named owner. A named human — never the Lab — decides whether it is promoted.
Observe
Candidate not enforced; existing controls stay on. Every tool call, argument and denial is recorded, with gaps named.
Patterns
Tools, argument ranges, resources, sequences, time-of-day — with support counts, low-volume warnings and named gaps.
Draft
Rules in Native or Rego. Unexercised tools default to deny.
Human review
Accept, edit or reject per rule. The Lab cannot approve its own draft.
Shadow
Runs beside the live decision; every divergence reported.
Enforce
Promoted to enforcement. Staged rollout, retained versions.
pattern file.write to /external/* 3 of 12,480 calls support 3 of 3 file.write calls · low volume egress signal authority owner decision pending (REQ-083) rule deny-external-write → action: deny evidence the 3 observed calls, linked status draft · awaiting review by priya.n (GRC)
Natural-language authoring turns a sentence someone typed into a rule. Learning turns what the agent actually did into a candidate, with the calls that justify it attached — the way IAM Access Analyzer generates a least-privilege template from access activity, applied to agent actions. Both can ground a draft — an approved written requirement, or observed behaviour with its calls attached — and the Lab records which one each rule rests on.
Two human decisions stay separate: approving a revision approves exact content and a release plan; approving a held action records a decision on that one held request, which expires; it does not release the call. A hard deny is never releasable by a click.
From draft to enforced.
Numbered because the order is load-bearing: a policy cannot be promoted past a stage it has not cleared. Hand-written, template-driven, managed in Terraform or learned by the Lab — the lifecycle is the same.
One policy object connects everything, from discovery to operations.
A policy in isolation tells you little. The graph is built from live policies, agents, tools, decisions and evidence, and answers the questions that come up in review — and in incident response.
Reach and overlap
What a policy binds to, where two rules overlap, which rules are never reached, which agents nothing reaches. The answer to "if I change this, what moves?"
Decision to reviewed mapping
Trace the action through its policy, approval and evidence to the reviewed control mapping it supports. An assessor walks it the other way. A single decision supports a mapping; it does not establish control effectiveness.
Timeline
Versions, approvals, rollouts and decisions on one line, so a reviewer can reconstruct the posture at the moment an action was decided.
Governance that lives in your pipeline.
Policy is a versioned artifact with a review process, not a setting in a console. Declare it, plan it and apply it like the rest of your infrastructure. Changes go through the review your team already uses; the decision record is queryable rather than exportable-on-request.
- Terraform provider, GraphQL API, webhooks
- Branches, diffs and a version history for every policy
- Same lifecycle whether the policy came from a template, the Lab or a pull request
resource "governor_policy" "refund_approval" {
name = "refund-approval-v5"
engine = "native" # or "rego"
governance_mode = "shadow" # audit_only | shadow | enforcement
fail_closed = true
source = file("policies/refunds.yaml")
tests = file("policies/refunds.test.yaml")
}
resource "governor_opa_remote" "platform" {
url = "https://opa.prod.internal:8181"
auth = "mtls" # your policies, your review
}The questions a careful buyer asks, answered the careful way.
Does "one policy" mean the same code runs everywhere?
No. It means one stable governance identity connects its requirements, revisions, executable definitions and target artifacts; evidence names the policy, not yet its revision. Native rules, Rego and the CEL subset Rego compiles to do not have identical semantics. A mandatory control a target cannot express is rejected or enforced at a capable seam — never dropped quietly.
Can we keep our existing OPA?
That is the intended model. The integration still needs authentication, request and result mapping, source ownership, version provenance, timeout handling and tests. Changes to your policies keep going through your workflow, not a rewrite inside GovernorAI.
Does AI learning require turning off our policies?
No. Observe without enforcing the new candidate while existing controls stay active, in a bounded window with redaction and retention set by you. Frequency alone never establishes permission or business authority.
Does passing the tests prove the agent is safe or compliant?
No. Tests establish evidence for defined cases, snapshots, evaluators and environments. A control mapping is support for a control's intent, not proof the whole control is satisfied — and an allowed action with no execution receipt is shown as unknown, not as success.
Bring one consequential workflow
Drop it into the environment you already run.
Sidecar, tool gateway, your OPA server or a provider-native target — no agent code changes on those paths; a thin SDK wrapper where a framework is governed. Six-week design-partner evaluation.