Cordon for MCP

Cordon for MCP

The Security Gateway for MCP Tool Calls

Website • Writeup

Quickstart • Why Cordon • How It Works • Configuration • Roadmap • Contributing

---

Every company wants to deploy AI agents. No company is willing to give an agent the keys to their database.

Cordon closes the trust gap.

From the maintainer of Agent Toolbelt — 25+ MCP tools, ~1,600 weekly npm downloads.

---

Demo

https://github.com/user-attachments/assets/153d978f-6303-443a-b49b-b4ec7ebf0452

---

The Problem

The Model Context Protocol (MCP) has made it trivially easy to give AI agents access to powerful tools — databases, file systems, APIs, cloud infrastructure.

But MCP has no built-in security model. No audit logs. No approval workflows. No rate limits. Today, an AI agent is either off or full admin. There is nothing in between.

This is the single biggest blocker preventing AI agents from reaching production.

The Solution

Cordon is the security gateway that sits between the LLM and your MCP servers.

It acts as a firewall, an auditor, and a remote control — giving you complete visibility and authority over what your AI agents can and cannot do.

┌─────────┐      ┌──────────┐      ┌──────────────┐

│ LLM / │ ──▶ │ Cordon │ ──▶ │ MCP Server │ │ Agent │ ◀── │ Gateway │ ◀── │ (database, │ └─────────┘ └──────────┘ │ fs, APIs) │ │ └──────────────┘ ├── Policy Engine ├── Audit Logger └── Approval Workflows

No infrastructure changes. No rewrites. One config file.

---

Quickstart

Step 1 — Initialize

Run this inside your project (where your claude_desktop_config.json exists):

npx @getcordon/cli init

This reads your existing Claude Desktop MCP config, generates cordon.config.ts, and patches Claude Desktop to route all tool calls through Cordon.

Step 2 — Start

npx @getcordon/cli start

Cordon starts, connects to your MCP servers, and begins intercepting tool calls. Restart Claude Desktop and every tool call now flows through the gateway.

Manual setup

If you prefer to configure manually, install globally and create a config:

npm install -g @getcordon/cli

cordon init

cordon init generates a cordon.config.ts:

import { defineConfig } from '@getcordon/policy';

export default defineConfig({ servers: [ { name: 'database', transport: 'stdio', command: 'npx', args: ['-y', '@my-org/db-mcp-server'], policy: 'read-only', // Block all write operations }, { name: 'github', transport: 'stdio', command: 'npx', args: ['-y', '@modelcontextprotocol/server-github'], policy: 'approve-writes', // Reads pass; writes require approval tools: { delete_branch: 'block', // Never, regardless of approval }, }, ],

audit: { enabled: true, output: 'stdout', // or 'file' },

approvals: { channel: 'terminal', timeoutMs: 60_000, // auto-deny after 60s; the request is retained // and replayable if approved late }, });

---

Why Cordon

---

Features

Policy Engine

Define rules per tool, per server, or globally. Tool-level policies override server policies.

// Server-level default

policy: 'approve-writes',

// Per-tool overrides tools: { query: 'allow', // reads: pass through execute: 'approve', // writes: pause for human approval drop_table: 'block', // catastrophic: always reject list_tables: 'log-only', // audit but don't interrupt },

Human-in-the-Loop Approvals

When a tool call requires approval, Cordon pauses the agent and prompts you directly in your terminal:

╔══════════════════════════════════════╗

║ ⚠ APPROVAL REQUIRED ║ ╚══════════════════════════════════════╝ Server : database Tool : execute_sql Args : { "query": "DELETE FROM sessions WHERE expires_at < NOW()" }

[A]pprove [D]eny

The agent waits. You decide.

Prefer Slack? Connect your workspace once with Add to Slack in the dashboard — no bot token to create or paste — then set approvals: { channel: 'slack' }. A flagged call posts an Approve / Deny card to your channel and pauses until a human clicks, and the approver's name is written onto the audit record. See the Slack approvals setup.

When nobody answers in time. The call is denied and the agent moves on, but the request isn't lost. Cordon retains the pending approval with its full context, and the dashboard lists it under What changed → Timed-out approvals. If someone approves the card after it expired, that late decision is recorded and the call can be re-run:

cordon replay <callId>

The replay executes the tool and logs the outcome to the same audit stream with reason replay of late-approved call. It recovers the tool call, not the agent's session — the agent that asked is long gone. Only a call approved *after* timing out is replayable, since replaying a call that already ran would double-execute it.

Audit Logging

Every tool call is logged as structured JSON — the request, the policy decision, the response, and timing. Pipe to stdout or write to a file for your compliance team.

{"event":"tool_call_received","callId":"...","serverName":"database","toolName":"execute_sql","timestamp":1773434469641}

{"event":"approval_requested","callId":"...","serverName":"database","toolName":"execute_sql","timestamp":1773434469641} {"event":"tool_call_approved","callId":"...","serverName":"database","toolName":"execute_sql","timestamp":1773434471203} {"event":"tool_call_completed","callId":"...","durationMs":34,"isError":false,"timestamp":1773434471237}

Read-Only Mode

One policy setting to block all write operations across a server. Zero guesswork about what counts as a write — Cordon detects it from the tool name.

policy: 'read-only'  // any tool starting with write/create/update/delete/drop/execute/... is blocked

Hidden Tools

For tools the model should never even see — not just rejected on call, but filtered from the tools/list response entirely. Closes a prompt-injection surface: if the model never knows a tool exists, it can't be tricked into calling it.

{

name: 'database', policy: 'approve-writes', tools: { drop_table: 'block', // call attempts are rejected internal_admin: 'hidden', // not advertised to the client at all }, }

SQL-Aware Policies

For database MCP servers where a single tool takes arbitrary SQL (Postgres, SQLite, BigQuery, etc.), tool-name heuristics aren't precise enough — the name query doesn't tell you whether the agent's about to SELECT or DROP TABLE. Cordon ships two policies that parse the SQL itself and decide based on the statement type.

tools: {

// Allow SELECTs (including CTEs that wrap a SELECT). Block everything else. query: 'sql-read-only',

// Reads pass; writes (INSERT/UPDATE/DELETE/DROP/ALTER/...) pause for human approval. execute: 'sql-approve-writes',

// When the tool takes SQL in a different arg name: run: { action: 'sql-read-only', sqlArg: 'statement' }, }

Both policies use the PostgreSQL dialect by default (others coming later) and are fail-closed: unparseable SQL is blocked rather than allowed. Prompt-injection patterns like SELECT 1; DROP TABLE users; and block-comment-wrapped keywords are correctly classified as writes by the AST parser.

Closed-World Tool Catalogs

Declare the exact tool surface your upstream server is expected to advertise. When the upstream adds a new tool in a future release, Cordon blocks it automatically until you explicitly promote it.

{

name: 'postgres', command: 'npx', args: ['-y', '@modelcontextprotocol/server-postgres', process.env.POSTGRES_URL!], policy: 'read-only', knownTools: ['query', 'list_tables', 'describe_table'], // your approved surface onUnknownTool: 'block', // default when knownTools is set }

If the next Postgres MCP release adds truncate_table, Cordon blocks it with a stderr warning — no policy update needed. Leave knownTools undefined for backwards-compatible open-world behavior.

Per-Agent Policies + Call-Graph Constraints

Per-tool policies catch dangerous *individual* calls. Call-graph rules catch dangerous *sequences* — combinations of allowed tools used in unintended order. The classic example: an agent reads sensitive data with read_data (allowed) and then writes it to disk with write_file (also allowed). Each call is fine in isolation. The *sequence* is the problem.

Cordon's call-graph rules apply on top of your per-tool policy and are additive — they can only raise severity, never lower it.

export default defineConfig({

// Optional identity for this Cordon process. Surfaced in audit logs. agentId: 'et-acquisition-agent',

servers: [{ name: 'demo-db', transport: 'stdio', command: 'npx', args: ['-y', '@my-org/db-mcp'], policy: 'approve-writes', }],

callGraph: [ // Reading data and then writing to disk is the exfil shape — block it, // even though write_file would only require approval on its own. { from: 'read_data', to: 'write_file', action: 'block', reason: 'No file writes after database reads.' },

// Glob matching: any send_* tool right after a database read needs human approval. { from: 'read_data', to: 'send_*', action: 'approve' },

// * matches anything: after a privileged read, every next call must be approved. { from: 'sensitive_read', to: '*', action: 'approve' }, ], });

How rules combine with per-tool policies (additive severity):

Severity ordering: allow < approve < block.

A call-graph rule only takes effect if its action is *higher* severity than the per-tool decision. That means:

• A rule with action: 'block' overrides an allow per-tool policy ✓
• A rule with action: 'approve' overrides allow, but doesn't lower a block ✓
• A rule with action: 'allow' never weakens a stricter base — it's a no-op
• When multiple rules match, the highest-severity one wins (config order doesn't matter)

One-way ratchet — tighten only, never loosen.

**Audit log gains chain co