USE CASES / SECURITY & AI SECURITY
You already own the identity, the network and the endpoint. What you do not own yet is the moment an agent decides to call erp.process_payment — because that call is made by a non-human principal, with arguments a model wrote, against a system of record. GovernorAI puts a policy decision point at that boundary: a per-call verdict, deterministic, recorded, and fail-closed when it cannot resolve.
Every governed action takes the same five steps in the same order, and nothing in that path consults a model. The verdict is recorded whichever way it goes — an allow is evidence too.
WHAT YOUR JOB ACTUALLY IS HERE
Agent governance is usually sold as a compliance story. For a security team it is a much narrower problem: an unattended principal, holding real credentials, taking irreversible actions on instructions that partly came from text somebody else wrote.
I cannot tell you who authorised that call.
The agent authenticated as a service account and did fourteen things. Your access logs record that the service account acted; nothing records that this action, with these arguments, was permitted under a policy someone approved.
The instruction came from a ticket, not a person.
The prompt was clean. The retrieved document was not. Indirect injection is the case your prompt-level review never sees, because the hostile text arrives after the request has already been approved.
If this goes wrong at 2am, what do I pull?
Revoking a key stops everything the key touches, including the things that were fine. You want to stop one agent, one tool, or one session — now, everywhere, with the stop itself recorded.
Your SSE, CASB and endpoint tooling decide whether a destination may be reached and whether a payload may leave. GovernorAI decides whether a specific tool invocation may execute, against the policy attached to that agent, and leaves a record of the verdict. The two sit alongside each other — GovernorAI's discovery even reads the logs your egress vendors already produce rather than deploying a sensor of its own.
ONE GOVERNED ACTION
Nothing here is inference. The verdict comes from policy evaluation and deterministic detectors — regular expressions, Luhn and range checks, keyword and path rules — so the same call with the same arguments under the same policy resolves the same way twice.
Nothing is permitted because it arrived from a trusted network. The governed call carries an agent identity, an organisation and a namespace before it is evaluated at all.
governor.* Native rules, CEL or Rego — or your own OPA server, in remote mode, so the policy never leaves your repository. The verdict carries a matched rule id, an explain code and a reason.
allow · deny · require_approval Argument-aware inspection reaches into JSON-encoded sub-fields of a tool call. Where an enforcement point supports it, response bodies are inspected too — including plain text and streaming, in flight.
request · response Each enforcement point declares the outcomes it can truthfully carry out. Ask for one it does not declare and the result is a deny marked as a downgrade — never a silent fallback to something weaker.
_DOWNGRADED Allow, deny and approval all land in the hash-chained audit ledger with the action context that produced them. An allow is evidence, not an absence of governance.
policy.decision Fail closed Gateway unreachable, decision timeout, a non-2xx answer, an unparseable answer, an outcome the enforcement point cannot execute, a redaction that rewrote zero fields, a rewritten body that still trips the detectors on re-scan, a structure past the inspection depth budget — every one of them resolves to deny, with a reason, recorded, and distinguishable in logs from a genuine policy deny.
Six outcomes exist: allow, deny and require-approval decide the action; redact, mask and constrain change its payload. Which of the six a given enforcement point can actually execute is a published capability registry the runtime consults on every call, not a marketing table. An enforcement point that lets calls through when it is confused is a logging product with extra latency, so nothing here degrades to allow.
The decision timeout is explicit — five seconds by default, configurable per deployment — and its expiry resolves to deny, never to allow. Full mechanics on Runtime Enforcement.
PROMPT AND INDIRECT INJECTION
Direct prompt injection is the easy half. The harder half is indirect: a retrieved document, a ticket body, a web page or an MCP tool result that carries instructions the agent then follows. Both are handled the same way — as untrusted content inspected at the action boundary, where the consequence would land.
On the central gateway path, and on MCP invocations an operator declared as a fetch, the retrieval body is inspected as untrusted retrieved content rather than trusted context. That is the enforcement point where indirect injection is actually visible.
gateway_execute · mcp_invocationInstruction-override attempts are matched against a deterministic floor, and base64 or hex runs that decode to printable text are caught separately — the standard technique for smuggling an instruction past a keyword filter. Tuned to avoid firing on ordinary hashes, identifiers and binary blobs.
reproducible, no model callA semantic detector for paraphrased or obfuscated override exists. It is disabled by default, it can only add a deny to the strictest-outcome selection and never soften one, and a model error or timeout inside it resolves to deny.
cannot weaken a verdictAn injection only matters if it reaches an action. Policy binds allowed and denied tools per agent, high-consequence calls escalate to a human, and a destination argument pointing somewhere policy does not permit has that field dropped before dispatch.
allowed_tools · require_approvalInjection defence here is deterministic detection plus policy at the action boundary. It does not prevent every encoded, indirect or novel attack, and a technique nobody has written a rule for will pass the detectors. What it changes is the blast radius: the instruction may survive, but the call it asks for still has to clear policy for that agent, on an enforcement point that will fail closed rather than guess.
This is also not network inspection. GovernorAI operates on the body it already receives at an enforcement point. It does not inspect packets, does not analyse raw TCP or TLS, and the egress agent deliberately does not terminate TLS — it records one decision per tunnel open, not one per logical call inside that tunnel. Where you run a network or traffic-level security product, this sits alongside it.
DATA CONTROLS
Redact, mask and constrain are the outcomes that rewrite. They are driven by the same classification rule set the data-controls surface shows you — not a forked, parallel rule engine that can quietly disagree with it.
| Detector | What it catches | Resolves to |
|---|---|---|
| secret | Credential material — API keys, bearer tokens, JWTs and provider-specific key formats. | REDACT — replaced with a non-recoverable token |
| sensitive_data | Regulated and confidential content, using the existing data-classification rule set. | MASK at high and critical severity — a deterministic mask; otherwise approval |
| regulated_identifier | Structurally validated identifiers the other two miss — payment-card numbers confirmed with a Luhn check, US social security numbers range-validated. | DENY · signal only, no rewrite |
| unsafe_destination | A destination argument pointing somewhere policy does not permit. | CONSTRAIN — the offending argument key is dropped, request side only |
A rewrite has to prove it worked. A shaping that mutated zero fields is never reported as shaped — it denies. A shaped plain-text body is re-scanned with the same detectors, and if anything still fires the body is not forwarded. On the provider enforcement points the narrowed arguments are compared against the exact payload about to leave, and a mismatch denies rather than sending a half-shaped request.
WHY YOU HAVE TO READ THE MATRIX
Not every enforcement point can rewrite. The product prints the gaps.Six outcomes across seven registered enforcement points, with the capabilities an enforcement point does not have shown as crosses rather than omitted. This is the table to take into an architecture review: it tells you, per integration point, whether "redact the card number" is a control you actually have there or a control that will resolve to deny.
A cross in that matrix is a capability the enforcement point does not have. In-SaaS native event surfaces are out-of-band, so nothing there rewrites a request body — a deny on that enforcement point is a downstream control action such as a kill switch or a session revoke. The out-of-process SDK consult path returns a verdict rather than a rewritten payload, so shaping outcomes are not advertised to it at all.
In-flight redaction of a streaming body keeps a bounded overlap so a token split across chunks is still seen whole. It is not unbounded in-flight redaction: when a flush could emit the prefix of an unbounded secret, or an event exceeds the safe buffer cap, the stream terminates rather than emitting raw bytes.
CONTAINMENT
Revoking a credential is a blunt instrument that also stops the work that was fine. A kill switch is activated against a target, and every activation runs through a single service so the record of it is not optional.
agentone governed agenttoolone tool, everywheresessionone live sessionnamespacean environmentFour scopes, which is what KillScope declares. A switch may also be created global by a platform admin, applying across tenants — that is a flag on the switch, not a fifth scope, and not something a tenant sets for its own estate.
The registry write, the cross-pod propagation, the domain event, the audit-timeline row and the webhook dispatch all happen in one service. There is no code path where an agent is stopped and nobody can prove when, or by whom.
no silent activationRules on deny rate, error rate, p95 and p99 latency, request count and queue depth — scoped globally or to a namespace, agent or policy — with actions that include opening an incident, pausing a policy, or engaging a kill switch.
observation feeds enforcementA cluster-side agent governs each outbound CONNECT tunnel at host and port level by asking the same gateway for a verdict, then opens raw TCP forwarding on allow. TLS is not terminated; the body stays encrypted end to end.
one decision per tunnel openRequests to tenant-supplied URLs are checked at dial time against the actual resolved IP, refusing loopback, private, link-local and cloud-metadata ranges, with every redirect hop re-validated. A hostname cannot pass validation and then re-resolve inward.
DNS rebinding closedToken-bucket limiting, in-memory for a single node and Redis-backed for a fleet, behind one interface — so the behaviour does not change when the deployment shape does.
same semantics either wayA read-only execution-posture surface derives, from real decision records, what was authenticated, which tenant the action was bound to and what policy decided. It reports the credential mode as scoped_api_key rather than dressing it up, and reports just-in-time authorization and brokered credentials as roadmap — never live.
HOW THIS STARTS
No security team enters a new control plane by putting it in the request path. Discovery is a consumer of feeds you already produce: your SIEM, your secure-egress and endpoint vendors, your identity provider, your cloud AI control planes. It is not in the path of any call, and it changes nothing about how your agents run.
not_assessed, which is never a pass. Step three · at the action boundary Runtime Enforcement Where the per-call verdict is applied, which enforcement points execute which outcomes, and the full table of conditions that resolve to deny. This is the page to read before an architecture review. After the fact Decision Observability The investigation surface: what the agent attempted, which policy version decided it, who approved, what alert it tripped and what incident followed. The unit is the verdict, not the response. There is no tap, no proxy and no packet inspection anywhere in discovery: every source is a log, an audit record or a control-plane list call that a system you already run hands over. Its blind spots are therefore ours. An agent calling a model over a path no connected source records is invisible, and connecting no sources discovers nothing. A finding is a worklist item — the discovery path itself never blocks, disables or reconfigures anything.