Our own inline adapters — the Envoy filter, the MCP proxy, the forward-auth endpoint — translate protocol, never policy. None of them can invent a verdict, an approval or an audit record of its own.
PLATFORM / OVERVIEW
Five stages, seven product surfaces — and seven places a decision can land.
Security, risk and compliance block agents that can act. GovernorAI finds the agents nobody registered, checks what each one is allowed to do before it ships, decides each consequential action against that same policy — allow, deny, or hold for a human — and writes a record your auditors can verify. You keep building: we don’t build, host or take over your agents.
One policy object across all five stages Seven enforcement points, capability published Read-only discovery needs no enforcement decision
Governance lifecycle · sample environment
org_sample_01 04 / ENFORCE Refund held for approval
erp.process_payment · $12,400 · rule 3 → require_approval
target system: unchangedEvidence stream connected
illustrative valuesModels decide. Agents act.
GovernorAI governs both.
THE PLATFORM
One policy model, and a decision core every enforcement point defers to rather than reimplements. Start at any stage — discovery is read-only and needs no enforcement decision.
01 · Discover
Discovery & Shadow AI
Inventory the agents, tools, MCP connections and SaaS copilots nobody registered — read-only, from sources you already run.
See discovery → 02 · AssureAssurance
Evaluate an immutable agent snapshot against preregistered bars before it reaches production. Six domains, with measurability computed per deployment.
See assurance → 03 · GovernPolicy & Governance
Write it natively or in Rego — or point at the OPA server you already operate and write no policy here at all.
See policy → 04 · EnforceRuntime Enforcement
Allow, deny, approve, redact, mask or constrain at the action boundary — and only the outcomes an enforcement point can genuinely carry out.
See enforcement → 04 · EnforceInference & Model Governance
Which models may be called, what may be sent, and what may come back — governed without sitting in your token path.
See inference → 05 · ProveEvidence & Compliance
A hash-chained, tamper-evident record of governance actions, mapped to the controls an assessor will ask about.
See evidence → Across the loopDecision Observability
Policy verdicts, approvals, drift and fleet health — the record of what a control did and why.
See observability →Seven enforcement points, and they do not all do the same things. The capability matrix prints, for each one, the outcomes it can carry out and the ones it cannot.
Scope boundary You build the agent. GovernorAI independently governs what it is allowed to do.
We do not build your agents, host them, or sit in the availability path of every token. That independence is why the evidence stands up when a security or compliance team examines it.
ONE OBJECT, THE WHOLE WAY
The policy that cleared the gate is the policy that stopped the action — and the one the control report attests.
The stages themselves are not the differentiator. What matters is whether one object survives the whole way, or whether each stage holds its own and you are left arguing they agree.
Stage
What that one object does there
01 · Discover
Before there is one. Read-only inventory of the agents, tools, MCP connections and SaaS copilots nobody registered — so you know what needs a policy at all.
02 · Assure
It is written, and the agent is judged against it. An immutable snapshot scored against preregistered bars before release — against the rules that will actually govern it, not a separate test suite that resembles them.
03 · Govern
It is authored once. Native DSL or Rego — or point at the OPA server you already operate. One object, not one per enforcement point and not one per cloud.
04 · Enforce
It decides. The same rules evaluate each consequential action at the point it would take effect — allow, deny, or hold for a named human — at the action boundary and the inference boundary both. Seven enforcement points defer to it rather than reimplementing it.
05 · Prove
It becomes the evidence, and the compliance answer. The decisions are the record — hash-chained and tamper-evident — and control status is computed from those same decisions, mapped to the frameworks an assessor asks about. Compliance is produced by the enforcement rather than assembled afterwards from screenshots.
Across the loop
It is observed the whole time. Verdicts, approvals, drift and fleet health — the record of what that policy did and why. Observability is not a stage; it runs across all five.
The question this makes askable. Can your evidence prove the policy that passed your pre-production gate is the policy that made this decision? GovernorAI enforces the control and attests to it from the same policy object, so the thing that decided the action and the thing the control report describes cannot drift apart. See where that lands against what you run →
WHAT DECIDES, AND WHAT ONLY ADVISES
No model sits in the decision path.
The control that stops a payment is deterministic: your policy, evaluated against the action. Machine learning is used where a mistake is recoverable — drafting a rule, spotting an anomaly — and kept out of the moment where it is not.
An optional semantic detector is off unless an operator enables it, and can only add a deny, never an approval.
A draft a human signs off
Describe the rule in plain language and get a policy back. It lands as a draft, moves to reviewed only when a person says so, and reaches deployed after that. Nothing an assistant wrote enforces anything until somebody approved it.
The same input, the same verdict
Policy evaluated against identity, action, resource and context. No inference call, no confidence threshold, no drift. Run it twice on the same action and you get the same answer, which is what makes the record worth showing an auditor.
Learns beside the path, not on it
Behavioural analysis over governed-action telemetry runs asynchronously and feeds back risk signals and proposed rules. It never returns the allow or the deny.
This is the split GovernorAI is built around. Where a runtime control is itself a classifier, every decision inherits a confidence score, an inference latency and a retraining schedule. Here the model proposes and a person disposes, and by the time an action is evaluated the answer is already fixed in rules. In the sidecar topology that evaluation is CPU-bound and the decision never leaves the host. A typical evaluation costs ~0.13 µs in-process policy evaluation (Go benchmark, Apple M4 mean; excludes transport, serialization and audit I/O) — cheap enough that anything you can measure in a deployment is the hop around the decision, not the decision. That figure is a mean, not a p99 on your production hardware, and the page that carries it says so. See the number and every condition behind it →
WHY ONE CONTROL POINT IS NOT GOVERNANCE
Ten links. A guardrail is one of them.
A proxy in front of it, a guardrail on the prompt, an authoriser on the tool call — each answers one question in the middle of this chain. The links either side are where governance actually lives, and they are the ones a security team is asked about when something goes wrong.
Discovered→ Inventoried→ Risk-assessed→ Observed→ Authorised→ Held for a human→ Contained→ Drift detected→ Evidence retained→ Compliance assessed→
This is a loop you operate, not a conveyor that runs itself — several links are deliberately something you invoke rather than something that fires on its own, because an assessment nobody asked for is an assessment nobody trusts. What matters is that the links share one policy model and one place to read what happened, and that what it decided is written down where an assessor can read it, instead of scattered across nine tools’ logs. Any single control — gateway, guardrail or tool authoriser — gives you one link and leaves the other nine to you.
See what each of the seven enforcement points can carry out →