USE CASES / BY RISK · DATA LEAKAGE
In the prompt an agent sends. In the completion that comes back. In the arguments of the tool call the completion turns into. GovernorAI inspects all three at the enforcement points the integration supports, and shapes the payload where the enforcement point can genuinely execute a rewrite — redacting a secret, masking classified content, dropping an unsafe destination argument. Where an enforcement point cannot, the request fails closed to deny rather than being quietly weakened.
The shaper keeps a bounded sliding-window overlap and only emits bytes that are safely past the longest possible detector match — which is how a secret straddling a chunk boundary is still caught.
ONE CALL, FOUR POSITIONS
They are positions on the same call, and the same decision core evaluates each of them against the same policy. A customer identifier pasted into a prompt, an instruction planted in a retrieved document that comes back inside a completion, and a credential handed to a tool as an argument are one problem examined at three moments.
Before any content moves, the model itself is a registry row with a status — pending review, approved, restricted, deprecated or blocked — and a policy carrying allowed and blocked lists, a maximum risk tier, and a tier above which approval is required.
status · risk_tier · approved_by The prompt is a governed surface, not a log line. Policy is authored against an interaction whose arguments carry the messages and the model name; detectors run over the content and the tool arguments before anything leaves.
llm.chat.request The completion is inspected on the way back. Where it is the output of a governed retrieval call, an operator can declare it untrusted retrieved content and the indirect-injection detector reads it as a payload rather than as an answer.
llm.chat.response · retrieved_untrusted What the model said becomes a tool call, and that is the action boundary. Arguments can be narrowed, and the narrowed arguments are re-verified against the exact payload actually dispatched.
POST /api/v1/gateway/execute The inline sensitive-data detector reuses your existing data-classification rule set rather than forking one, so what the data-controls surface calls sensitive is exactly what the enforcement point acts on. Detection is deterministic — regex, Luhn and range checks, keyword and path rules — with no model in the decision loop. An optional semantic detector exists for paraphrased instruction-override, is off unless an operator enables it, can only add a deny to the strictest-outcome selection, and resolves its own error or timeout to deny.
WHAT FIRES, AND WHAT IT RESOLVES TO
A secret has a location, so it can be replaced. An instruction-override attempt does not have a safely removable location — editing it out leaves an attacker's remainder in place — so it is a deny-class signal rather than a shaping outcome. The table below is the whole detector set and what each one is permitted to do.
| 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 rather than a forked one. | MASK at high and critical severity · approval at medium · informational below that |
| regulated_identifier | Structurally validated identifiers the other two miss — payment-card numbers confirmed with a Luhn check, US social security numbers range-validated. | DENY · scan-only, no rewrite today |
| prompt_injection | Instruction-override attempts against the deterministic keyword floor. The same detector reads a body declared as retrieved content, which is where indirect injection is caught. | DENY · signal only, never rewritten |
| encoded_payload | Base64 and hex runs that decode to printable text — instructions smuggled past a keyword filter by encoding them. Base64 is also an ordinary transport, so this is deliberately low-confidence. | Surfaced as a detected type for policy to gate on, and recorded — it never tightens a decision on its own |
| unsafe_destination | A destination argument pointing somewhere policy does not permit. | CONSTRAIN — the offending argument key is dropped |
| risky_tool_intent | Tool calls whose shape carries consequence a human should see before it lands. | APPROVAL · signal only |
| semantic_injection | Paraphrased or obfuscated instruction-override the keyword floor misses. Off unless an operator enables it, and it rides an existing model client rather than new infrastructure. | DENY · can only add a deny, never soften one · model error or timeout resolves to deny |
prompt_injection, regulated_identifier and risky_tool_intent are scan-only: they produce no mutations, and the product refuses at write time to let an operator override one of them to a shaping decision, because a shaping rule that produces nothing would silently degrade to the base policy at runtime. Removing the phrase that tripped an injection detector would also leave the rest of an attacker-controlled payload in place and return a body the product had implicitly declared clean. Redaction of a validated card number or SSN is not shipped — that path denies rather than rewriting. Only detectors that can prove where a match sits contribute spans: a classifier returning a verdict with no offsets cannot drive a rewrite, so a shaping outcome resting solely on it denies instead. And a shaping that rewrote zero fields is never reported as shaped — the applier returns the count of fields actually mutated, and a redaction that changed nothing fails closed. encoded_payload is deliberately weaker still: base64-encoded text is a common legitimate transport, so it is recorded and exposed for an explicit policy to gate on rather than being allowed to block a call by itself.
TWO SIDES, DIFFERENT POWERS
On the way out, the payload has not left yet and the shaped version can be compared with the bytes actually dispatched. On the way back, the content is already in hand — and if it is streaming, part of it is already gone.
Prompts and tool arguments are inspected before dispatch. Argument narrowing reaches into JSON-encoded sub-fields of a tool call, and the narrowed arguments are re-verified against the exact outbound payload — a constraint that cannot be honored denies rather than forwarding an unconstrained request.
Response bodies are shaped only on the enforcement points that can genuinely do it. 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. Binary or non-text content, and JSON that cannot be rewritten without corrupting it, fail closed rather than being forwarded un-inspected.
| Enforcement point | Request side | Response side | Stated limit |
|---|---|---|---|
gateway_execute | Redact, mask, constrain | Redact and mask — JSON, plain text and SSE shaped in flight | Constrain is request-side only. A response that cannot be shaped safely fails closed to deny rather than being forwarded un-inspected. |
mcp_invocation | Redact, mask, constrain — argument-aware | Retrieval output inspected as untrusted retrieved content | Ordinary model-answer responses are not classified on this enforcement point. |
provider_bedrock | Redact, mask, constrain — verified against the exact payload sent onward | Redact and mask on the response text, with a re-scan that proves the content is gone | Streaming, SSE and binary Bedrock responses are not shaped. Content a detector cannot localize fails closed rather than being partially redacted. |
provider_azure | Constrain, re-verified against the exact request | Not offered | Response shaping is not available on this enforcement point. A constraint that cannot be honored fails closed to deny. |
provider_gcp | Constrain, re-verified against the exact request | Not offered | Response shaping is not available on this enforcement point. |
sdk_wrapper | Consult only — allow, deny, approval | Not offered | The SDK path receives a decision, not a shaped payload; choosing a shaping outcome here downgrades to deny. |
saas_native | Not offered | Not offered | In-SaaS event surfaces are out-of-band. Nothing mediates the request body, so no inline rewriting is claimed — allow and deny only. |
Response shaping is real on gateway_execute, on mcp_invocation for declared retrieval bodies, and on provider_bedrock. It is not offered on provider_azure or provider_gcp: those enforcement points constrain request arguments and nothing more. Ask an enforcement point for an outcome it does not declare and the result is not a silent degradation to something weaker — it is a deny, marked as a downgrade with an explain code suffixed _DOWNGRADED, with the original request never dispatched. Forward-auth adapters cannot rewrite a body at all; that pattern emits an X-Governor-Shaping-Required header so an operator knows a redaction was requested and did not happen. An enforcement point that is not in the registry advertises no shaping whatsoever.
The full capability matrix, including the outcomes each enforcement point does not have: Runtime Enforcement.
THE CONTROL THAT CANNOT BE UNDONE
A streaming body cannot be buffered without defeating the point of streaming, so the shaper consumes it incrementally and emits shaped bytes without ever materializing the whole response. A sensitive token can be split across two chunks, so the shaper keeps a bounded sliding-window overlap and only emits bytes that are safely past the longest possible detector match — a span straddling a boundary is still seen whole and redacted before its tail goes out.
Chunks 01 to 03 are gone. The shaper cannot recall them, and the product does not pretend otherwise. What it can do is refuse to forward another byte: on a deny-class signal it terminates and withholds the remainder rather than letting the rest of an attacker-controlled body through.
Bytes already delivered to the client are gone. The sliding window is sized by the bounded detectors' longest match, but several secret patterns are not length-bounded — a JWT, an sk- key, a bearer token. The shaper therefore never flushes a window prefix while a potential unbounded secret could still be growing across the cut, and when a forced flush would emit such a prefix, or a single event's buffered data exceeds the safe buffer cap, it terminates with a deny instead of emitting raw or prefix bytes. This is a bounded window, honestly stated: it is not unbounded in-flight redaction. For the same reason, blocking on streaming traffic has to be enforced on the input — LiteLLM's post-call streaming hook is audit-only, and the deployment guide says so plainly rather than implying the output hook can stop anything.
CONTENT THAT ARRIVES CARRYING INSTRUCTIONS
The modern leak is rarely a person pasting a secret into a chatbot. It is a document, a ticket comment or a web page that an agent retrieved, containing text addressed to the model rather than to the reader — and the exfiltration happens in the tool call the model makes next.
retrieved_untrusted Declared, never guessed A response is treated as untrusted retrieved content only when an operator configures it or a caller explicitly declares it. It is never inferred from a tool name, because a tool called search is not evidence of anything.
retrieved_content Read as a payload Once declared, the body is tagged as retrieved content rather than as a model answer, and the prompt-injection detector — which self-skips ordinary responses — inspects it. That is where indirect injection is caught.
unsafe_destination The exfiltration argument is dropped Where the follow-on tool call names a destination policy does not permit, the offending argument key is constrained out rather than the whole call being refused.
re-verified Against the exact outbound payload A narrowed argument is compared with the bytes actually about to leave. A mismatch denies rather than forwarding a half-shaped request — a shaping that cannot be applied cleanly is not applied at all.
Every one of these decisions carries an explain code and a reason, and lands in the hash-chained audit ledger alongside the action context that produced it — including the allows. So a data-protection review can be answered with the record of what was inspected and what was shaped, rather than an assertion that nothing went wrong.
These are data controls and injection defenses at an enforcement point, not a guarantee. They do not prevent every encoded, indirect or novel attack, and nothing here is a claim about the quality or truthfulness of what a model produces. GovernorAI operates on the body it already receives at an enforcement point: it does not inspect packets, does not analyze raw TCP or TLS traffic, and the egress agent deliberately does not terminate TLS — it governs a tunnel at the host and port level, one decision per tunnel open, not one per logical call inside it. Where you run a network or traffic-level data-protection product, this sits alongside it and answers a different question.