Skip to content
Cordum
MCP Governance

Put policy in front of MCP tool calls routed through Cordum.

Enable Cordum's policy gate to approve, deny, constrain, and audit routed tool calls before agents mutate governed systems.

Read the MCP server docsSee Cordum Edge
  • Gateway auth and tenant scope
  • Approval-gated mutations
  • Audit-correlated retries
tools/call response
json
{
  "jsonrpc": "2.0",
  "id": 7,
  "error": {
    "code": -32099,
    "message": "approval required",
    "data": {
      "tool": "cordum_update_policy_bundle",
      "approval_ref": "edge_appr_…",
      "retry_hint": "retry_with_approval_ref"
    }
  }
}

Mutation paused

The caller retries the same arguments with resolved approval evidence.

JSON-RPC 2.0 over stdio or Gateway HTTP/SSE.

Available today

A concrete MCP control surface—not a logo wall.

Cordum ships a built-in MCP server and Gateway transport with scoped discovery and approval-aware mutations.

JSON-RPC 2.0

Discover and call Cordum tools and resources over the standard MCP request model.

Two transports

Use standalone stdio locally or Gateway HTTP/SSE for authenticated remote clients.

Caller scope

Gateway authentication, tenant checks, and caller-scoped discovery narrow what each client can see.

Approval holds

Built-in mutating tools and enabled policy gates can pause a call before side effects.

Decision path

Scope, decide, hold, and retry.

The call stays bound to the same identity, arguments, and approval evidence across the decision path.

  1. 01

    Client connects

    An MCP client initializes over stdio or Gateway HTTP/SSE.

  2. 02

    Gateway scopes

    Authentication and tenant context shape tool and resource visibility.

  3. 03

    Policy evaluates

    With mcp.policy_gate_enabled=true, tools/call enters the policy and action-gate path.

  4. 04

    Call holds or runs

    A mutation can return -32099 with approval coordinates instead of executing.

  5. 05

    Approved retry

    The client retries identical arguments with _approval_ref; the server validates and consumes it.

Turn the policy gate on deliberately.

The per-tool gate is opt-in so existing MCP deployments keep their current behavior until operators enable and validate policy.

  • Set mcp.policy_gate_enabled=true in Gateway configuration.
  • Test allow, deny, approval, expiry, and argument-mismatch paths before rollout.
  • Treat arbitrary external MCP servers as managed or preview scope—not blanket turnkey integrations.

Frequently Asked Questions

Is the MCP policy gate enabled by default?
No. Set mcp.policy_gate_enabled=true to opt into per-tool policy and approval handling; the default remains off for compatibility with existing deployments.
Does Cordum ship every external MCP integration?
No. Cordum's built-in server, tools, resources, Gateway transport, authentication, tenant checks, and mutating-tool approvals are available today. Arbitrary external MCP server mediation should be evaluated against the managed or preview surface rather than assumed turnkey.
What binds an approved retry?
The approval path validates tenant, requester, tool, canonicalized arguments, action hash, policy snapshot, expiry, and approval state before consuming the approval.

Put a human decision in front of the next MCP mutation.

Start with Cordum's built-in tool surface, enable the policy gate, and verify the approval retry path before expanding scope.

Open MCP server docsTalk to an engineer