We use optional cookies to understand website visits and identify visiting businesses. You can change your choice anytime using Cookie preferences.
Apollo records page visits and sets a first-party cookie to identify visiting companies globally. If person-level tracking is enabled in Apollo, it may also identify visitors from the U.S. Read Apollo's privacy policy.
Your browser's Global Privacy Control signal is enabled, so Apollo tracking is off.
Use cases / Destructive actions
An agent that can reach a tool is not authorized for every use of it. GovernorAI decides each consequential call at the action boundary: routine work is allowed, changes above the agent’s authority are held for a named approver, and prohibited actions are blocked before dispatch. By policy, with no model deciding, and recorded as it happens.
The agent has access to the tool. Your policy prohibits deleting production customer records.
An approval cannot override this policy block.
Decision summary. The policy verdict, the request fingerprint, the human response and the dispatch state are separate fields, so none of them can stand in for another.
{
"decision_id": "demo-dec-2403-r1",
"request_id": "demo-req-2403",
"request_revision": 1,
"agent": "ops-agent",
"tool": "records.delete",
"enforcement_point": "inline_tool_gateway",
"policy": {
"id": "production-protection",
"rule_id": "protect-production-customer-records"
},
"initial_policy_decision": "deny",
"explain_code": "PROTECTED_RECORDS_DELETE",
"llm_invoked": false,
"human_response": {
"status": "not_eligible",
"reviewer": null
},
"dispatch_policy_decision": null,
"execution": {
"status": "not_dispatched",
"target_confirmation": null
},
"events": [
{
"event": "policy.evaluated",
"detail": "deny",
"request_revision": 1
}
],
"argument_fingerprint": {
"algorithm": "SHA-256",
"value": "f4c34f372921b882e34180e56643c8e9899253453544874b439367055b0e4666",
"scope": "sorted-key arguments"
}
}The control that matters
Your identity stack settles whether this agent may reach the tool. GovernorAI settles the question that comes next: is this particular action, with these arguments, something the agent may do on its own.
The verdict comes from your policy and deterministic checks on the tool, target and arguments. The optional semantic detector can only add a deny, never turn a block into permission, and every record states whether one was consulted.
Routine work proceeds. A consequential change is held for a named approver with the request and the policy reason attached. The approval is recorded and does not release the change; a changed request is held again.
The request, the policy that matched, the verdict and who approved land in one record as the decision is made. Security and compliance start an investigation from the decision, not from three systems correlated afterwards.
In the product
Recorded on a demo tenant: governed actions decided at the action boundary, a destructive tool call held with its reason, what each enforcement point can execute, and the record a deny leaves.
Real product screens from a demo tenant with seeded activity: the outcome, the rule and the reason for each governed action.
Real consequences. Explicit authority.
Money moved. Records changed. Production modified. Put the policy decision before the consequential action.
Give an operations agent useful access without giving it unrestricted authority to delete records or change production configuration.
Keep routine refunds moving. Route higher-value requests to Finance and stop destinations your policy does not permit.
Support clinical workflows without treating a model-generated change as an authorized update to a patient record.
Two questions. Both matter.
A request can look harmless and still exceed an agent’s authority. Detection scores a call; authorization decides it. Keep your security signals, and make policy the permission check.
Inspect content and behavior for signs of injection, misuse or exfiltration. Those signals inform protection and response.
Evaluate the exact action against business rules. A legitimate request may still require a Change Manager’s approval.
| The question | Threat detection answers | Action authorization · GovernorAI |
|---|---|---|
| What produces the verdict | A model’s confidence that the call looks malicious. | Your policy, evaluated deterministically. No model is asked, and the record says so. |
| What it reads | Prompts, content and behavior patterns. | The exact action: tool, arguments, principal and session. A rule reads amount > 5000. |
| When the control itself fails | Configured per host; a timeout often passes the call. | Deny, with a reason, recorded, at the Envoy ext_proc, MCP proxy and forward-auth adapters. |
| What the decision costs | A model inference per call. | A deterministic policy evaluation, in process. What you measure in a deployment is the hop, not the decision. |
| Above the agent’s authority | Alert, or block. | Held for a named approver, whose decision is recorded. |
| Afterwards | Alerts in a SIEM, correlated later. | One record per gateway decision, allow included, written as it is made. |
Both jobs matter. Only one of them is a permission check. Benchmark scope and method
Try the approval pathIndependent execution governance
Keep your agents, frameworks and business systems. GovernorAI inserts at the gateway or proxy you already run, a transparent MCP proxy, a provider adapter, a Kubernetes sidecar, or an SDK consult if you want one. Policy stays where you keep it: native rules, Rego, or your existing OPA.
The requested tool, arguments and caller identify the action—not just the connection.
GovernorAI evaluates the request independently of the agent: deterministic policy, no model deciding. The evaluation itself runs in process (benchmark method), so what you measure in a deployment is the hop around it, not the decision.
Dispatch permitted work, hold for review, or block the call before it reaches the target. The decision is recorded here; the target’s response is correlated as its own evidence.
Control you can explain
When someone asks why an agent was allowed to act—or why it was stopped—start with the decision, not a reconstruction from scattered logs.
Explore evidence & complianceConnect the attempted action to the policy and rule that allowed, blocked or escalated it.
Keep the original policy verdict, human response and execution evidence distinct. An approval is a recorded decision, not a release and not proof of a completed change.
Gateway decisions, allows included, are recorded as they are made, carrying the policy, the rule, the explain code and whether a model was consulted. Control-plane audit entries are hash-chained, and verification names the first entry it cannot reconcile.
An enforcement point that lets calls through when it is confused is a logging product with extra latency. At the gateway adapters, every unresolved condition resolves to deny, with a reason, recorded, and marked so it is never mistaken for a policy deny.
All eleven conditions, as published in the enforcement contract. Read the contract →
Block subsequent governed calls at the scope that matches the problem: an agent, a tool or a namespace. Keep unrelated work moving.
Before you start
Bring your existing workflow. We will work through the control with you.
No. No SDK is required in the agent. GovernorAI inserts at the gateway or proxy you already run (Envoy, Istio, NGINX, Traefik), a transparent MCP proxy, a provider adapter, a Kubernetes sidecar, or an SDK consult if you prefer one. Your runtime and your policy ownership (native rules, Rego, or your existing OPA) stay where they are. See the architecture.
The call is denied, with a reason, and the deny is recorded and marked as synthesized so it is never mistaken for a policy deny. The same holds for timeouts, unreadable verdicts and outcomes an enforcement point cannot execute. Your gateway’s own failure mode has to agree: the Envoy filter ships with fail-open off.
No. Policy decides. The only model-backed component is an optional semantic detector that is off until you turn it on, can only add a deny, and resolves to deny on its own timeout. Every decision record states whether a model was invoked. Read the trust principles.
No. Approval handles an action that policy allows subject to authorized review. A prohibited action remains denied. Approving a held request records the decision; it does not release or dispatch the call.
No. Those controls remain part of the system. GovernorAI adds independently managed action policies, authorized review, containment, and evidence around consequential workflows.
Yes. An allow is a decision like any other and is recorded with the policy and rule that resolved it. An allow is evidence, not an absence of governance.
This use case is about intervening before a governed action executes. An inline path can block dispatch; a supported before-commit path can abort a write. After-event controls contain later activity—they do not undo a completed change.
Start with the action that matters
Bring one consequential workflow to a 30-minute briefing. Map the business rule, the authorized reviewer and the evidence for a scoped six-week evaluation.