Cordum vs Permit.io MCP Gateway
Permit MCP Gateway decides which MCP tools an agent may call on a person's behalf. Cordum decides whether a specific agent action runs, waits for approval, or stops.
Short answer
Permit MCP Gateway is an authorization proxy for MCP traffic. It signs the user in, records how much access that user delegates to an agent, checks each tool call against Permit policy (an OPA-based decision point with Zanzibar-style relationships) and logs the result.
Cordum is an action firewall for AI-agent actions. Cordum Edge puts a policy check in front of Claude Code shell commands, file reads and writes and other tool calls; the Safety Kernel returns ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE or ALLOW_WITH_CONSTRAINTS and records redacted evidence.
Pick Permit when the gap is per-user, per-tool access to third-party MCP servers. Pick Cordum when the gap is what coding agents and agent jobs actually do. The two overlap mainly at MCP tool calls, and they can run together.
What Permit MCP Gateway is
- A proxy between MCP clients (Claude Code, Cursor, VS Code, Claude Desktop) and upstream MCP servers. Clients use the gateway URL instead of the server URL; Permit documents no SDK or server changes.
- A consent flow: the user grants an agent a trust level per server, capped by an admin-set ceiling. Tools are classed low (read), medium (write) or high (destructive).
- Each tool call is checked by Permit's policy decision point, which runs OPA and uses Zanzibar-style relationship policies alongside RBAC and ABAC. The agent gets the lower of its own role and the human's relation to the server. The default is deny.
- Each allow or deny is logged with the human, agent, tool, server and time, and can be read in Permit's dashboards or through its audit logs API.
- Enterprise plans add human-in-the-loop approvals (the call is held until an admin decides; default timeout five minutes) and customer-controlled or fully on-premises deployment. The hosted gateway runs on agent.security.
- Separate from the gateway: the open-source (MIT) Access Request MCP server, which lets an agent file access requests and one-time operation approvals for a human reviewer in Permit.
- Status as of 2026-10-26: Permit announced the gateway on 2026-03-17 and says it is also known as Agent.Security or MCPermit. The current docs describe a working product with no beta or early-access label.
What Cordum is
- Edge first: cordumctl edge claude launches Claude Code with a PreToolUse hook registered for every tool. The hook sends a redacted action envelope to a local cordum-agentd, which asks the Cordum Gateway and Safety Kernel for a decision before the tool runs.
- Five decisions: ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE and ALLOW_WITH_CONSTRAINTS. An approval is single-use and bound to the tenant, action hash, input hash and policy snapshot; the agent retries the same action to use it.
- MCP governance second: Cordum's built-in MCP server runs over stdio or Gateway HTTP/SSE. On the Gateway path, an opt-in per-tool policy gate (mcp.policy_gate_enabled) adds approval holds and argument redaction. Cordum's MCP Gateway route for third-party servers is disabled by default; the current docs describe it as a skeleton that does not forward to upstream servers.
- Platform third: the same Safety Kernel evaluates jobs before the scheduler dispatches them. Policy is YAML, the first matching rule wins, the default is deny, and bundles must be Ed25519-signed in production.
- Evidence: Edge events keep redacted descriptors, hashes and artifact pointers, not raw prompts, tool payloads or secrets. Audit events are SHA-256 hash-chained per tenant.
- Customer-managed and source-available under BUSL-1.1. The documented Edge path builds cordumctl, cordum-hook and cordum-agentd from source. The local wrapper is a developer path; fleet enforcement needs managed Claude Code settings and endpoint controls.
Side by side
Each row is checked against Permit's and Cordum's documentation as of 2026-10-26.
| Evaluation area | Cordum | Permit MCP Gateway |
|---|---|---|
| Question it answers | Should this specific action run now, wait for a reviewer, be throttled or run with constraints? | May this agent, acting for this person, call this MCP tool on this server? |
| Where it enforces | Claude Code PreToolUse hook through local agentd (Edge), Cordum's MCP server policy gate, and the Safety Kernel before job dispatch. | A proxy in front of upstream MCP servers. Tool listing returns every upstream tool; enforcement happens on each tool call. |
| Actions covered | Claude Code shell commands, file reads and writes, and other tool calls that reach the hook, MCP tools included; Cordum's built-in MCP tools on the Gateway path when the gate is on; jobs submitted through Cordum. | MCP tool calls through the gateway. An HTTP egress proxy, enabled per account, extends checks to an agent's direct REST and webhook calls. |
| Policy model | YAML rules matching topic, capability, risk tags, labels, actor, tenant and MCP server, tool or action. First match wins; default deny. | Permit policies evaluated by Permit's PDP (OPA inside, updates pushed by OPAL): Zanzibar-style ReBAC plus RBAC and ABAC, with per-tool trust levels. |
| Decisions | ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE, ALLOW_WITH_CONSTRAINTS. | Allow or deny per tool call; on Enterprise plans a call can be held for admin approval. |
| Human-to-agent delegation | Not modeled as end-user consent. Agent-to-agent delegation tokens narrow scope, expire and can be revoked; they build on agent identities, an Enterprise entitlement. | Core feature: the user consents and picks a trust level up to an admin ceiling; sessions expire 90 days after the last tool call. |
| Human approval | REQUIRE_APPROVAL is in the core. Claude Code gets a deny with an approval_ref and retries after review; MCP calls return an approval hold. Destructive retries also need a resolved approval event in the audit chain. | Enterprise plans: held calls appear on an Approvals page, with email, Slack and browser notifications. The open-source Access Request MCP covers request-and-approve flows inside apps. |
| Audit evidence | Redacted action descriptors, hashes and artifact pointers; per-tenant SHA-256 hash chain; SIEM export (webhook, syslog, Datadog, CloudWatch) is an Enterprise entitlement. | Each decision with timestamp, user key, tool, server, decision and reason, in Permit's dashboards or through the audit logs API. |
| Tool-result inspection | Output policy can redact or quarantine results of jobs run through Cordum when it finds secrets, PII or injection content. It covers Platform jobs, not every tool result. | Out of scope per Permit's docs: the gateway does not inspect data returned by tool calls, and prompt-injection defense belongs in the client and model layer. |
| Deployment | Customer-managed with Docker Compose or Helm; source-available under BUSL-1.1. | Hosted gateway on agent.security; customer-controlled or fully on-premises on Enterprise plans. |
| Coding-agent endpoints | Cordum Edge for Claude Code through hooks; fleet rollout uses managed settings and endpoint controls. | A separate Coding Agents Gateway product, offered as early access on its product page. |
When to choose Permit MCP Gateway
- You need per-user, per-tool authorization in front of third-party MCP servers such as GitHub or Linear, without changing those servers.
- You want end users to consent to, and cap, the access they delegate to each agent.
- Your authorization model already lives in Permit, or you want relationship-based policy shared across apps and agents.
- A hosted gateway suits your evaluation, with self-hosting available on an Enterprise plan.
When to choose Cordum
- Developers run Claude Code and the risk is local action: destructive shell commands, credential reads, file writes, git pushes.
- You need more than allow or deny: approval holds bound to the exact action, throttles and constraints.
- You want one policy engine and one evidence trail across coding agents, Cordum's MCP tools and agent jobs.
- Policy, approvals and redacted evidence must run on infrastructure you operate.
Using both together
The products meet mainly at MCP tool calls, so the layers stack cleanly. Cordum does not ship a Permit.io integration; each product runs its own check.
- Claude Code proposes a tool call. Cordum Edge's PreToolUse hook evaluates it first: shell and file actions are classified, and MCP tools reach the same policy check. Tools the classifier does not recognize are tagged for review, so policy can deny them or require approval.
- If Cordum allows the call, or a reviewer approves it and the agent retries, an MCP call goes on to Permit's gateway.
- Permit checks the agent's delegated trust level and relationships for that tool, then forwards or denies the call.
- Each product keeps its own record: Cordum's redacted decision evidence and Permit's audit log.
Related comparisons
Frequently Asked Questions
Is Cordum an alternative to Permit MCP Gateway?
Is Permit MCP Gateway available today?
What is MCPermit?
Does Permit MCP Gateway govern shell commands or file writes?
Can Cordum and Permit run together?
Which Cordum capabilities are license-gated?
Sources
All sources accessed 2026-10-26. Vendor descriptions are paraphrased from the pages below.
Permit.io
Start with the actions your coding agents take
Put policy, approvals and redacted evidence in front of Claude Code shell and file actions, then extend the same policy to MCP tool calls routed through Cordum.