GovernorAI evaluates
OPA runs as a Go library inside the decision path. Policies are managed here, or loaded from the filesystem. Nothing external to operate.
- mode
- embedded
- source
- managed · filesystem
- operated by
- GovernorAI
Platform / Policy & Governance
Keep the policy engine you already run.
Three engines ship in the box — native rules, CEL expressions and Rego. If your organisation has standardised on OPA, point GovernorAI at your existing server: your policies, your language, your review process. You write no policy here.
Native · CEL · Rego Embedded or remote OPA Fail-closed by default
loading…SEPARATION OF CONCERNS
Two ways to run policy. Both are first-class.
OPA is CNCF-graduated and already deployed across many enterprises for Kubernetes admission control. Where that is true, the platform team has an engine, a Rego codebase, a review process and an owner — and no appetite for a second policy system. Configuration is per tenant, so both modes can coexist across an organisation.
Your OPA evaluates
GovernorAI calls your OPA server for the verdict. Your policies stay in your repository, under your review process, owned by your team. GovernorAI contributes the agent action seam and the evidence.
- mode
- remote
- source
- external
- auth
- api key · bearer · mTLS
- operated by
- you
What this changes Governance stops being a migration and becomes an integration.
The usual objection to a governance platform is that it asks a team to move its policy into a new system, learn a new language, and re-run an approval process that already works. In remote mode none of that happens. The policy engine, the language and the separation of duties stay where they are; what GovernorAI adds is the point of enforcement and the record.
Honesty note
Remote OPA is a deployment configuration, not a default — a tenant-supplied server address is treated as untrusted and cannot be pointed at loopback, private or cluster-internal addresses; only an operator-configured address may reach a sidecar. Policy semantics can differ between engines, and where a policy is transpiled the divergence is reported rather than silently resolved.
BEFORE YOU ENFORCE
A policy can watch before it decides.
Every policy carries a governance mode. The same rule can observe traffic, run alongside the real decision, or take the decision — so a team can prove a policy behaves correctly against production traffic before it is allowed to block anything.
audit_only Watch
The policy evaluates and records. It never changes an outcome. Use it to learn what a rule would have caught.
shadow Run alongside
The policy runs against live traffic in parallel with the decision in force, so its verdicts can be compared before promotion.
enforcement Decide
The policy's verdict is the outcome at the seam. fail_closed governs what happens when it cannot resolve.
Why it matters for adoption Nobody has to be brave on day one.
The read-only entry point is not just discovery. A policy can be written, tested against recorded traffic, and run in shadow against production before anyone grants it the authority to deny. Enforcement becomes a decision made with evidence, rather than a leap.
POLICY LIFECYCLE
From draft to enforced, with separation of duties.
Numbered because the order is load-bearing: a policy cannot be promoted past a stage it has not cleared.
Author
Write in native rules, CEL or Rego — or bring policy in from your own repository. Templates and natural-language drafting assist; neither is required.
templates · NL draftingTest
Run a policy against fixtures and recorded traffic. Similarity checks surface rules that overlap or contradict; dead-policy detection finds rules nothing reaches.
testing · similarity · dead policySimulate
Project the effect before it lands: what a change would have allowed, denied or held, against traffic that already happened.
simulator · impact predictionApprove
Change management with separation of duties: the author is not the approver, and the approval is attributable to a named person.
change management · approvalsRoll out
Promote in stages rather than at once, with versions retained so a rollback is a selection rather than a rewrite.
staged rollout · versions Honesty note
Effectiveness reporting describes what policies did against observed traffic. It is not a claim that a rule set is complete, nor that an unreached rule is unnecessary — a policy nothing has triggered may simply be waiting for the case it exists for.
POLICY GRAPH · GOVERNANCE GRAPH
See what a rule actually governs.
A policy in isolation tells you little. Two graphs answer the questions that come up in review: which agents, tools and seams does this rule reach — and for a given governed action, which policy decided it, under whose approval, against which control.
Reach and overlap
What a policy binds to, where two rules overlap, and which rules are never reached. The answer to "if I change this, what moves?"
Decision to control
A cross-domain map from a governed action back through the policy, the approval and the evidence to the control it satisfies.
What changed, and when
Policy versions, approvals and rollouts on one timeline, so a reviewer can reconstruct the posture at the moment an action was decided.
POLICY AS CODE
Governance that lives in your pipeline.
Policy is a versioned artifact with a review process, not a setting in a console. It can be declared, planned and applied like the rest of your infrastructure.
# policy declared alongside the infrastructure it governs
resource "governor_policy" "refund_approval" {
name = "refund-approval-v4"
governance_mode = "shadow"
fail_closed = true
engine = "rego"
source = file("${path.module}/policy/refunds.rego")
} Stated precisely A Terraform provider, a GraphQL API and webhooks — governance you can automate rather than click through.
Policies, assignments and governance modes are declarable. Changes go through the review your team already uses, and the resulting decision record is queryable rather than exportable-on-request.
IN THE PRODUCT
The surface this page describes.
