The MCP Proxy: Guarding Every AI Tool From One Place

Every AI coding tool on the market connects to MCP servers directly. Cursor reads from your database MCP. Copilot calls your deployment MCP. Cline talks to your Supabase MCP. Each connection is a direct pipe with zero oversight. If the AI decides to drop a database table or delete a production branch, nothing stands in the way.

This is the problem I set out to solve with theGuard's MCP proxy.

The Direct Connection Problem

MCP (Model Context Protocol) is the standard way AI tools talk to external services. Your AI editor connects to an MCP server, discovers available tools, and starts calling them. The protocol itself has no concept of authorization beyond "the server is running." If the server exposes a tool called delete_branch, the AI can call it. There is no review step, no policy layer, no audit log.

I watched an AI agent try to "clean up" a Supabase project by deleting what it considered unused database branches. It had the tool available. It had a plausible reason. The only thing that stopped it was that I happened to be watching the terminal at that exact moment.

That is not a safety strategy. That is luck.

How the Proxy Works

theGuard's MCP proxy sits between the AI tool and every upstream MCP server. From the AI tool's perspective, it is connecting to a single MCP server (theGuard). From the upstream servers' perspective, they are receiving calls from a normal client. theGuard is transparent in both directions.

The architecture is straightforward. When the proxy starts, it reads the AI tool's MCP configuration file to discover which servers are configured. For Cursor, that means reading .cursor/mcp.json. For VS Code extensions, it reads the appropriate settings file. theGuard calls this auto-discovery, and it means you do not have to manually configure which servers to proxy. It finds them automatically.

Once the upstream servers are discovered, theGuard connects to each one, queries their available tools, and builds a routing table. The routing table maps every tool name to its upstream server. When the AI tool calls supabase_delete_branch, theGuard knows exactly which server to forward it to, after checking it against the rule engine first.

The Interception Flow

Every tool call follows the same path. The AI tool sends a request to theGuard. theGuard extracts the tool name and arguments. It runs the tool call through its pattern matching engine, which checks against over 170 built-in rules organized by platform.

If the call matches a block rule, theGuard returns an error response to the AI tool explaining why the action was blocked and suggesting a safer alternative. The AI never touches the upstream server. If the call is clean, theGuard forwards it to the correct upstream server and passes the response back.

The matching is fast. Rules are compiled to a JSON registry at build time, and lookups are simple string matches or regex tests against tool names and argument patterns. The overhead is negligible, typically under two milliseconds per call.

The guard_exec Tool

Shell commands are a special case. Many AI tools can execute arbitrary shell commands through MCP, and those commands can do anything the user's shell can do. theGuard handles this with a dedicated tool called guard_exec.

When an AI tool tries to run a shell command, the request routes through guard_exec instead of going directly to a shell. guard_exec parses the command, checks it against platform-specific rules (is this an AWS CLI call that would delete resources? A kubectl command that would modify production?), and either blocks or forwards it.

This is the same rule engine that handles MCP tool calls, but applied to raw shell commands. The AI tool does not know the difference. It sends a command, and either gets output back or gets an error explaining why the command was blocked.

A Real Example

Here is what happens when an AI agent tries to delete a Supabase branch through theGuard:

The AI decides it wants to clean up branches. It calls the supabase_delete_branch tool with the branch ID as an argument. The call arrives at theGuard's proxy. theGuard matches the tool name against rule SUP-003 ("Block Supabase branch deletion"). The rule has severity "critical" and impact "Deletes a database branch, potentially destroying data and schema changes."

theGuard blocks the call and returns a structured response: the action was blocked, here is the rule that triggered, and here is the suggested remediation ("Use the Supabase dashboard to manually review and delete branches"). The AI receives this as a tool error and moves on to other tasks.

No data was lost. No human had to be watching. The policy was enforced automatically.

Auto-Discovery Details

The auto-discovery system handles the messy reality that every AI tool stores its MCP configuration differently. Cursor uses .cursor/mcp.json in the project root. VS Code uses settings.json or workspace configuration. Other tools have their own conventions.

theGuard scans for all known configuration file locations, parses each one, and extracts the server definitions. It deduplicates servers that appear in multiple configurations (common when you use several AI tools on the same project). The result is a single unified view of every MCP server your AI tools have access to.

During initialization, theGuard prints a summary: how many servers were discovered, how many tools are available, and how many rules are active. This gives you immediate visibility into what is being protected.

Why a Proxy Instead of a Plugin

I considered building theGuard as a plugin for each AI tool individually. That approach has an obvious problem: you need a separate implementation for every tool, and each tool has different plugin APIs, different lifecycle hooks, and different levels of access to MCP calls.

The proxy approach works everywhere. Any tool that speaks MCP can be protected by pointing it at theGuard instead of directly at upstream servers. One implementation, universal coverage. When a new AI coding tool launches next month, it works with theGuard on day one, no adapter needed for MCP interception.

The tradeoff is that the proxy only sees MCP traffic. It cannot intercept tool-specific behaviors that bypass MCP. That is why theGuard also supports shell hooks and tool-specific adapters for deeper integration. The proxy is the first line of defense, not the only one.