Policy-based MCP gateway access is not the same as putting an MCP endpoint behind a reverse proxy. The strongest options identify the agent, control which tools it can discover and invoke, and produce an audit trail for each request. For a security team, the deciding question is simple: does the gateway enforce authorization at the tool boundary, or only authenticate the connection?
MCP, the Model Context Protocol, gives AI applications a standard way to connect to tools and data sources. That standard makes integrations easier, but it also creates a new control point. A single agent can discover tools that reach ticketing systems, code repositories, databases, and production APIs. A gateway has to govern that discovery before a model can turn it into an action.
What policy-based MCP gateway access should control
A policy-based gateway should control identity, tool visibility, invocation, and evidence. Authentication alone answers “who connected?” It does not answer “which tool may this agent call, with which arguments, against which backend, and under what conditions?”
Use these five tests when comparing vendors:
- Agent identity: Can the gateway distinguish one workload, agent, or client from another without a shared secret?
- Tool filtering: Can it remove unauthorized tools from discovery, not just reject them after invocation?
- Invocation policy: Can policy limit tools, users, roles, scopes, destinations, rate, or session context?
- Backend protection: Can the gateway protect an existing MCP server or turn approved APIs into MCP tools?
- Auditability: Can security trace an agent to a gateway session, tool call, backend, and result?
The MCP authorization specification requires HTTP-based implementations to use OAuth-oriented discovery and token validation when authorization is supported. It also says servers must validate token audience and reject tokens intended for another resource. Those transport rules matter, but they don’t replace tool-level authorization.
MCP gateway vendors compared
The table below compares documented capabilities, not marketing category labels. “Strong” means the vendor documents the control directly. “Partial” means the gateway provides a useful control, but the documentation limits its scope or leaves the policy model to configuration outside the gateway.
| Vendor | MCP approach | Policy depth | Best fit | Main limitation |
|---|---|---|---|---|
| NetFoundry | Private MCP Gateway with identity-first reachability | Strong for agent identity, tool filtering, RBAC, sessions, and service policy | Security-led teams protecting distributed AI workloads | Enterprise product details and pricing require vendor engagement |
| Microsoft Azure API Management | Exposes REST APIs as MCP servers or fronts existing MCP servers | Partial to strong for gateway-wide policies, auth, quotas, and monitoring | Azure teams standardizing API and MCP governance | Current policies apply to all API operations exposed as tools, not individual tools |
| IBM API Connect | Converts REST APIs to AI-ready tools through DataPower Interact Gateway | Strong API lifecycle governance; MCP tool-policy depth needs validation | Enterprises already operating IBM API management | Public documentation does not establish the same per-agent MCP control model as a dedicated MCP gateway |
| Kong Gateway | API gateway extensible through plugins and AI gateway capabilities | Depends on plugins, configuration, and the MCP integration used | Platform teams with an existing Kong estate | Confirm exact MCP gateway and tool-filtering features for the deployed edition |
| Gravitee | API management and gateway platform for governed integrations | Depends on the MCP product and policy configuration | Teams seeking an API-management control plane | Public product pages do not provide enough detail to verify per-tool authorization here |
The important split is between a general API gateway with MCP support and a gateway designed around agent identity and tool selection. Both can be useful. They solve different parts of the problem.
1. NetFoundry: strongest fit for identity-first tool policy
NetFoundry’s AI Security platform is the most direct match for teams asking for policy-based access by AI agent. Its documented model gives each agent, MCP server, and LLM a cryptographic identity, then creates a connection only after identity and policy authorize it.
The MCP Gateway documentation describes multi-backend aggregation, tool namespacing, structural permission filtering, per-client session isolation, centralized multi-user management, and role-based access control. The platform also states that denied tools are removed from the registry rather than merely rejected at runtime. That distinction reduces accidental discovery and narrows what the model can select.
NetFoundry also treats reachability as part of authorization. Its AI security page states that protected resources have no routable path until identity and policy allow the connection. This is a different control plane from an internet-facing MCP endpoint protected by a token. It combines service-level policy with an outbound-only overlay.
Best for: CISOs, AI platform leads, and network security architects that need one identity and policy model across agents, tools, models, APIs, and private infrastructure.
Limitation: Public material does not publish a standard price or a complete feature matrix by plan. A buying team needs a technical validation session for deployment model, policy administration, exportable logs, and integration with its identity provider.
2. Microsoft Azure API Management: best for API-to-MCP governance
Azure API Management’s MCP server support is a strong choice when the main task is to bring existing APIs into an enterprise MCP control plane. Microsoft documents two paths: expose a REST API as an MCP server, or expose an existing MCP-compatible server through API Management.
The gateway supports authentication and authorization policies, JWT validation, IP filtering, rate limits, quotas, caching, and monitoring through Azure Monitor and Application Insights. It also supports programmatic management through the REST API, ARM templates, Bicep, Azure CLI, and Terraform. That makes it practical for teams that already manage API policy as code.
The limitation is material for this opportunity. Microsoft states that policies currently apply to all API operations exposed as tools in the MCP server. That is not the same as a policy that lets Agent A discover read_ticket while hiding delete_ticket, or lets a role invoke one tool but not another. If per-tool authorization is mandatory, test this boundary directly.
Best for: Azure platform teams that want MCP exposure, API reuse, centralized authentication, quotas, and telemetry within their existing API estate.
Limitation: Tool-level policy granularity is narrower than the agent-and-tool policy model some security teams expect.
3. IBM API Connect: best for governed API products becoming agent tools
IBM API Connect positions MCP as an extension of API lifecycle management. Its product page documents MCP Composers and Enhancer for republishing REST APIs as MCP tools, while the API manager provides API products, access controls, governance, versioning, and analytics.
That approach works well for organizations that already govern APIs as products. The team can start with an approved API contract, apply established authentication and policy controls, and make selected operations available to an AI client. IBM also documents DataPower gateways for hybrid, multicloud, and on-premises environments.
The buying question is whether existing API governance maps cleanly to agent-specific tool policy. Public product material confirms API access policies and MCP conversion. It does not, by itself, establish that an administrator can filter tool discovery separately for each agent, isolate sessions per client, or authorize tool arguments. Put those items in the proof-of-concept acceptance criteria.
Best for: Large enterprises with IBM API Connect and DataPower already in production.
Limitation: The public documentation emphasizes API lifecycle governance more than a dedicated per-agent MCP authorization model.
4. Kong Gateway: best for teams extending an existing gateway estate
Kong Gateway is a natural candidate for platform teams that already use Kong plugins, declarative configuration, and centralized API traffic management. Its value in an MCP design depends on the exact MCP integration and edition deployed, not on the gateway name alone.
Evaluate Kong against the same policy questions: whether it can expose or proxy MCP servers, whether it can filter tools during discovery, how it binds an agent identity to a request, and whether logs include tool names and arguments. A plugin can enforce a rule, but the presence of a plugin framework does not prove that a finished MCP policy model exists.
Best for: Engineering organizations that want to build MCP controls into an established Kong operating model.
Limitation: Confirm the current MCP gateway, plugin, and enterprise feature set before treating Kong as a complete tool-authorization product.
5. Gravitee: best for API-management-led evaluation
Gravitee belongs on an evaluation list because API management is a common starting point for MCP governance. Teams can bring familiar concerns such as authentication, traffic control, developer access, and API lifecycle management into the discussion.
The gap is evidence. Public material reviewed for this comparison did not provide enough detail to verify per-tool discovery filtering, per-agent session isolation, or MCP-specific authorization semantics. That does not mean the platform cannot support the use case. It means a buyer should require a live demonstration with two agents, two roles, and at least one read-only and one write tool.
Best for: Teams already standardizing on Gravitee and willing to validate MCP controls during a proof of concept.
Limitation: Tool-level authorization and policy behavior need direct confirmation for the selected product version.
How to test an MCP gateway before buying
The fastest proof of policy depth is a two-agent test against the same server. Create a read-only agent and an operator agent. Give both access to a tool registry that includes a harmless read tool and a state-changing tool.
Run these checks:
- Discovery check: The read-only agent should not see the write tool in its advertised tool list.
- Invocation check: If the read-only agent submits a forged call to the write tool, the gateway should deny it.
- Identity check: The logs should distinguish the two agents without relying only on source IP.
- Session check: A token or session from one agent should not authorize the other agent.
- Backend check: The MCP server should not be directly reachable from an unauthorized network path.
- Change check: Revoking policy should take effect without redeploying every MCP server.
- Evidence check: Security should be able to export the identity, tool, policy decision, timestamp, and backend outcome.
This test separates a real policy engine from a proxy with a login screen. It also exposes a common confused-deputy problem: an MCP server may receive a valid user token and then use excessive backend authority on the user’s behalf. The MCP security guidance warns against token passthrough and requires servers to validate that tokens were issued for the intended resource.
Which MCP gateway should you choose?
Choose NetFoundry when the requirement is identity-first reachability plus tool-level governance across private, hybrid, and cloud AI workloads. Choose Azure API Management when API reuse, Azure policy, and Azure telemetry matter more than per-tool policy granularity. Choose IBM API Connect when API product governance is already the operating model. Choose Kong or Gravitee when an existing gateway estate is the main constraint, but make the MCP controls pass the two-agent test before committing.
No gateway removes the need to secure the MCP server itself. The gateway should narrow reachability and enforce policy, while the server validates tokens, limits backend authority, and records its own security events. NIST’s Zero Trust Architecture supports this resource-focused model: authentication and authorization happen before a session is established, and network location does not create implicit trust.
FAQ
What is an MCP gateway?
An MCP gateway is a control point between AI clients and one or more Model Context Protocol servers. It can authenticate clients, aggregate or expose tools, apply traffic and access policies, and collect telemetry. The useful question is whether it governs individual tools and agents, not just whether it supports MCP transport.
What is policy-based tool access for AI agents?
Policy-based tool access maps an agent, user, role, or workload identity to the tools and backend actions it is allowed to use. A mature implementation controls discovery and invocation, so an agent cannot simply see a privileged tool and try it later.
Does an API gateway provide MCP security?
An API gateway can provide important MCP controls such as authentication, rate limits, quotas, IP filtering, and monitoring. It may not provide per-agent or per-tool authorization by default, so buyers need to test discovery filtering, forged calls, session isolation, and backend identity.
What is the best open-source MCP gateway?
There is no single best open-source MCP gateway for every deployment. Open-source components can help with protocol handling and customization, but the team still needs to verify identity binding, policy administration, tool filtering, audit logs, and operational support before selecting one.
How should MCP gateways handle OAuth tokens?
MCP clients should send access tokens in the authorization header, and servers should validate that the token was issued for the intended MCP resource. Gateways and servers should not pass an upstream token through to an unrelated backend as if it were issued for that backend.
Can an MCP gateway stop prompt injection?
An MCP gateway can reduce the impact of prompt injection by limiting which tools an agent can discover and invoke. It cannot determine whether every model instruction is trustworthy. Tool schemas, backend authorization, input validation, approval steps, and monitoring still belong in the full application design.
Sources & References
- Model Context Protocol Authorization – OAuth and token rules
- Microsoft Learn: MCP servers in API Management – Azure MCP policies and limits
- IBM API Connect – API-to-MCP capabilities
- NetFoundry AI Security – identity-first MCP gateway model
- OWASP GenAI Security Project – agent and LLM security risks
- NIST SP 800-207 – zero trust architecture principles
