Do not make me open eleven repositories.
Fourteen agents, four frameworks, three teams, two of them contractors. A control that requires a library upgrade in each one is a control that ships next quarter, partially, and then drifts.
USE CASES / PLATFORM & AI ENGINEERING
Ship agents without becoming the governance bottleneck.
Governance usually arrives as a request to change every agent. GovernorAI is designed so that the common answer is you change nothing in the agent at all — the decision drops into the Envoy filter chain, the MCP proxy, the forward-auth check or the AI-gateway webhook you already operate. Where an SDK is the better fit, it is one import and one decorator on the function that makes the call. Your policy engine, your pipeline, your keys.
No SDK required in the agent Bring your own OPA Terraform provider · GraphQL Not a proxy in the token path
Five ways in, and they do not all carry the same powers. Forward-auth cannot rewrite a body; an LLM gateway decides but does not shape. failure_mode_allow must be false on ext_proc or the gate is decorative.
one decision brain5 insertion pointsyou change nothing in the agent
WHAT YOUR JOB ACTUALLY IS HERE
You are not against governance. You are against owning it in every service.
The platform team ends up holding AI governance because it is the only team that can reach the code. That is a bad place for it to live: the policy is not yours, the review process is not yours, and every change becomes a deployment you have to schedule.
We already have a policy engine, and it has an owner.
If OPA is already doing Kubernetes admission control, there is a Rego codebase, a review process and a team that answers for it. A second policy system is a migration, not an integration — and nobody asked for one.
Nothing sits in front of the model on day one.
An availability incident caused by a governance layer is the fastest way to have the governance layer removed. The first question is what happens when it is slow, and the second is what happens when it is unreachable.
The design constraint There is one decision brain. Every insertion point is a thin protocol translator into it.
Each adapter parses a tool call off the wire, builds the canonical execute request, and asks the gateway for the verdict. Policy, data controls, injection deny, approvals, the kill switch and the hash-chained evidence live in one place — adapters never re-implement any of it. That is why adding a second enforcement point does not mean maintaining a second set of rules.
GOVERN WITH NO SDK IN THE AGENT
Five places to put the decision. Four of them are infrastructure you already run.
Read the topology line on each card: the orange box is where GovernorAI sits, and the green one is something that stays yours. Read the right-hand list before you choose — an insertion point that cannot rewrite a body is honest about it rather than pretending.
Envoy ext_proc
The service mesh you already have
A gRPC external processor for Envoy Gateway, Istio, Gloo, Envoy AI Gateway and agentgateway. The identity travels in governor.* request headers, so the agent itself is unchanged. Allow continues, redact becomes a body mutation, approval returns 202, deny returns 403.
Non-negotiable: failure_mode_allow must be false. An unreachable processor has to be a deny, not a pass.
agentyour envoygovernoraiupstream
- Executesallow · deny · approval · redact
- Agent codeunchanged
- Rewritesrequest body mutation
- Watchfail-closed is a config setting you must set
MCP proxy
Transparent proxy in front of an MCP server
Point the MCP client's server URL at the proxy — that is the whole integration. tools/call is governed; initialize, tools/list, ping and notifications pass through untouched. Allow forwards, redact rewrites the call arguments, approval and deny return a JSON-RPC error.
Argument-aware inspection runs here even where prompt or response classification would be a no-op, and a retrieval body an operator declared as a fetch is inspected as untrusted content.
mcp clientgovernorai proxymcp server
- Executesallow · deny · approval · redact · mask · constrain
- Agent codeunchanged — one URL
- Rewritestool-call arguments
- Needsno gateway of your own
Forward-auth
An auth check your proxy already speaks
NGINX auth_request, Traefik ForwardAuth, an AWS Lambda authorizer, Apigee, Azure API Management. Allow returns 200; approval and deny return 403. A JSON verdict mode returns the decision and shaped arguments for guardrail webhooks.
The cheapest thing on this page to wire, and the most limited. Choose it when the decision is allow-or-not, not when a payload must be rewritten.
agentyour proxygovernorai
- Executesallow · deny · approval only
- Agent codeunchanged
- Cannotrewrite a body — the pattern has no body mutation
- Signals it
X-Governor-Shaping-Required
AI-gateway webhook
Coexistence with the gateway you already chose
A Portkey bring-your-own-guardrail webhook and a LiteLLM custom guardrail govern the model call itself, where those products already sit. GovernorAI does not replace them and does not read your provider keys — it answers the verdict question they ask it.
Our endpoint answers with an explicit negative verdict rather than a 5xx, because those hosts treat a server error as a pass.
agentportkey · litellmgovernoraiprovider
- Executesthe verdict the host asks for
- Agent codeunchanged
- Keysstay in the gateway you already run
- Watchhost defaults differ — see the honesty note
SDK · when you do want it in the code
One import, one decorator — about five minutes
Python, Go and JavaScript SDKs consult the gateway out of process for a verdict on a call the agent is about to make. The decorator wraps the function that makes the call; govern(agent) auto-detects a LangChain, LangGraph, LlamaIndex or CrewAI agent and applies the right adapter. Adapters also ship for the OpenAI Agents SDK, Semantic Kernel, AutoGen, Bedrock, Vertex AI, Azure AI Foundry and Databricks.
Denials and approvals surface as typed exceptions, and the client is fail-closed by default: if the gateway is unreachable the call denies rather than silently proceeding.
your agentsdkgovernorai
- Executesallow · deny · approval
- Agent codeone import, one decorator
- Cannotshape a payload — the consult path returns a verdict, not a body
- Defaultunreachable gateway → deny
# identity travels in governor.* request headers:
# x-governor-agent-id · x-governor-org-id · x-governor-tool
http_filters:
- name: envoy.filters.http.ext_proc
typed_config:
grpc_service: { envoy_grpc: { cluster_name: governor_extproc } }
processing_mode:
request_header_mode: SEND
request_body_mode: BUFFERED
failure_mode_allow: false # REQUIRED — fail closed# pip install governor-sdk
from governor import governed
@governed(agent_id="refund-agent-v1", namespace="governor.prod")
def run_refund(request, __gov_ctx__=None):
# the tool call is what gets a verdict — not the prompt
return __gov_ctx__.execute(
"erp.process_refund",
{"amount": request.amount, "customer": request.id},
) Honesty note — outcomes are enforcement point-dependent, and third-party hosts have their own defaults
Which of the six outcomes an insertion point can execute is a property of that enforcement point, published as a capability registry the runtime consults on every call. Ask an enforcement point for an outcome it does not declare and the result is a deny, marked as a downgrade — never a silent fallback to something weaker. Forward-auth is allow, deny and approval only because auth_request has no body mutation; it emits a header so the operator knows a redaction was requested and did not happen. The out-of-process SDK path likewise returns a decision rather than receiving a shaped payload back.
Third-party hosts are outside our control and we will not describe them otherwise: Portkey's guardrail webhook fails open on timeout, and LiteLLM's post-call hook on streaming is audit-only. Our endpoint always fails closed; the gateway-side hook must be configured to treat a webhook error as a deny, and that configuration is yours to verify per deployment.
KEEP WHAT YOU ALREADY OPERATE
Bring your own OPA. You write no policy here.
Three engines ship in the box — native rules, CEL and Rego. If your organisation has standardised on OPA, GovernorAI can call your existing server for the verdict instead: your policies stay in your repository, in your language, under your review process, owned by your team. GovernorAI contributes the agent action boundary and the evidence.
Your OPA returns the verdict
GovernorAI never holds the policy. Authentication by API key, bearer token or mTLS; the server is operated by you. Configuration is per tenant, so embedded and remote can coexist across an organisation.
an integration, not a migrationOPA as a library in the decision path
Where you do not already run OPA, it runs as a Go library inside the decision path with policies managed here or loaded from the filesystem. Nothing external to operate.
no second serverA policy can watch before it decides
audit_only records and never changes an outcome. shadow runs against live traffic in parallel with the decision in force. enforcement is the outcome at the action boundary. Nobody has to be brave on day one.
Simulate against traffic that already happened
Project what a change would have allowed, denied or held. Similarity checks surface rules that overlap or contradict, and dead-policy detection finds rules nothing reaches.
see Policy & GovernanceRemote 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. The full picture is on Policy & Governance.
GOVERNANCE THAT LIVES IN YOUR PIPELINE
Declare it. Review it. Query it. Nobody has to click through a console.
Policy is a versioned artifact with a review process, not a setting in a UI. The provider makes the governance objects declarable alongside the infrastructure they govern, and the API makes the resulting state queryable rather than exportable-on-request.
- governor_agent
- governor_namespace
- governor_policy
- governor_policy_assignment
- governor_approval_workflow
- governor_kill_switch
- governor_integration
- governor_automation_config
# policy declared alongside the infrastructure it governs
resource "governor_policy" "refund_approval" {
name = "refund-approval-v4"
governance_mode = "shadow" # promote when the diff is boring
fail_closed = true
engine = "rego"
source = file("${path.module}/policy/refunds.rego")
}# introspectable schema at /api/v1/graphql/schema
{
agents(namespace: "governor.prod", limit: 50) {
id
name
status
}
policies(namespace: "governor.prod") {
id
name
}
} Stated precisely A Terraform provider, a GraphQL API and webhooks — governance you can automate rather than click through.
Policies, assignments, namespaces, approval workflows and kill switches are declarable resources. Changes go through the review your team already uses, versions are retained so a rollback is a selection rather than a rewrite, and rollout is staged rather than all at once.
THE AVAILABILITY QUESTION
You keep the keys. This is not a proxy in the token path.
The objection that kills governance layers is the one about becoming a single point of failure for inference. GovernorAI is architected to answer a verdict question, not to relay your traffic — and where it does sit inline, the failure mode is stated rather than discovered.
The gateway does not make it for you
On the AWS Bedrock inbound path, invocations arrive from inside AWS and the Lambda proxy executes the tool after the gateway returns a decision — the gateway does not make the outbound model call. On the AI-gateway webhooks, the host holds the provider credentials and asks us only for the verdict.
verdict in, decision outTLS is not terminated
The cluster-side egress agent governs each outbound CONNECT tunnel at host and port level, then opens raw TCP forwarding on allow. The body stays encrypted end to end between the caller and the destination — one decision per tunnel open, and that limit is stated rather than papered over.
not a man in the middleAn explicit budget, and a stated failure mode
The decision client carries an explicit timeout — five seconds by default, configurable per deployment — and expiry resolves to deny, never to allow. A transport error is synthesized as a deny and marked as fail-closed, so it is distinguishable in your logs from a genuine policy deny.
you can measure it before you trust itNothing in the path on day one
Discovery reads the telemetry and control planes you already run — no agent to install in the request path, no configuration change to the systems being inventoried. A source can be previewed end to end with a test payload through the real adapter that persists nothing, before you point live telemetry at it.
see Discovery & Shadow AIOutside your delivery stack, on purpose
GovernorAI does not host your agent, replace its harness, or require a rewrite. It evaluates and governs an agent you already built, on a framework you already chose. Adding agent creation would erase the reason to trust the governance.
no agent-builder replacementCredentials scoped to the thing that uses them
Each discovery source gets its own bearer token, bound to that source and that account, rotatable and revocable on its own — a full account API key is never handed to a forwarder. Rate limits run per key, endpoint and role.
per-source, revocable Honesty note — inline means inline, and end-to-end shaping is not universal yet
Four of the five insertion points above put GovernorAI on the request path, and an inline component is an availability dependency you have to plan for. That is why the timeout is explicit, why the failure mode is deny rather than a guess, and why audit_only and shadow exist so a policy can be proved against production traffic before it is allowed to block anything.
End-to-end redaction on an inbound self-execute caller depends on the gateway returning shaped arguments, which it materialises for the Bedrock enforcement point today. Until that is generalised, ext_proc and the MCP proxy are the paths that enforce allow, deny and approval end to end. We would rather write that sentence than let a diagram imply otherwise.
THE PAGES THAT ANSWER THE REST
Everything above is a pointer into a page that states its own limits.
A persona page is a route, not a specification. These four are where the mechanics — and the crosses in the capability tables — actually live.
The contract Runtime Enforcement Seven registered enforcement points, six outcomes, and the published matrix of which enforcement point executes which — plus the full table of conditions that resolve to deny. Your engine Policy & Governance Native, CEL, Rego or your own OPA server; governance modes; and a lifecycle with separation of duties, staged rollout and retained versions. Operating it Decision Observability Decision latency at p50, p95 and p99 per governed agent, drift against an approved baseline, alert rules that can act, and incidents that open themselves on an SLO breach. Your pipeline Assurance A CI/CD gate with five distinct exit codes, an immutable snapshot pinned by config hash, and verdicts that stale when the policy path moves under them.