The "Cloudflare for AI Agents" Is Here (MCP Security Proxy)

[Harshit-J004]

The Model Context Protocol (MCP) by Anthropic, OpenAI, and Google is revolutionizing how LLMs talk to databases and external tools. But there’s a massive problem: The protocol has zero native security. It’s entirely unguarded JSON-RPC traffic.

Today we are releasing ToolGuard v5.0.0 — the first transparent, runtime security proxy for the entire MCP ecosystem.

We built a 6-layer interception firewall that sits perfectly between ANY MCP client (Claude, Gemini, etc.) and ANY MCP server:

The 6-Layer Interceptor Pipeline

1. Policy Enforcement: Hard-block specific dangerous tools (e.g. execute_code).
2. Risk-Tier Gating: Pause destructive MCP tools (e.g. drop_database) and require human approval.
3. Injection Scanning: Recursive DFS memory scanner to neutralize Reflected Prompt Injection.
4. Rate Limiting: Per-tool call frequency caps protect your upstream services.
5. Semantic Policy: Context-aware authorization—beyond type-checking (e.g., path patterns, regex).
6. Trace Logging: Full execution DAG recorded for audit and replay.

Universal Compatibility

ToolGuard proxy operates strictly at the raw JSON-RPC 2.0 transport layer. Zero vendor coupling. You don't need to rewrite your agent. It seamlessly protects MCP servers written in Python, TypeScript, Go, or Rust.

Before (unguarded):
claude --mcp-server "python database_server.py"

After (guarded by ToolGuard):
toolguard proxy --upstream "python database_server.py" --policy security.yaml

The 10-Framework Integration Milestone

Alongside the MCP Proxy, ToolGuard cross the 10-integration mark. We have added native, zero-config adapters for the OpenAI Agents SDK and the Google Agent Development Kit (ADK).

Terminal Elite Web Dashboard ("Obsidian")

ToolGuard now ships with a zero-dependency, real-time web dashboard. Run toolguard dashboard and instantly monitor every agent tool call as it happens:

• Server-Sent Events (SSE) stream traces with zero latency
• Live 6-Layer Sentinel HUD shows exactly which security layer fired
• Deep payload JSON inspector reveals the exact hallucinated arguments
• Global Kill-Switch instantly freezes all agent execution

Verified With Live LLM Traffic (Gemini 2.0 Flash)

We did not just build this in theory. We connected a live Google Gemini 2.0 Flash API to the proxy and ran a deep 6-layer stress test:

• L1 Policy: Permanently blocked delete_database — instant deny.
• L2 Risk-Tier: Headless auto-deny on Tier-2 shutdown_server.
• L3 Injection: Detected [SYSTEM OVERRIDE] prompt injection in nested args.
• L4 Rate-Limit: Burst 12 rapid calls throttled at 10/min sliding window.
• L5 Semantic: Regex-denied DROP TABLE users from a LIVE Gemini function call.
• L6 Trace: Clean read_file passed all 6 layers and logged to execution DAG.

Every layer. Every attack vector. Zero mocks. All verified against real LLM-generated payloads.

We didn't just build an adapter. We built security infrastructure. ToolGuard is now officially the execution-layer firewall for the intelligence boom.

Repository: https://github.com/Harshit-J004/toolguard
Documentation: https://github.com/Harshit-J004/toolguard#readme
Install: pip install py-toolguard

---

This discussion was created from the release The "Cloudflare for AI Agents" Is Here (MCP Security Proxy).

[polterguy]

An MCP security proxy is compelling because it shifts the problem toward mediation instead of assuming safer prompts will be enough.

That architectural move matters a lot. Once a separate layer can inspect, constrain, and deny risky actions, the whole system becomes easier to reason about. If anyone wants to dig into similar ideas, feel free to click my profile avatar.

[Harshit-J004]

Heyy... exactly this. Relying purely on prompt engineering or hoping the model's system prompt "holds" against injection is actually a losing battle when destructive backend tools are on the line. Mediation at the transport layer forces deterministic safety onto non-deterministic models.

Really appreciate the insight! We actually just pushed v6.1.0 today, which takes this mediation architecture a step further. We decoupled it into a universal HTTP sidecar and added Redis distributed state, meaning you can now mediate large, multi-language agent swarms across a Kubernetes cluster without state collisions.

I'd absolutely love for you to take it for a spin. If you run into any issues or have ideas for the mediation pipeline, please feel free to reach out ( heerj4477@gmail.com ) or open an issue right here on GitHub!

Will definitely check out the work on your profile as well. Thank you so much for dropping by!!

[polterguy]

Yeah, my approach is to allow for whitelisting individual keywords, restricting the agent on the function invocation level. Good luck to you :)