The Problem Nobody Talks About
AI agents are getting powerful fast. With the Model Context Protocol (MCP), a single agent can read your files, call external APIs, execute shell commands, and query databases — all in one conversation.
That power is exactly why security matters. But when you look at how most developers are trying to secure MCP today, there's a pattern worth questioning.
The Proxy Approach (and Its Hidden Cost)
Most MCP security tools today work as a proxy — a separate process that sits between your AI model and your MCP server, intercepting every request.
It sounds clean on paper. In practice, it means:
- Extra infrastructure to deploy and keep running — one more service to monitor, restart, and update
- Network latency on every single tool call — every request makes an extra hop before it executes
- Another failure point — if the proxy goes down, your entire tool execution goes down with it
- A different language — most proxy-based tools are written in Python, so TypeScript/Node.js developers are working across a language boundary they didn't ask for
The proxy approach made sense when MCP was new and people were experimenting. But for production systems, embedding security directly in your server code is a better architecture.
The Library Approach
That's the philosophy behind mcp-warden — a TypeScript library that adds a security middleware chain directly inside your existing MCP server. No separate process. No deployment complexity. No network overhead.
You import it, wrap your handler, and your server has a full security layer.
import { McpGuardian, PolicyBuilder } from "mcp-warden";
const policy = new PolicyBuilder()
.allow("read_file")
.allow(/^search_/)
.block("/etc")
.readOnly("/home")
.rateLimit(60)
.build();
const guardian = new McpGuardian(policy);
const guardedHandler = guardian.wrapHandler(async (request) => {
// your existing handler logic — unchanged
return yourMcpServer.handle(request);
});
That's it. Every tool call now passes through a full security pipeline before your handler touches it.
What the Pipeline Actually Does
When a request arrives, mcp-warden runs it through 8 built-in checks in sequence. The first failure short-circuits — nothing downstream executes.
1. Tool authorization — is this tool on the allowlist? Supports exact names and regex patterns.
2. Input size limits — are the arguments within nesting depth and byte size limits? Oversized payloads are blocked before any parsing happens.
3. Argument schema validation — do the arguments match the declared shape for this tool? You define the schema per tool:
.argSchema("create_file", {
type: "object",
required: ["path", "content"],
properties: {
path: { type: "string", minLength: 1 },
content: { type: "string", maxLength: 65536 }
}
})
If the AI sends create_file with a missing path, it's blocked before execution.
4. Path enforcement — does this call touch a restricted filesystem path?
.block("/etc") // all access denied
.readOnly("/home") // reads allowed, writes denied
5. Approval gating — if approvalRequired: true, every tool call returns REQUIRES_APPROVAL until a human signs off.
6. Rate limiting — global sliding window plus optional per-tool overrides, implemented with an O(1) circular buffer.
7. Prompt injection scanning — scans all tool arguments for known injection phrases using word-boundary regex to avoid false positives.
8. Circuit breaker — if a tool keeps failing, its circuit opens automatically and stays open until cooldown expires. Idle circuits are evicted from memory to prevent leaks.
Observability Built In
After every request — allowed or blocked — the guardian emits a typed event:
guardian.on("blocked", (event) => {
logger.warn("Tool call blocked", {
tool: event.toolName,
reason: event.reason,
code: event.violationCode,
durationMs: event.durationMs
});
});
guardian.on("allowed", (event) => {
metrics.increment("tool.call", { tool: event.toolName });
});
No polling. No separate log parser. Security events flow directly into your existing observability stack.
PII Redaction on Outputs
Tool responses can contain sensitive data — emails, API keys, IP addresses, phone numbers. mcp-warden automatically strips them from every tool response before returning to the caller, in a single combined regex pass:
// Tool returns: "Contact alice@company.com, key: sk-ABCDEF12345678"
// Guardian returns: "Contact [REDACTED], key: [REDACTED]"
Opt out if you need raw outputs:
new McpGuardian(policy, { redactToolOutputs: false });
Zero Runtime Dependencies
The entire library ships with zero runtime dependencies. No supply chain risk from third-party packages. The validator, rate limiter, circuit breaker, injection scanner, and PII redactor are all built from scratch in pure TypeScript.
npm install mcp-warden # installs nothing else
CLI Tools for Config Auditing
If you work with claude_desktop_config.json or any MCP client config, the CLI can audit it for dangerous permissions:
npx mcp-warden audit ./claude_desktop_config.json
Output:
SAFE: filesystem-server
CRITICAL: code-runner
- Command-line flags indicate unrestricted filesystem access.
Watch mode re-audits automatically every time you save the file:
npx mcp-warden audit --watch ./claude_desktop_config.json
Validate a policy file before deploying it:
npx mcp-warden validate ./mcp-policy.json
# SAFE: mcp-policy.json is a valid GuardianPolicy.
Generate a JSON Schema for IDE autocomplete:
npx mcp-warden schema --output mcp-policy.schema.json
Getting Started
npm install mcp-warden
import { McpGuardian, PolicyBuilder } from "mcp-warden";
const policy = new PolicyBuilder()
.allow("read_file")
.block("/etc")
.rateLimit(60)
.build();
const guardian = new McpGuardian(policy);
guardian.on("blocked", (event) => console.warn(event.reason));
export const handler = guardian.wrapHandler(yourExistingHandler);
Full docs and source: github.com/vikrantwiz02/mcp-warden
npm: npmjs.com/package/mcp-warden
If you're building MCP servers in TypeScript and care about what your AI is actually allowed to do — I'd love your feedback.