USE CASES / BY RISK · DESTRUCTIVE ACTIONS
The moment that matters is not the completion — it is the tool call the completion turns into, made by a non-human principal, with arguments a model wrote, against a system of record. GovernorAI puts a decision at that enforcement point: deterministic, with no model in the decision loop, executing only the outcomes the enforcement point can genuinely carry out, and failing closed to deny on anything it cannot resolve.
A wrong answer is a ticket. A wrong action is a record. The line that matters here is llm_invoked: false — no model was asked whether this should happen, so the decision is reproducible rather than persuasive.
WHAT "DESTRUCTIVE" ACTUALLY MEANS
An agent with a tool is not a chatbot with extra features. It holds a credential, it runs unattended, and the argument it fills in was written by a model. These are the calls where a policy document and a log after the fact stop being enough.
A clinical record changes. The consequence is not a bad answer a clinician can discount — it is a value in a chart that downstream care, billing and audit will all treat as true. The enforcement point sees the tool, the arguments and the principal before the write happens, and can hold it for a person.
tool · args · principal · policy · verdict A refund, a payment, a limit increase. Amount is an argument, and an argument is exactly what a policy can read: a CEL expression on the tool name and the amount is enough to route a high-value call into approval rather than allowing it. The narrowed or held call is re-verified against the exact payload before dispatch.
action.tool == "refund_customer" && action.args.amount > 5000 A delete against an ITSM table, a configuration push, a destructive migration. Native rules carry allowed and denied tool lists and a step ceiling, so a runaway loop hits a bound rather than continuing until someone notices.
denied_tools: itsm.delete_* · max_steps: 40 This is not an agent builder and not a replacement for your runtime. The decision sits at the action boundary where an existing agent's call is dispatched — the gateway you already run, an MCP proxy, a provider adapter, or an SDK consult — and it does not require an SDK inside the agent to work.
SIX OUTCOMES, TWO POWERS
Three outcomes settle whether the action happens. Three change its payload. The distinction is load-bearing, because an enforcement point that can decide is not automatically an enforcement point that can rewrite — and the product is not allowed to blur the two.
allow Policy resolved and the call is dispatched as written — and the decision is still recorded. An allow is evidence, not an absence of governance. deny The target never sees the call. On the SDK path the wrapped function is never invoked and the caller gets the policy reason rather than a result. approval Held for a human decision. Carried internally as require_approval in audit and evidence, and delivered as pause at the SDK and HTTP boundary; on the Bedrock inbound path the proxy returns a 202 while the request waits. redact The value is replaced with a non-recoverable token, driven by the secret detector. Applied to request arguments and, on the enforcement points that support it, to response bodies. mask The value is replaced with a deterministic mask, driven by the sensitive-data classifier at high and critical severity. constrain The offending argument key is dropped. Request side only. Argument narrowing reaches into JSON-encoded sub-fields of a tool call, and the narrowed arguments are re-verified against the exact payload actually sent upstream. The enforcement point capability registry is a runtime contract, not a marketing table. Every registered enforcement point declares the interaction kinds it can inspect and the outcomes it can truthfully carry out; the inspector consults that declaration before applying a richer outcome. Where a policy resolves to something the enforcement point cannot execute, the decision is not quietly weakened — it is refused.
Ask an enforcement point for an outcome it does not declare and the answer is a deny, flagged as downgraded, with an explain code suffixed _DOWNGRADED and the original requested decision retained in the decision detail — never a silent degradation to something weaker. saas_native carries allow and deny only, because in-SaaS event surfaces are out-of-band and nothing mediates the request body there; a deny on that enforcement point is a downstream control action such as a kill switch or a session revoke, not a request the enforcement point edited on the way through. sdk_wrapper adds approval but shapes no payload, because the consult path returns a verdict rather than a rewritten body. provider_azure and provider_gcp constrain request arguments but are not offered response shaping. An enforcement point that is not in the registry at all falls back to allow, deny and approval, and advertises no shaping whatsoever — adding an outcome to the matrix requires shipping the runtime that executes it first.
The full matrix, including the capabilities each enforcement point does not have: Runtime Enforcement.
WHEN THE ACTION EXCEEDS THE AGENT'S AUTHORITY
A refund above a threshold is not a policy violation — it is a decision above the agent's pay grade. Approval is a first-class outcome for exactly that case, and the record shows who decided, not just that something was held.
An approval request carries the action, the session, the agent, the tool, a hash of the arguments and a readable summary of them, the rule that matched, and — once decided — who decided and when. A policy can route on the arguments themselves, so the threshold that triggers a human is written where the rest of the rule lives.
args_hash · rule_id · decided_byTool calls whose shape carries consequence a human should see before it lands resolve to approval rather than deny. It is a scan-only signal: it cannot be overridden into a shaping outcome, because a shaping rule that produces no mutations would silently degrade to the base policy at runtime.
approval · signal onlyPolicy change management is separate from action approval and carries its own rule: a policy cannot be promoted past a stage it has not cleared, and the approval is attributable to a named person.
see Policy & GovernanceWHEN WAITING FOR THE NEXT CALL IS TOO SLOW
Activation runs through one service so it can never be invisible: the registry write, the cross-pod propagation, the domain event, the audit-timeline row and the webhook dispatch all happen together.
agentOne agentEvery governed call that agent attempts, across every enforcement point it reaches.
toolOne toolA single tool, whichever agent invokes it — the right shape when the problem is the target, not the caller.
sessionOne sessionA single run in flight, without stopping the agent's other work.
namespaceOne namespaceEverything in a namespace at once — the blast radius an environment boundary already defines.
Four scopes, which is what KillScope declares — a switch created global by a platform admin applies across tenants, but that is a flag rather than a fifth scope. Kill switches can carry a time to live and be revoked; activation and deactivation are both audited events.
THE CONTRACT
An enforcement point that lets calls through when it is confused is a logging product with extra latency. Every path resolves an unresolvable situation the same way: deny, with a reason, recorded — and the synthesized deny is marked so it is distinguishable in the record from a genuine policy deny.
| Condition | Resolution | Why |
|---|---|---|
| Transport error | DENY | The gateway is unreachable. A transport error is not an answer, and the adapter synthesizes the deny rather than guessing. |
| Decision timeout | DENY | The decision client carries an explicit timeout — five seconds by default, configurable per deployment. Expiry resolves to deny, never to allow. |
| Non-2xx response | DENY | The gateway returns 200 for every real verdict, including deny and approval. Any 4xx or 5xx is an error condition, and the body is not trusted to argue otherwise. |
| Unparseable response | DENY | If the verdict cannot be read, it has not been received. |
| Unsupported outcome for the enforcement point | DENY | The registry says this enforcement point cannot execute the outcome policy chose. Downgrading to something weaker would be a silent lie, so it denies and is flagged as downgraded. |
| Shaping rewrote zero fields | DENY | A redaction that changed nothing is not a redaction. The applier returns the count of fields actually mutated so the gateway can refuse to label it as shaped. |
| Shaped payload cannot be verified | DENY | On the provider enforcement 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 | DENY | The inspector walks arguments and payloads against a depth and field budget. A structure that exceeds it has not been inspected, and uninspected is not allowed. |
The verdict comes from policy evaluation and deterministic detectors — regex, Luhn and range checks, keyword and path rules. The decision record carries a field stating whether an LLM was invoked at all, so the claim is checkable rather than asserted.
An optional model-backed detector for paraphrased instruction-override exists. It is off unless an operator enables it, it can only add a deny to the strictest-outcome selection, and its own model error or timeout resolves to deny.
Envoy's failure_mode_allow must be false. Third-party hosts have their own defaults — Portkey's guardrail webhook fails open on timeout — so GovernorAI's endpoint answers with an explicit negative verdict rather than a 5xx, and the failure action on the host side is yours to set and verify per deployment.
Nothing is permitted because it arrived from a trusted network, an identity is required on every governed call, and the execution-posture surface reports the credential mode as what it is rather than dressing it up.
THE RECORD
Every verdict lands in a hash-chained audit ledger alongside the action context that produced it. Each entry carries a sequence number and the SHA-256 hash of the entry before it; verification walks the chain from an empty genesis hash and stops at the first row it cannot reconcile, naming that row.
// one governed tool call, as it lands in the ledger
{
"tool_name": "erp.process_payment",
"tool_args_hash": "sha256:…", // arguments hashed, not stored raw
"session_id": "…",
"trace_id": "…",
"decision": "pause", // require_approval in audit and evidence
"reason": "amount above agent authority",
"policy_id": "refund-approval-v4",
"rule_id": "…",
"explain_code": "…",
"llm_invoked": false, // no model in the decision loop
"latency_ms": …
}The decision, its rule, its explain code and its action context are one record rather than three systems correlated after the fact. Evidence is mapped to named controls, with the coverage of every control stated rather than assumed — mapping evidence to controls is not certification, and the product is built to say so.
GovernorAI operates on the call it already receives at an enforcement point. It does not inspect packets and does not analyze raw TCP or TLS traffic; the egress agent deliberately does not terminate TLS and records one decision per tunnel open rather than one per logical call inside that tunnel. The controls here reduce risk at the action boundary — they do not prevent every encoded, indirect or novel attack, and nothing on this page is a claim about the quality of what a model produces. Signed Ed25519 and Merkle evidence bundles are available per deployment and are not on by default. Where a customer runs a network or endpoint security product, this sits alongside it and answers a different question: whether this agent may make this call, with these arguments, under this policy.