- MCP is an authorization surface, not just a developer convenience: tool descriptions, server trust, and token scope are security controls that currently have no clear owner in most organizations.
- The four attack classes that matter most are tool poisoning, rug pulls, confused deputy attacks, and token passthrough. Each has a distinct detection signal and a distinct enforcement point.
- An MCP gateway and an API gateway solve different problems. An API gateway enforces HTTP-level access control; an MCP gateway understands tool call semantics, schema validation, and prompt-layer manipulation.
- The right enforcement architecture depends on one question: does your team need to inspect tool call content, or only gate which tools an agent can reach? The answer determines whether you need a gateway, a proxy, or a registry with policy enforcement.
- Most teams should run a two-week pilot against their existing MCP servers before committing to a full platform. The operational cost of tuning a misconfigured gateway mid-deployment is significantly higher than the cost of piloting first.
The best MCP security tools for most enterprise teams fall into three categories: inline gateways that inspect and enforce tool call semantics (such as gateway-layer enforcement tools), policy-as-code registries that control which servers agents can reach, and runtime monitors that detect anomalous tool invocation patterns. The right choice depends on whether your threat model centers on data exfiltration via token passthrough, prompt-layer manipulation through tool descriptions, or unauthorized lateral movement across agent-accessible services.
Why MCP Security Is an Authorization Problem, Not a Developer Problem
Most security teams first encounter the Model Context Protocol when a platform engineer mentions it in a sprint review. It sounds like plumbing. It is not. MCP defines how an AI agent discovers and calls external tools, which means it defines what the agent can do, to what systems, with what credentials. That is an authorization surface by any reasonable definition.
The confusion about ownership is understandable. MCP servers are typically built and operated by platform or AI engineering teams. The security controls that matter most, token scope, server trust, tool description integrity, live inside a protocol that most security engineers have not yet read. The result is a gap: platform teams assume security has reviewed it, security teams assume platform owns it, and neither team has mapped the full blast radius of a compromised MCP server.
A single MCP server with access to a code repository, a cloud provider API, and an internal ticketing system represents a lateral movement path that would require three separate compromises to achieve through traditional means. An attacker who controls one tool description controls the agent’s behavior across all three. That is the risk, stated plainly.
What Are the Actual Attack Classes Against MCP Servers?
Tool poisoning is the most documented attack class. A malicious or compromised MCP server returns a tool description containing hidden instructions that manipulate the LLM’s behavior independent of the user’s intent. Because most agents render tool descriptions as trusted context, the injected instruction runs without any visible signal to the user or operator. Detection: diff tool descriptions across sessions and alert on schema changes outside a deployment window. Mitigation: treat tool descriptions as untrusted input and validate them against a signed schema registry before the agent processes them.
Rug pulls are a temporal variant of tool poisoning. A server initially returns a benign tool description, passes any static review, and then returns a different description after trust has been established. The MCP specification does not require tool descriptions to remain stable across invocations. Detection: hash and log tool descriptions on every call, not just at registration. Mitigation: require cryptographic signing of tool manifests and reject unsigned or changed descriptions at the gateway layer.
Confused deputy attacks occur when an agent with broad tool access is manipulated by content from one system to perform actions in another. A classic scenario: an agent reads a support ticket containing injected instructions that tell it to query a billing API the agent legitimately has access to but the ticket author does not. The agent is the deputy; it holds permissions the attacker cannot exercise directly. Detection: correlate tool call context with the originating input source. If a tool invocation targeting a sensitive system was triggered by externally-sourced content, flag it. Mitigation: implement input source tagging and restrict which tool categories can be invoked from external content contexts. OWASP’s LLM Top 10 covers prompt injection and indirect prompt injection in detail.
Token passthrough is the quietest of the four. Many MCP server implementations forward the agent’s bearer token or API key directly to downstream services without scoping or expiry controls. An attacker who can observe or intercept that token, through a compromised tool server or a logging misconfiguration, gains the full permissions of the agent’s identity across every downstream service that accepts that credential. Detection: audit token usage patterns for calls originating from agent infrastructure outside expected invocation windows. Mitigation: require MCP servers to exchange short-lived, scoped tokens per tool call rather than forwarding long-lived credentials.
The SecurityOpsWire MCP Trust Boundary Test
Before evaluating any tool in this list, run the SecurityOpsWire MCP Trust Boundary Test against your current deployment. It has four questions.
- Can you enumerate every MCP server your agents can reach? If the answer requires asking the platform team, you do not have a registry. You have shadow tooling.
- Are tool descriptions logged and hashed on every invocation? If you only log at registration, rug pulls are invisible to you.
- Do your agents use long-lived tokens or credentials shared across tool calls? Yes means token passthrough is exploitable today.
- Is there a policy that restricts which tools can be called based on the context that triggered the call? If not, confused deputy is architecturally unmitigated.
A team that answers yes to all four does not need a full gateway immediately. A team that answers no to two or more should treat MCP security as an open critical gap, not a roadmap item.
Do I Need an MCP Gateway If I Already Run an API Gateway?
An API gateway operates at the HTTP layer. It enforces authentication, rate limiting, and route-level access control. It cannot inspect the semantic content of a tool description, validate whether a tool schema has changed, or enforce policy based on the AI agent’s behavioral context.
An MCP gateway sits between the agent runtime and the tool servers and understands the MCP protocol semantics: tool registration, schema validation, call routing, and description integrity. It can enforce policy at the tool-call level, not just the HTTP-request level. The two tools are not substitutes. If your API gateway is terminating TLS and enforcing auth, that is still necessary. An MCP gateway adds a layer that understands what the agent is doing, not just what HTTP request it sent.
The practical question is whether your current deployment justifies the operational overhead of a dedicated MCP gateway. For a team running fewer than five MCP servers with a single agent type and no external data inputs feeding those agents, a signed schema registry with change detection may be sufficient. For a team running multi-agent workflows where agents can call other agents, a gateway with semantic inspection is worth the deployment cost.
12 MCP Security Tools: What Each One Actually Does
A note on scope: several popular lists conflate two categories. Some articles describe MCP servers that run security tools, meaning an AI agent can call Nmap or Snyk through MCP. This article covers the other direction: tools that protect MCP deployments from attack. If you found this looking for AI-accessible security tooling, the Snyk and GitHub awesome-list results in search are what you want. This list is about securing the protocol itself.
| Tool | Enforcement Type | Primary Attack Class Addressed | Deployment Model | Pricing |
|---|---|---|---|---|
| Straiker | Inline gateway | Tool poisoning, token passthrough | SaaS / self-hosted | Not publicly disclosed |
| Microsoft MCP Gateway | Inline gateway | Auth, routing, server registry | Azure-hosted | Not publicly disclosed |
| Invariant Labs Guardrails | Runtime monitor | Rug pulls, confused deputy | Self-hosted / cloud | Not publicly disclosed |
| Anthropic’s MCP Inspector | Schema validation tool | Tool poisoning (static analysis) | CLI / developer | Open source |
| Zuplo MCP Gateway | Inline proxy / gateway | Auth, rate limiting, routing | SaaS / cloud-native | Not publicly disclosed |
| Proofpoint AI Security | Data loss prevention + monitoring | Token passthrough, data exfil | SaaS | Not publicly disclosed |
| Wiz AI-SPM | Posture management / CSPM extension | Misconfigured MCP server exposure | SaaS (agentless) | Not publicly disclosed |
| Permit.io | Policy-as-code authorization | Confused deputy, privilege drift | SaaS / self-hosted | Free tier available; paid tiers not publicly disclosed |
| mcp-manager (open source) | Server registry + lifecycle | Shadow tooling, unmanaged servers | Self-hosted | Open source |
| LangSmith (LangChain) | Trace logging and audit | Rug pulls (post-hoc detection) | SaaS / self-hosted | Free tier; paid tiers not publicly disclosed |
| Portkey AI Gateway | Inline proxy with observability | Token passthrough, audit logging | SaaS / self-hosted | Free tier; paid tiers not publicly disclosed |
| Pangea Security | Modular security API layer | Tool poisoning, authz, audit | SaaS API | Free tier available; paid tiers not publicly disclosed |
Straiker
Straiker sits inline between the agent runtime and MCP tool servers, inspecting tool calls for anomalous patterns including schema drift and suspicious payload structures. Its architecture is designed specifically for agentic AI environments rather than adapted from general-purpose API security. Straiker addresses tool poisoning by validating tool descriptions against a registered baseline and alerting when descriptions change outside a defined policy window. Pricing is not publicly disclosed; contact for a quote based on agent count and tool call volume. Best fit for enterprise teams running multiple agent types across heterogeneous MCP servers who need a purpose-built enforcement layer rather than a generalist proxy.
Microsoft MCP Gateway
The microsoft/mcp-gateway project is an open-source reference implementation hosted on GitHub. It provides routing, authentication enforcement, and server registry capabilities for MCP deployments. The primary value is standardizing how agents discover and authenticate to tool servers within Azure-hosted environments. It does not currently provide tool description hashing or behavioral analytics. Best fit for teams already running on Azure who need a governed discovery layer and are willing to build detection logic on top of the gateway’s logs. The open-source nature means no licensing cost but full operational ownership.
Invariant Labs Guardrails
Invariant Labs offers runtime guardrails for agentic systems, including MCP-aware monitoring that can detect deviations in agent behavior patterns. Its approach to rug pull detection is behavioral: it builds a baseline of expected tool call sequences and alerts when agent behavior diverges from the baseline in ways consistent with instruction injection. Deployment is either self-hosted or via their cloud offering. Pricing is not publicly disclosed. Best fit for teams with a detection engineer who can tune behavioral baselines, not a good fit for a team that needs a low-maintenance out-of-the-box policy engine.
Anthropic’s MCP Inspector
Anthropic’s MCP Inspector is a developer-facing CLI tool for testing and validating MCP server behavior. From a security perspective, its primary use is static inspection: you can use it to review tool descriptions, validate schema structures, and identify unexpected capabilities before a server reaches production. It does not provide runtime enforcement. It is open source and free. Best fit as a pre-deployment gate in a CI/CD pipeline, not as a runtime control. A team that pipes MCP Inspector output into a policy check before merging MCP server changes gets meaningful tool poisoning prevention at zero licensing cost.
Zuplo MCP Gateway
Zuplo offers an MCP gateway that handles authentication, rate limiting, and routing for MCP deployments. Its design inherits from API gateway patterns, making it familiar to teams who already manage API access control. The security value is primarily at the access control layer: who can reach which servers, under what rate limits, and with what authentication requirements. It does not natively inspect tool description content for manipulation. Pricing is not publicly disclosed. Best fit for teams whose primary concern is unauthorized server access rather than prompt-layer attacks, and who want a gateway that integrates naturally with existing API management workflows.
Proofpoint AI Security
Proofpoint’s AI Security offering extends its existing data loss prevention capabilities into AI agent interactions. For MCP deployments, the relevant capability is detecting and blocking sensitive data flowing through tool calls, particularly cases where an agent forwards credentials or regulated data to external tool servers. This addresses the token passthrough problem from the data-in-transit angle rather than the token-scoping angle. Pricing is not publicly disclosed and is typically bundled with existing Proofpoint licensing. Best fit for organizations already running Proofpoint for email and content security who want to extend that policy enforcement to agent-generated traffic without deploying a separate platform.
Wiz AI-SPM
Wiz’s AI Security Posture Management capability scans cloud environments for AI-related misconfigurations, including exposed MCP servers, overprivileged service accounts used by agent infrastructure, and unencrypted tool server endpoints. Its agentless architecture means no additional software deployment against existing MCP servers. It does not provide runtime enforcement or inline inspection; it is a posture and misconfiguration scanner. Pricing is not publicly disclosed. Best fit for cloud security teams who want visibility into where MCP servers exist in their environment and whether they are misconfigured, before investing in a runtime enforcement tool.
Permit.io
Permit.io provides policy-as-code authorization that can be integrated into MCP server implementations to enforce fine-grained access control on tool invocations. Its relevance to confused deputy mitigation is direct: you can write policies that restrict which tools a given agent identity can invoke based on the context of the request, not just the identity of the caller. A free tier is available as of mid-2025; paid tier pricing is not publicly disclosed. Best fit for teams building or controlling their own MCP server implementations who want to add authorization logic without writing custom middleware.
mcp-manager (open source)
Several open-source mcp-manager implementations exist on GitHub for managing MCP server lifecycles. The security value is registry-level: these tools let platform teams maintain an authoritative list of approved MCP servers, their versions, and their access policies. Without a managed registry, agents can connect to any server they are pointed at, which is the shadow tooling problem. Best fit as a foundational control for teams early in their MCP security program. Operational cost is low, but the tool provides no runtime inspection. Pair it with a schema validation step and a logging layer for meaningful coverage.
LangSmith
LangSmith from LangChain provides trace logging and observability for LLM applications, including those using MCP for tool calls. From a security standpoint, its primary value is post-hoc detection: you can query traces to identify sessions where tool descriptions changed, where unexpected tool calls occurred, or where agent behavior deviated from expected patterns. A free tier is available; paid tier pricing is not publicly disclosed. Best fit for teams using LangChain or LangGraph for their agent infrastructure who want security-relevant logging without deploying a separate observability stack. Not a runtime enforcement tool.
Portkey AI Gateway
Portkey is an AI gateway that proxies requests from agent infrastructure to LLM providers and tool servers. Its security-relevant capabilities include audit logging of tool calls, basic access control, and anomaly flagging. Token passthrough mitigation is partial: Portkey can log credential usage patterns but does not re-scope tokens per call. A free tier is available; paid tier pricing is not publicly disclosed. Best fit for teams that want a single observability and access control layer across both LLM API calls and MCP tool invocations without running two separate proxies.
Pangea Security
Pangea offers a modular security API platform that developers can integrate into MCP server implementations. Relevant modules include audit logging, authorization, and input redaction for tool call payloads. For tool poisoning prevention, the input redaction API can sanitize tool description content before it reaches the agent. A free tier is available; paid tier pricing is not publicly disclosed. Best fit for development teams building MCP servers from scratch who want to add security controls as API calls rather than managing a separate security infrastructure layer.
Which Enforcement Architecture Fits Your Team?
Consider a mid-size SaaS company with two security engineers, a platform team of eight, and a growing set of AI agent workflows. Their agents connect to five MCP servers: one for their internal knowledge base, one for their ticketing system, one for their cloud infrastructure API, one for a third-party SaaS CRM, and one for a code repository. Their agents use a shared service account token passed through every tool call. They have no MCP-specific logging today.
For that team, the priority sequence is: first, fix the token passthrough by requiring per-call scoped tokens, which is a server-side change their platform team owns. Second, deploy a registry that inventories all five servers and blocks unregistered servers at the network level. Third, add trace logging through LangSmith or Portkey to get visibility into tool call patterns. Fourth, and only after the first three are stable, evaluate whether an inline gateway with semantic inspection is worth the additional tuning overhead. A full inline gateway dropped into a misconfigured environment creates more noise than signal.
Larger organizations with dedicated detection engineering and more than ten MCP servers should invert that sequence. The inline gateway gives you the enforcement surface you need before you have visibility. The trade-off is tuning overhead in weeks two through four of deployment.
What Does MCP Security Cost to Run at Scale?
Most of the tools in this list do not publish pricing. That is a consistent pattern in the AI security segment as of mid-2025: vendors are still mapping out how customers price and consume these tools, and most quotes are per-environment or per-agent-count rather than per-seat. The practical advice is to ask for quotes anchored on two variables: number of agent invocations per day and number of distinct MCP servers in scope.
The open-source options, Microsoft MCP Gateway, Anthropic’s MCP Inspector, and open-source mcp-manager implementations, have zero licensing cost but non-zero operational cost. A team that deploys the Microsoft MCP Gateway without a dedicated engineer to manage routing policies and monitor logs will find the tool becomes shelfware within a quarter. The honest per-year cost of an open-source gateway includes engineering time for initial configuration, ongoing policy tuning, and incident response when the gateway misroutes a call. For most teams that cost runs between 20 and 40 hours per month of a senior engineer’s time in steady state.
For tools with free tiers, LangSmith, Portkey, Permit.io, and Pangea all offer meaningful free usage. Starting with one of those for logging and registry enforcement before purchasing a dedicated MCP gateway is a reasonable pilot strategy. It gives you the data you need to justify a gateway purchase and to configure it correctly when you do deploy.
Frequently Asked Questions
Are MCP servers secure by default?
No. The MCP specification defines the protocol but does not mandate authentication, tool description signing, or token scoping. Security properties depend entirely on how each server is implemented and deployed. A default MCP server with no additional security controls is an unauthenticated tool execution endpoint. Server authors and operators are responsible for adding authentication and authorization on top of the base protocol.
What is the difference between an MCP gateway and an LLM gateway?
An LLM gateway sits between an application and an LLM provider API, handling routing, rate limiting, and prompt filtering at the model-call level. An MCP gateway sits between an agent runtime and tool servers, enforcing policy at the tool-invocation level. They operate at different layers of the AI application stack. Some tools, like Portkey, attempt to cover both layers from a single proxy, with trade-offs in depth of inspection at each layer.
What is a rug pull attack in MCP context?
A rug pull is when an MCP server returns a benign tool description during initial registration or review and then returns a different, malicious description during live operation. Because the MCP protocol does not require description stability, an agent that verified a tool at registration time may receive different instructions at runtime. The mitigation is hashing and logging tool descriptions on every invocation, not just at registration, and rejecting calls where the live description does not match the registered hash.
What is a confused deputy attack in MCP?
A confused deputy attack occurs when an agent with legitimate access to multiple systems is manipulated by input from one system to perform unauthorized actions in another. The agent acts as the “deputy” and holds permissions the attacker cannot exercise directly. In MCP deployments, this typically appears as injected instructions inside externally-sourced data, such as a document or email, that direct the agent to invoke sensitive tools. Mitigation involves tagging input sources and restricting which tool categories can be invoked from external content contexts.
How does token passthrough create risk in MCP deployments?
Many MCP servers forward the calling agent’s credentials directly to downstream services without scoping or expiry controls. If an attacker can intercept those credentials, through a compromised tool server, a logging misconfiguration, or a network-level attack, they gain the full permissions of the agent’s identity across every downstream service. Mitigation requires requiring MCP servers to exchange short-lived, scoped tokens per tool call, rather than forwarding the agent’s long-lived bearer token.
Do I need an MCP-specific security tool or can I use an existing API gateway?
An existing API gateway handles HTTP-level authentication, rate limiting, and routing but cannot inspect tool description content, detect schema drift, or enforce policy based on AI agent behavioral context. For teams whose primary concern is controlling which servers agents can reach and enforcing authentication, an API gateway extended with MCP routing rules may be sufficient. For teams whose threat model includes tool poisoning and rug pulls, an MCP-aware gateway or runtime monitor is necessary because those attacks operate at the semantic layer, not the transport layer.
What MITRE ATT&CK techniques map to MCP attack classes?
Tool poisoning and rug pull attacks map most closely to Supply Chain Compromise (T1195) and Command and Scripting Interpreter (T1059) for the execution phase. Confused deputy attacks align with Abuse Elevation Control Mechanism (T1548). Token passthrough maps to Steal Application Access Token (T1528). These mappings are directional; the MITRE ATT&CK framework does not yet have MCP-specific technique IDs as of mid-2025.
Which of these tools works without modifying the MCP servers themselves?
Inline gateways and proxies, including Microsoft MCP Gateway, Zuplo, Straiker, and Portkey, operate without requiring changes to existing MCP server implementations. They intercept traffic at the network layer. Tools that require server-side integration, such as Permit.io and Pangea, need development effort on the MCP server itself. Wiz AI-SPM and LangSmith require no server changes but provide posture visibility and trace logging rather than enforcement. Choosing a server-agnostic gateway is practical for teams that do not control all of their MCP server codebases.
What the Right Enforcement Point Actually Looks Like
The goal of this article was to reframe MCP from a developer integration detail into an authorization surface. If you ran the SecurityOpsWire MCP Trust Boundary Test and found gaps, the tool category you need is determined by which gap is most severe. Token passthrough is a server-side fix first and a monitoring problem second. Shadow tooling is a registry problem. Tool poisoning and rug pulls require either an inline gateway with schema enforcement or a CI/CD gate with static inspection, depending on your deployment model. Confused deputy requires input-source tagging at the application layer, which no gateway can fully substitute for.
Pick one enforcement point, the tool in this list that closes your most critical gap, and pilot it against your existing MCP servers for two weeks before expanding scope. The teams that struggle with MCP security tooling almost always bought a full platform before they understood their own tool topology. The teams that succeed mapped their servers first, identified their dominant attack surface, and chose an enforcement point that matched it.
MCP security is new enough that the tools are still maturing and the category definitions are still shifting. What will not change is the underlying authorization logic: any system where one agent identity can reach multiple sensitive services through a shared credential is a system that needs explicit ownership of that trust boundary. Owning that boundary is a security decision, and it should be made by the security team, not inherited from the platform roadmap.
