Control the action.
Not just the access.
When agents move from answering questions to changing systems, policy has to reach the action. GovernorAI decides the call an existing agent is about to make, at the gateway or proxy you already run, and carries out only the outcomes that enforcement point can execute.
Inspect this decisionSample data
ADD, DON’T REPLACE
Add action governance. Keep what already works.
You do not need a new agent platform to put a business decision in front of a consequential action. Start with an enforcement point you already have and the policy ownership your organisation already runs.
Keep your policy authority
Native rules, embedded Rego, or your existing OPA server in remote mode. Your repository, reviewers and policy owners stay where they are; the enforcement point asks that engine for the verdict and maps in the action context it needs.
Decide on consequence, not only access
Access control answers whether this identity may act, and that answer is settled upstream. This layer adds the question that comes next: is this particular action, with these arguments, consequential enough to need a person, a narrower payload, or a stop.
One policy, each cloud's own controls
Where Bedrock, Foundry or Vertex ship their own guardrail plane, the same policy compiles down to it, with any divergence named. The inline enforcement point still governs the tool call at the gateway.
In the product
See runtime enforcement in the console.
A recorded walk through the screens behind this page: decisions at the action boundary, a held action, what each enforcement point can execute, and the record every decision leaves.
Enforcement, step by step
Real product screens from a demo tenant with seeded activity: the outcome, the rule and the reason for each governed action.
ONE GOVERNED ACTION
One refund. Three governed paths.
The same tool. A different consequence. Change the request and watch the policy decision, the human response and the execution result stay separate.
interactive example · synthetic data · no live requests
{
"agent": "support-agent",
"tool": "support.issue_refund",
"order": "ORD-1048",
"amount": 12400,
"currency": "USD",
"destination": "original_payment_method"
} Original payment method only.
Above $10,000 → Finance approval.
Otherwise → Allow.
Access allowed. Finance approval still required.
The tool is permitted. The refund crosses the configured threshold, and the requirement names a role, not a person, so the hold is not satisfied until someone holding that role responds.
Approval is not execution, and it does not release the held call.
This walkthrough shows the inline gateway path. How the hold is carried differs by enforcement point: the gateway and Bedrock inbound paths hold the request; on the SDK consult path the caller receives pause and implements the stop. The integrations page states it per path.
Permission isn't proof of execution.
A policy decision says whether an action may proceed. A human response records authority. A target confirmation says what actually happened. The record keeps them apart instead of collapsing them into one green check.
Gateway verdicts carry an explain code and a reason, and are recorded with the action context that produced them, allows included. Evidence & Compliance
OUTCOMES
Six things an enforcement point can do to an action.
Three decide its fate. Three change its payload. The split matters, because a point that can decide is not automatically a point that can rewrite.
Decide the action's fate
Proceeds unchanged. The call is dispatched as written and the decision is still recorded. An allow is evidence, not an absence of governance.
Blocked before dispatch. On an inline path the target never sees the call and the caller gets the policy reason rather than a result. On a before-commit path the write is aborted. After-event surfaces contain; they do not prevent.
Held for a human. Carried as require_approval in evidence, delivered as pause at the SDK and HTTP boundary, and as a 202 on the Bedrock inbound path while the request waits.
Shape the action's payload
Value replaced with a non-recoverable token. Driven by the secret detector. Request arguments and, where the point supports it, response bodies in flight.
Value replaced with a deterministic mask. Driven by the sensitive-data classifier and by validated identifiers: Luhn-checked card numbers, range-checked US SSNs.
The offending argument key is dropped. Request side only, reaching into JSON sub-fields; the narrowed arguments are re-verified against the exact payload sent upstream.
Deterministic by default
The verdict is policy evaluation plus deterministic detectors: regex, Luhn and range checks, keyword and path rules. An optional semantic detector is off until an operator enables it; when enabled it can only add a deny, never soften one, and a model error or timeout resolves to deny.
Unsupported is never silently weakened
Ask an enforcement point for an outcome it does not declare and the result is a deny flagged _DOWNGRADED. A shaping outcome that rewrites zero fields is not reported as shaped. The product surfaces the downgrade rather than claiming the outcome that was asked for.
DEPLOYMENT PATTERN
Your agents. Your systems. A decision in between.
GovernorAI evaluates the policy. The component in the action path carries out the decision. Two responsibilities, never one component doing both.
This is the inline pattern. An out-of-band event feed cannot prevent an action that has already happened, and a before-write control in a SaaS platform has a different boundary from a network proxy. The matrix below says which is which.
COVERAGE
Coverage you can read. Boundaries you can act on.
Choose the path, not the platform logo. Each registered enforcement point declares what it inspects and which outcomes it executes; the runtime consults that registry on every call, and the registry ships as a read-only API, gaps included.
| Enforcement point | Inspects | Allow | Deny | Approval | Redact | Mask | Constrain | Boundary |
|---|---|---|---|---|---|---|---|---|
| Before dispatchAn inline path can prevent the governed call from reaching its target. | ||||||||
Inline tool gatewaygateway_execute | tool call, MCP call, prompt, response, payload, retrieved content | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | Response shaping covers JSON, plain text and streaming SSE. Anything that can't be shaped safely is denied rather than forwarded. Constrain is request-side. |
Governed MCP invocationmcp_invocation | MCP call, tool call, retrieved content | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | Retrieval bodies declared as a fetch are inspected as untrusted content for indirect injection. Ordinary model answers are not inspected on this path. |
AWS Bedrock inboundprovider_bedrock | tool call, prompt, response | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | The Lambda proxy executes the tool after the verdict. Shaped arguments are verified against the exact payload sent. Streaming, SSE and binary responses are not shaped. |
Azure AI Foundry proxyprovider_azure | tool call, prompt | ✓ | ✓ | — | — | — | ✓ | Request narrowing is re-verified against the exact payload posted to Foundry; a constraint that can't be honoured denies. No response shaping. |
Vertex AI / Gemini proxyprovider_gcp | tool call, prompt | ✓ | ✓ | — | — | — | ✓ | Same boundary as Azure. This is the routed provider adapter, not a detect-only cloud connection. |
SDK consultsdk_wrapper | tool call, prompt | ✓ | ✓ | ✓ | — | — | — | Python, Go or JavaScript. Returns a verdict; on deny the wrapped function is never invoked. No shaped payload comes back, so shaping outcomes downgrade to deny. On Databricks this is the agent SDK, including MLflow and Unity Catalog function wrappers. |
Salesforce native action gatesaas/salesforce/check | action name and selected arguments | ✓ | ✓ | ✓ | — | — | — | Agentforce, Flow and Apex ask for the decision before the action runs and branch on it; Salesforce executes the authorized operation. The check itself never executes or forwards anything. |
Salesforce governed API routeproxy/salesforce | API request from an agent outside the org | ✓ | ✓ | — | — | — | — | GovernorAI checks the request and forwards it to Salesforce only on allow. A request that needs approval is not forwarded. MCP clients use the governed MCP invocation above. |
ServiceNow workflow checksaas/servicenow/check | flow step action and arguments | ✓ | ✓ | ✓ | — | — | — | A Flow Designer action asks before the consequential step. The flow continues on allow, waits on hold and does not run the step on deny; ServiceNow executes the step. |
Databricks Model Serving proxyproxy/databricks | model request to a serving endpoint | ✓ | ✓ | — | — | — | — | The request reaches the endpoint only on allow. No response shaping on this path. |
Databricks cluster egressgovernor-egress-agent | outbound connection: host and port | ✓ | ✓ | — | — | — | — | Pinned by cluster policy at cluster create. Each connection is checked before it opens; a deny refuses it. Host-level, not per call: per-call arguments use the agent SDK. |
| Before commitAn in-system control can abort a write before it commits. | ||||||||
ServiceNow before-write rulesaas_native | record insert and update on configured tables | ✓ | abort write | — | — | — | — | The scoped app's before rules on change_request, incident, sc_request and sc_task call setAbortAction(true); the record never commits. A backstop alongside the workflow check, enabled per table. No body rewriting. |
| After an observed eventA response can contain subsequent activity. Prevention of the original action is not claimed. | ||||||||
SaaS discovery and activitysaas_native | inventory and out-of-band activity from Salesforce, ServiceNow and Databricks; no body interception | — | contain | — | — | — | — | A deny here is a downstream control: a kill switch or a session revoke that stops later governed actions. It does not undo or prevent the action already observed. |
_DOWNGRADED, never a weaker result presented as success. Shaped arguments are re-verified against the exact bytes sent upstream, and a shaping that cannot be applied cleanly denies rather than forwarding a half-shaped request.WHERE IT INSERTS
Govern with no SDK in the agent.
Drop the decision into the gateway or proxy you already run. Each adapter parses the call off the wire, builds the canonical request, and asks one decision brain for the verdict: policy, data controls, injection deny, approvals, kill switch, evidence. Adapters never re-implement it.
The service mesh you already have
A gRPC external processor for Envoy Gateway, Istio, Gloo, Envoy AI Gateway and agentgateway. Allow continues, redact becomes a body mutation, approval returns 202, deny returns 403.
Transparent proxy in front of an MCP server
Point the client's server URL at the proxy. tools/call is governed; initialize, tools/list, ping and notifications pass through untouched.
An auth check your proxy already speaks
NGINX auth_request, Traefik ForwardAuth, AWS Lambda authorizer, Apigee, Azure API Management. Allow returns 200; approval and deny return 403.
Coexistence with an AI gateway
A Portkey bring-your-own-guardrail webhook and a LiteLLM custom guardrail govern the model call. Our endpoint answers with an explicit negative verdict rather than a 5xx, because those hosts treat a server error as pass.
# Envoy HTTP filter: stream the request to GovernorAI and honor the verdict # identity travels in governor.* headers: agent-id, org-id, mcp-id, 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 if the processor is unreachable
Also available: a Kubernetes sidecar that evaluates its mounted policy files on the host, and SDK consult paths for Python, Go and JavaScript. All integrations
FAILURE BEHAVIOUR
At the gateway adapters, fail closed, or it is not enforcement.
An enforcement point that lets calls through when it is confused is a logging product with extra latency. At the gateway adapters, every unresolvable situation resolves the same way: deny, with a reason, recorded, and distinguishable in logs from a policy deny. Embedded OPA, hybrid mode and some framework shims can fail open, so check the path you deploy. The gateway you insert at has to agree, which is why the Envoy filter ships with failure_mode_allow: false.
A transport error is not an answer. The adapter synthesizes the deny and marks it fail-closed.
An explicit timeout, five seconds by default and configurable per deployment. Expiry never resolves to allow.
The registry says this point can't execute what policy chose. Downgrading silently would be a lie, so it denies and flags the downgrade.
After a body is shaped it is re-scanned with the same detectors. If anything still fires, the body is not forwarded.
All eleven conditions that resolve to deny
| Condition | Why it denies |
|---|---|
| Gateway unreachable | A transport error is not an answer. The adapter synthesizes the deny and marks it fail-closed so it is distinguishable from a genuine policy deny. |
| Decision timeout | Five seconds by default, configurable per deployment. Expiry resolves to deny, never to allow. |
| Non-2xx response | The gateway returns 200 for every real verdict, including deny and approval. Any 4xx or 5xx is an error, and the body is not trusted to argue otherwise. |
| Unparseable response | If the verdict cannot be read it has not been received. |
| Unsupported outcome | The registry says this point cannot execute the outcome policy chose. The decision resolves to deny and is flagged as downgraded. |
| Shaping rewrote zero fields | A redaction that changed nothing is not a redaction. The applier returns the count of fields mutated so the gateway can refuse to label it as shaped. |
| Redaction fails re-scan | After a plain-text body is shaped it is re-scanned with the same detectors. If anything still fires, the body still leaks and is not forwarded. |
| Un-localizable sensitive content | Only detectors that can prove where a match sits contribute spans. A verdict with no offsets cannot drive a rewrite, so a shaping outcome resting solely on it denies. |
| Streaming window exceeded | The in-flight shaper keeps a bounded overlap so a token split across chunks is still seen whole. When a flush could emit the prefix of an unbounded secret, or an event exceeds the buffer cap, the stream terminates rather than emitting raw bytes. |
| Shaped payload cannot be verified | On the provider points the shaped or narrowed arguments are compared against the exact payload about to leave. A mismatch denies rather than forwarding a half-shaped request. |
| Inspection bounds exceeded | Arguments and payloads are walked against a depth and field budget. A structure that exceeds it has not been inspected, and uninspected is not allowed. |
DETECTORS
Seven deterministic detectors, plus one you can switch on.
Regular expressions, Luhn and range checks, keyword and path rules. Each declares its default response; a policy can gate on any of their signals. Two of them inspect retrieved content: the indirect-injection case where hostile text arrives in a document the agent fetched, after your prompt review has already passed.
| Detector | What it catches | Default response |
|---|---|---|
| secret | API keys, bearer tokens, JWTs and provider-specific key formats. | redact |
| sensitive_data | Regulated and confidential content, against your existing classification rule set rather than a forked one. | mask at high/critical · approval at medium |
| regulated_identifier | Payment cards confirmed with a Luhn check; US SSNs range-validated. | signal for policy |
| prompt_injection | Instruction-override attempts against the deterministic keyword floor. | deny |
| encoded_payload | Base64 and hex runs that decode to printable text. Surfaced for a policy to gate on; not auto-blocked, because base64 is a common legitimate transport. | signal for policy |
| risky_tool_intent | Tool calls whose shape carries consequence a human should see first. | approval |
| unsafe_destination | A destination argument pointing somewhere policy does not permit. | constrain · field dropped |
| semantic_injection | Paraphrased or obfuscated override the keyword floor misses. Model-assisted. Off until an operator enables it; rides an existing model client. | deny only · never softens |
CONTROLS
Controls that don't wait for the next call.
A per-call verdict is the core, not the whole surface. These operate on an agent, a tool or a namespace at once. Activating a stop does not undo transactions already completed.
Kill switch
Stop an agent, a tool or a namespace. One activation path: registry write, cross-pod propagation, domain event, audit row and webhook all happen together, so it can never be invisible.
Data controls
One classifier, not a parallel rule engine. What the data-controls surface says is sensitive is exactly what the enforcement point acts on.
Rate limits
A token-bucket budget per key, endpoint and role. In-memory for a single node, Redis-backed for a fleet, behind one interface.
Egress
A cluster-side agent governs each outbound CONNECT tunnel at host and port, asking the same gateway for a verdict. TLS is not terminated; the body stays encrypted end to end.
Outbound safety
Webhooks to tenant-supplied URLs are checked at dial time against the resolved IP, refusing loopback, private, link-local and metadata ranges. Every redirect hop is re-validated.
Provider-native
Where a platform ships its own guardrail plane, policy is compiled into it and, with a configured provider client, synced there, and any divergence from the source policy is named. Attaching that guardrail to the model call is planned. This complements the inline point; it doesn't replace it.
DETAILS
The details, when you need them.
Start with the business action. Then examine the policy, the protocol, the failure behaviour and the evidence your deployment will depend on. Developer documentation
Can our existing OPA service remain authoritative?
Yes. Remote mode calls your OPA service for the verdict; native rules and embedded Rego are also available, and engines can be mixed per policy. Your repository, reviewers and policy owners stay in place. Expect to map the action context (agent, tool, arguments, caller) into the input schema your policies read.
What does “require approval” mean at the boundary?
The governed call does not proceed: it is held, and an approval records a decision without releasing it. It is carried as require_approval in audit and evidence, delivered as pause at the SDK and HTTP boundary, and as a 202 on the Bedrock inbound path while the request waits.
How the hold is carried differs by enforcement point: the gateway and Bedrock inbound paths hold the request; on the SDK consult path the caller receives pause and implements the stop. A requirement can name a role rather than a person, so the hold is satisfied only by someone who holds that role.
What happens when a decision cannot be enforced?
It resolves to deny, with a reason, recorded, and marked so it is distinguishable in logs from a policy deny. The eleven conditions are listed above. Your gateway's own failure mode must agree: for Envoy that means failure_mode_allow: false, and the equivalent is documented for each path.
Which parts are deterministic, and which are not?
By default, all of it: policy evaluation plus deterministic detectors. The one optional model-assisted component is the semantic injection detector. It is off until an operator enables it; when enabled it can add a deny, never soften one, and a model error or timeout resolves to deny.
Are redact, mask and constrain supported everywhere?
No. Allow, deny and approval are decisions; redact, mask and constrain are payload changes that need a capable path. The matrix above says which points execute which. Request-side narrowing is not the same as rewriting a response, streaming inspection has a bounded window, and content already released cannot be withheld after the fact. Shaped arguments are re-verified against the exact payload sent upstream, and a shaping that changed nothing is not reported as shaped.
Can we stop an agent, not just one call?
Yes. The kill switch activates against an agent, a tool or a namespace through one service, so the registry write, propagation, domain event, audit row and webhook always happen together. It does not undo transactions already completed.
What performance figures are published?
Policy evaluation in process, in the sidecar topology, measured on a developer machine; the figures and the method are on the benchmark page. End-to-end sidecar percentiles and a run on the production instance type are not yet published, and a gateway, proxy or forward-auth hop adds its own cost on its own path.
How do the terms map to NIST SP 800-207?
An enforcement point is the mediated control between an agent's intent and the target system: the PDP/PEP pattern. GovernorAI is the policy decision point; the mediated integration is the policy enforcement point. Neither is both. The registry and API values call these seams.
Deny by default, least privilege at the point: nothing is permitted because it arrived from a trusted network, and an action no policy covers is denied rather than waved through. On the shared deployment a valid credential is required on every governed call and the tenant is taken from that credential; a header can confirm it, never choose it.
BEFORE ENFORCEMENT
Enforcement is the second decision. Not the first.
Everything on this page decides an action an agent is already taking. The first decision belongs to assurance: whether the agent should have reached production at all, scored on an immutable snapshot against acceptance bars registered before the run, and returned as a decision surface a deploy step can consume; shown today as a demo, not yet the automated stop in your pipeline.
The two are deliberately separate. An enforcement point that also graded the agent would be marking its own homework, and a verdict is only worth something if what was evaluated and what shipped are provably the same snapshot.
Start with one action
Start with one consequential action.
Bring an agent workflow. Together we map the enforcement point, the approval requirements and the evidence a scoped evaluation needs.