MCP Security Tools Compared

What they do well. API gateways such as Kong, Envoy, Apigee, and the open source MCP proxies that have appeared around the Model Context Protocol ecosystem are excellent at the transport-layer problems they were designed for: terminating TLS, validating OAuth tokens and mTLS certificates, applying coarse rate limits per API key, routing traffic to upstream services, and exposing consistent metrics. They are the backbone of any modern service mesh and they solve a real set of problems very well.

The blind spot. Gateways operate at the request envelope. They see that agent support-bot-42 called the database.query tool, that the request was authenticated, and that the rate limit budget was not exceeded. What they do not see is whether the SQL string inside that call targets the current tenant or the entire customer table. They cannot tell whether a files.read invocation asks for /tmp/report.csv or /etc/shadow. That level of parameter semantics is simply outside the gateway's job.

When to use it alongside INS. Always. A gateway is the right place for authentication, TLS termination, and tenant-level rate limiting. INS sits behind (or inside) your gateway and adds the parameter-aware layer the gateway is not built to provide. If you are weighing a pure proxy against INS, read our deeper breakdown in MCP Proxy vs API Gateway.

What they do well. Web application firewalls, whether commercial (Cloudflare, AWS WAF, Akamai) or open source like ModSecurity with the OWASP Core Rule Set, are the workhorse defense against web-scale attacks. They detect SQL injection syntax, cross-site scripting payloads, path traversal, known CVE fingerprints, and abusive crawlers. Decades of signature tuning make them very good at catching the attacks that made web apps bleed through the 2000s and 2010s.

The blind spot. WAF rules are pattern matchers. They answer the question "does this request look malicious?", not "will this request do something malicious?" An agent asked to fetch customer 42's address produces a perfectly valid SQL query. An agent prompt-injected to dump the customer table produces a perfectly valid SQL query too. Both pass any signature check you care to write. The OWASP CRS cannot flag a query that is syntactically clean, semantically boring, and contextually disastrous. WAFs were built for adversarial humans smuggling syntax past input validation. They were not built for AI agents composing legitimate operations with misaligned intent.

When to use it alongside INS. If your MCP servers sit behind public HTTP endpoints, a WAF still earns its place against opportunistic bot traffic, vulnerability scanners, and classic injection attempts. Pair it with INS so the parameters the WAF lets through are also evaluated for their semantic effect at the invocation layer.

What they do well. Data loss prevention suites from Symantec, Forcepoint, Microsoft Purview, and open source pattern libraries scan egress channels for structured sensitive data: credit card numbers, social security numbers, PHI identifiers, internal classifications. They excel at watching email gateways, file shares, USB transfers, and cloud storage uploads for exactly the patterns compliance teams care about.

The blind spot. DLP is a perimeter control, not a context control. It sees an outbound blob and decides "this contains a credit card pattern, block it." That model assumes the sensitive data is visible in the exfiltration step. AI agents break the assumption. An agent can read a row with customers.lookup, paraphrase it into prose in its own reasoning, call support_ticket.create to open a ticket with that prose as the description, and ship the data to an external support vendor — and no DLP signature fires, because by the time the data crosses the perimeter it no longer matches any regex. DLP also cannot tell that the data should not have been read at all, because the read happened inside the agent's normal tool session, not on the egress channel DLP is watching.

When to use it alongside INS. Keep DLP on your email, file sharing, and cloud storage channels — those are still the exfiltration paths for your human users. Let INS cover the agent-to-tool channel where DLP has no visibility. See Data Exfiltration via AI Agents for concrete scenarios.

What they do well. Role-based and attribute-based access control are the foundation of almost every enterprise authorization story. They let you declare, up front, that role X may call capability Y when attribute Z holds — and then enforce that statement uniformly. NIST SP 800-162 formalized ABAC as the path toward fine-grained, policy-driven authorization. When modeled well, RBAC is auditable, predictable, and stable.

The blind spot. RBAC and ABAC grant access to capabilities. An agent either can call database.query or it cannot. Once it can, every query is allowed — including the one that joins five tables no agent should ever touch in the same statement. You can get closer with ABAC by adding attributes like tenant_id or time_of_day, but the moment the condition depends on the contents of the request parameters — the actual SQL, the actual file path, the actual prompt string the agent is about to send to another LLM — you are no longer writing access policy. You are writing code. RBAC was not built to evaluate the internal structure of individual invocations, and stretching it to do so produces policy sets that nobody can audit.

When to use it alongside INS. Keep RBAC/ABAC for the coarse layer: which agents exist, which tool categories they are allowed to touch, which tenants they belong to. Let INS enforce the per-invocation layer with policies that understand parameter content. Our Policy Engine pairs naturally with your existing RBAC.

What they do well. User and entity behavior analytics platforms such as Splunk UBA, Exabeam, and Microsoft Defender for Identity build statistical profiles of every user and service account, then flag deviations: a login from a new country, a sudden spike in file access, a process spawning an unusual child. Against insider threats and compromised credentials they have earned their place in the SOC.

The blind spot. UEBA is a cold-start problem. A useful baseline takes weeks of history, because that is how long it takes a statistical model to distinguish signal from normal noise. When you deploy a new agent, the UEBA layer is effectively blind for the entire bake-in period. Worse, agents are designed to be unpredictable: the same prompt produces different tool call sequences depending on the model's sampling temperature, the upstream context, and what happened two turns ago. What "normal" means for an agent drifts faster than UEBA models can retrain. The practical effect is that UEBA either alerts constantly (and becomes noise) or tolerates a huge radius of deviation (and misses the attack).

When to use it alongside INS. UEBA still has value on the human side of your enterprise — the analysts, engineers, and service accounts that exist for years and drift slowly. For agents, INS provides the day-zero coverage UEBA cannot, by evaluating each invocation against deterministic policies and content-based detectors rather than statistical baselines.