MCP Action Governance
Authorize the exact callTool — not just that the tool exists.
MCP makes tools reachable. OAuth and RBAC identify principals. Neither answers whether this exact tool call, with these arguments, should create a side effect now. Strix adds that decision on routes you put through its proxy or adapter.
Answers the question: “How do we govern MCP tool calls before the server executes them?”
- Also: “How do you secure write-capable MCP tools so writes need approval?”
- Also: “How do you prevent an MCP agent from replaying an approved transaction?”
- Also: “How do I put an approval gate in front of MCP callTool writes without rewriting every tool?”
The MCP authorization problem
Discoverability and connectivity are not authorization. Approvals that bind only to tool names fail under parameter drift. Logs after execution cannot deny a side effect that already happened.
A tool is available to the agent, so every syntactically valid call is treated as authorized.
Approval covers a tool name while material arguments change before the server runs.
Sensitive MCP calls are logged after execution with no deny or hold state before forwarding.
The proxy route is governed, but the same server remains reachable on a direct connection.
Transport or policy failure silently falls back to forwarding instead of failing closed.
Bring one consequential MCP tool
Name the tool, its side effect, the arguments that matter, and the connection path that reaches the server.
Packages and live surfaces
Claim scope follows the route: only traffic through the governed adapter or proxy is in scope.
@strixgov/mcp-adapter
Wrap MCP callTool with policy evaluation and signed receipts.
@strixgov/mcp-proxy
Governed stdio MCP proxy for traffic you route through Strix.
@strixgov/tool-gateway
Classify → evaluate → allow/deny/hold with append-only receipts.
MCP Security Gateway
Live evaluation landing for one consequential MCP tool.
Action binding at the MCP boundary
Map tool + args → capability → policy → allow/deny/approval-required before the MCP server sees the call. Produce a signed receipt for governed decisions.
| Capability | How Strix delivers it |
|---|---|
| Tool-to-capability mapping | Do not treat tool discovery as permission to execute. |
| Pre-forward decision | Decide before the proxy or adapter forwards an in-scope call. |
| Argument constraints | Evaluate the resource, amount, recipient, destination, or command that defines the side effect. |
| Approval path | Bind human authority to the exact action presented at point-of-use. |
| Receipt path | Keep decision state distinct from the downstream server's terminal execution state. |
| Coverage statement | Document which connection is routed through Strix. See also /mcp-security-gateway. |
Proof, not promises
Every claim Strix makes is backed by an artifact you can independently verify.
Adapter demo
End-to-end governed MCP round-trip in under 20 seconds.
npx @strixgov/mcp-adapter demoIndependent verify
Verify signed receipts against public JWKS.
npx @strixgov/verifier@latest 5686Refund once (simulated)
Interactive exact-request bind + one-use grant before a simulated adapter.
/demo/refundSituation: MCP write gate
Entry page for write-capable MCP callTool approval without rewriting every tool.
/situations/mcp-write-approval-gatePublic packages
mcp-adapter, mcp-proxy, and tool-gateway are published for inspection.
github.com/Strixgov/strixFrequently asked questions
Does this replace an MCP server?+
No. The adapter or proxy sits between client and server. The server still implements its tools.
Does OAuth already solve MCP governance?+
OAuth solves identity. The remaining question is whether this exact callTool with these arguments should run now.
How is this different from the MCP Security Gateway page?+
This page is the claim→proof definition of MCP action governance. The gateway page is the evaluation landing for mapping one consequential tool. Use both.
What should we evaluate first?+
One tool with a consequential side effect: message send, account change, data write, command execution, payment, or protected-data disclosure.
How do you secure write-capable MCP tools?+
Reachability and OAuth identify a principal and make a tool callable. They do not authorize this callTool with these arguments now. Put an execution-control boundary on the route: map tool + args → capability → policy → Allow / Deny / Intercept before the MCP server sees the write. Bind any human approval to the material arguments (amount, customer, order, destination), not the tool name. Only traffic you route through the adapter or proxy is in scope — inventory direct connections separately. See also /situations/mcp-write-approval-gate.
How do I put an approval gate in front of MCP callTool writes without rewriting every tool?+
Wrap the client→server path. @strixgov/mcp-adapter wraps callTool. @strixgov/mcp-proxy is a governed stdio proxy. @strixgov/guard is the writes-need-approval / reads-pass seatbelt. The MCP server still implements the tools. High-risk writes Intercept for human approval bound to the exact args; reads can pass. Each governed call can emit a signed receipt.
How do you prevent an MCP agent from replaying an approved transaction?+
An approval that can be captured and resent is not an execution grant. Strix execution grants are single-use: the first redeem consumes the grant; a second identical callTool must fail closed. That is invariant #5 on the runtime claim, not a prompt instruction. Specimen adjacency: /demo/refund refuses a consumed authorization; CFX-001 refuses a payload that no longer matches the bound authority.
Does putting a gateway on MCP secure all agent write paths?+
No. The proxy or adapter governs routed traffic only. Direct SDK calls, workers, and alternate connections that never hit the boundary are out of claim scope and must be inventoried separately. Governing one route does not secure the system.