How to Govern MCP Server Integrations
MCP servers give AI agents access to tools and resources. Every new integration expands the attack surface. Cordum governs which tools execute.
The problem with ungoverned MCP Servers agents
- MCP servers expose their tools to any connected client over JSON-RPC. The protocol negotiates capabilities, but it has no built-in policy layer deciding which tool calls should actually run.
- Permissions are typically all-or-nothing per server. Once an agent is connected, it can invoke every tool the server advertises, with no per-tool or per-context restriction.
- Every server you attach multiplies the potential for unintended action. A GitHub server can push commits, a database server can delete records, and the model decides when each fires.
- There is no native approval workflow. When the model calls a tool, the server executes it immediately, so a single bad reasoning step can take a real-world action before anyone reviews it.
How Cordum governs MCP Servers
Route tool calls through the Cordum MCP server
Cordum ships its own MCP server that sits in front of your tools as a governance proxy. It speaks JSON-RPC over stdio for local clients and over HTTP/SSE for remote ones, so existing MCP clients connect to Cordum without code changes and every tools/call is evaluated before dispatch.
// Cordum MCP server transport modes:
// stdio: cordum-mcp --addr http://localhost:8081 --api-key $CORDUM_API_KEY
// HTTP/SSE: POST /mcp/message, GET /mcp/sseWrite per-tool and per-server policies
Instead of a single on/off switch per server, Cordum policies match on the MCP server, tool, resource, and action so you can govern individual tools. Require approval for write-category GitHub tools while a destructive delete tool is denied outright, and update the rules without redeploying any server.
rules:
- name: github-write-approval
match:
mcp:
server: github
action: write
action: REQUIRE_APPROVAL
approvers: ["engineering-lead"]
- name: db-delete-block
match:
mcp:
tool: delete_records
action: DENYConstrain risky calls instead of blocking them
When a tool should run but only within bounds, ALLOW_WITH_CONSTRAINTS lets the call proceed with a scoped constraint payload: limited file paths, capped record counts, or an allowlist of API destinations. The agent keeps working while the dangerous edges are fenced off.
Audit every MCP call in one timeline
Cordum records a structured pre/post event for each governed tool call, with the requesting principal, server, tool, decision, and a redacted argument summary. The result is one unified audit trail across every MCP server rather than separate per-server logs an auditor has to stitch together.
MCP Servers native vs Cordum governance
| Area | MCP Servers Native | With Cordum |
|---|---|---|
| Tool access | All-or-nothing | Per-tool rules |
| Approvals | None | Per tool/category |
| Constraints | Server-side only | Policy-defined |
| Cross-server | Independent | Centralized |
| Audit | Per-server logs | Unified log |
FAQ
Does Cordum replace my existing MCP servers?
No. Cordum runs as a governance proxy in front of your servers. Your tools and resources keep their existing implementations; Cordum only decides which calls are allowed, constrained, or held for approval before they reach the underlying handler.
Does it work with any MCP client?
Yes. Cordum exposes the standard JSON-RPC methods over both stdio and HTTP/SSE, so any MCP-compatible client, including Claude Desktop and Claude Code, can connect to it the same way it would connect to any other MCP server.
Can Cordum govern resources, not just tools?
Yes. Policies can match on MCP servers, tools, resources, and actions, so reads against a sensitive cordum:// resource can be governed with the same rules you use for tool calls.
Related guides
Ready to govern your MCP Servers agents?
Start with the open-source Cordum platform. Add policies, approvals, and audit trails in minutes.