QuilrAI
Back to Resources
Research

Why Your Firewall Doesn't Speak MCP

Traditional security tools were built for HTTP and humans. MCP, tool calls, and agent delegation chains speak a different language, one they can't parse.

5 min read
February 2026

Enterprise security infrastructure, firewalls, WAFs, DLP systems, SIEM, was designed around two assumptions: that traffic is HTTP, and that the intent behind a request can be inferred from its structure. Both assumptions fail spectacularly when applied to Model Context Protocol traffic. MCP is JSON-RPC transported over stdio or Server-Sent Events, carrying semantically rich tool schemas that describe what an AI can do rather than what it is currently doing. A packet inspector has no way to distinguish a legitimate database query tool call from one that is about to exfiltrate your customer records.

What Is the JSON-RPC Problem?

Traditional network security tools pattern-match against known attack signatures in HTTP headers, URL paths, and request bodies. MCP traffic arrives as a stream of JSON objects over a long-lived connection, often over stdio to a local process, bypassing the network entirely. Even when MCP runs over HTTP, the payload is a generic JSON-RPC envelope. The tool name, arguments, and schema are nested inside the payload in a format that existing WAF rules were never written to parse.

Why Do Tool Schema Semantics Require a New Security Layer?

The real challenge is semantic: understanding whether a specific tool call is dangerous requires knowing what that tool does, what the model intended to accomplish, and whether the combination of tool + arguments + current agent state constitutes a policy violation. This is not a job for a stateless packet filter. It requires a context-aware proxy that has parsed the tool schema, tracked the agent's current task, and evaluated the call against a semantic security policy.

What Is the Semantic-Aware Proxy Pattern?

A semantic-aware MCP proxy sits between the agent and the MCP server, intercepting every tool call and tool result. It maintains a session context, which tools are registered, what the agent has already done, and what permissions it was granted for this task. Each tool call is evaluated against a policy engine that understands the tool's declared capabilities and compares the actual arguments against the expected safe range. Calls that violate policy are blocked and logged before they ever reach the MCP server.

QuilrAI

How QuilrAI addresses this: The QuilrAI MCP Gateway is a semantic-aware proxy that parses tool schemas at registration time, tracks agent task context across a session, and evaluates every tool call against a configurable policy engine, blocking violations before they reach the MCP server, with full audit logging.

Related Articles

Dig deeper

Secure your AI stack today

See how QuilrAI's Guardian Agent and LLM Gateway protect your AI deployment from the threats covered in this article.

Get a Demo