USE CASES / MODEL CONTEXT PROTOCOL
Govern tools/call. Leave the rest of the protocol alone.
GovernorAI ships a transparent reverse proxy that speaks MCP Streamable-HTTP and sits in front of a real MCP server. One method is governed — the one that makes something happen — and every other message is forwarded untouched. Point your client's server URL at the proxy and nothing in the agent changes.
One method is governed — the one that makes something happen. initialize, tools/list and ping are forwarded untouched, so the proxy is transparent for everything that is not a tool call.
TRANSPARENT PROXY · governor-mcp-proxy
One call in. Four things that can come back out.
The proxy never re-implements policy, data controls, approvals or the kill switch. It translates the MCP tool call into the canonical gateway request, asks for a verdict, and enforces the answer on the wire. There is one decision brain and this is a protocol translator in front of it.
{ "jsonrpc": "2.0", "id": 7, "method": "tools/call",
"params": { "name": "refund_customer",
"arguments": { "account": "…", "amount": 8200 } } }allow Forwarded verbatim The original request reaches the upstream MCP server unchanged. The proxy adds nothing to the payload.
→ upstream, byte for byteallow + shaped Arguments rewritten params.arguments is replaced with the shaped arguments, then the rewritten request is forwarded.
pause Held for a human A JSON-RPC error carrying the approval id and URL. The call is never forwarded while it waits.
← error −32001deny Held, and recorded Policy deny, kill switch, or a fail-closed denial. Never forwarded; the decision still produces evidence.
← error −32002Everything else passes through. initialize, tools/list, ping, notifications, resources and prompts are forwarded untouched, and the Streamable-HTTP session headers are preserved in both directions so the transport handshake keeps working. Fail-closed is the contract: an unparseable body, a tools/call with no tool name, an oversized payload or any decision error resolves to a denial — the upstream server is reached only for calls the gateway explicitly allowed.
The simplest insertion: the proxy is the URL the MCP client is configured with, and the real server sits behind it.
The proxy is chainable inside Docker MCP Gateway or ContextForge, so an existing MCP gateway keeps its role and gains a decision point.
The same decision is available as an Envoy external processor and as an HTTP forward-auth check for teams whose traffic already goes through one.
The proxy implements the argument-rewrite path, but end-to-end redaction also depends on the gateway materializing shaped arguments back to the caller, which it does for the Bedrock enforcement point today; generalizing that gate is tracked work. Until it lands, treat the MCP proxy as enforcing allow, deny and approval end to end, with argument rewriting flowing once the gate is generalized. Separately: a proxy in front of a server governs the calls that go through it — it is not a claim that every MCP server in your estate is routed through one.
SEAM · mcp_invocation
An MCP call is a first-class decision target, not a prompt with extra steps.
Most AI controls are built to read text. An MCP tool call is often the least textual thing in the trace and the most consequential — a tool name and a structured argument object. GovernorAI registers mcp_invocation as its own enforcement point, and argument-aware inspection runs on it even where the same call would be a no-op for prompt or response classification.
| Declared | What the enforcement point carries |
|---|---|
| Interaction kinds | MCP calls and tool calls. Plus retrieved content: when an operator declares — or a caller hints — that an MCP call is a retrieval fetch, the returned body is treated as untrusted retrieved content and inspected for indirect prompt injection. |
| Outcomes | allow · deny · pause · constrain · redact · mask — one of the richest outcome sets in the registry. |
| Not carried | Ordinary model-answer responses are not inspected on this enforcement point. Response inspection lives on the central gateway path and on the Bedrock adapter. |
| Unknown enforcement point behaviour | A enforcement point not in the registry falls back to allow, deny and approval only. Asking for a richer outcome than an enforcement point declares fails closed to a deny. |
refund_customer is not a risk. refund_customer with an amount above a threshold, against an account outside a scope, is. Policy is evaluated against the action and its arguments, an argument can be narrowed before dispatch, and the constrained call is re-verified against the exact payload rather than trusted to have been applied.
MCP CATALOG
Know which servers exist before you argue about which are allowed.
The catalog builds a register of publicly published MCP servers from three sources, scores each entry, and gives it a lifecycle state a security team can act on. It is the artifact behind the sentence "these are the servers we permit" — and its limits are as important as its contents.
Sync the official MCP servers repository and record what it publishes, with the repository metadata that goes into scoring.
Search GitHub for MCP server repositories, optionally restricted to an allowlist of organisations you actually trust.
Read manifests from a repository you control, in a catalog-only, catalog-plus-approval, or full sync mode.
The states are the point of the catalog. A discovered server is not a permitted one, and the record of who moved it and when is what makes an allowlist reviewable rather than folkloric. Entries carry their source, so "approved" always answers the follow-up question: approved on the strength of what?
ASSESSMENT · FOUR DIMENSIONS, THREE OF THEM REAL
The composite score, and the part of it that is a constant.
Each entry is assessed on four weighted dimensions and reduced to a composite risk score. Three of them are computed from evidence. The fourth is not implemented, and pretending otherwise would be the exact failure mode this product exists to argue against — so it is on the page, at the same size as the rest.
Where the server came from: official registry listing, repository age, popularity signals. A judgement about the source, not the code.
Distribution and packaging: whether a digest is pinned, how it is distributed, community signals around the repository.
The heaviest weight. Dangerous verbs in the name and description, and manifest permissions — PII access, data egress, secrets access, tool count, sandbox level, network allowlist.
Not assessed. The behavioural stage returns a fixed placeholder score for every entry, labelled "behavioural sandbox assessment is not available yet". It contributes an identical amount to every composite and distinguishes nothing.
Placeholder · not measuredBecause the behavioural stage is a constant, one fifth of every composite score is the same number for every entry in the catalog. Two servers with identical provenance, supply-chain and capability readings will always score identically, however differently they would actually behave. The catalog is a register of what publicly published servers declare about themselves, assembled from public sources — it does not connect to a server, run one, or observe what one does. A high score means "nothing in the declared metadata looked alarming", not "this server was tested and found safe."
A catalog entry gives a policy something to point at: this MCP id, this approval state, this declared capability. The decision that actually protects a system of record is the one at the action boundary — this agent, this tool, these arguments, now — and that decision is made against the live call whatever the catalog thought of the server in the abstract. Use the score to triage a review queue. Do not use it as a substitute for a control.