TL;DR — Key Takeaways
MCP gateway adoption is accelerating, but most deployments ship without the access controls enterprises need. The five most dangerous gaps are all-or-nothing tool permissions, no user scoping, silent vendor-side changes, fragmented policy across AI clients, and unfiltered sensitive data. A production-grade MCP gateway needs per-tool policy enforcement, IdP-driven identity, change management workflows, and a default-deny posture. Security teams should demand policy lifecycle management and code-based policy configuration — not just a UI form.
Why Are MCP Gateways Now a Security Problem?
Most enterprise AI deployments in 2026 have an MCP problem they haven’t fully diagnosed yet.
According to KPMG, by early 2026 the majority of enterprise AI initiatives include at least one MCP-connected tool. Analyst surveys put the share of enterprises with active agentic-AI pilots well above 80%. The protocol is spreading fast — but the security controls needed to govern it are not keeping pace.
Developers built MCP for developers. It solves a real problem: giving AI agents a standardized way to call tools, pull data, and take actions across enterprise systems. What it does not solve is the enterprise governance problem that follows. There are no native controls for limiting which users can reach which tools, no audit trail, no change notifications when a vendor updates their tool catalog, and no mechanism to stop sensitive data from flowing into a model’s context window.
Security teams are inheriting MCP deployments that were stood up by engineering and business teams optimizing for speed. The question is no longer whether to govern these deployments — it is how quickly you can get the right controls in place before something goes wrong.
A common question is: Why do MCP deployments create security risk if the underlying systems already have access controls?
The answer: The underlying system’s access controls determine whether a user can log in directly. They don’t govern what that user can do when an AI agent acts on their behalf through an MCP. An employee who has read-only Salesforce access can, through an agent, trigger any action the MCP exposes — including destructive ones — unless a separate MCP policy layer blocks it.
What Is an MCP Gateway?
Definition: An MCP gateway is a policy enforcement layer that sits between AI agents and the MCP servers they connect to. It intercepts every tool call, applies access control rules, enforces data protection policies, and logs the action — before the call reaches the downstream system.
An MCP gateway differs from a basic MCP server connection in one critical way: it does not pass tool calls through unchecked. Every request passes through a policy engine that can allow, deny, redact, or route the call based on who is making it, what tool they are calling, and what data the response contains.
Think of it as the difference between giving every employee a master key to every room in the building, versus issuing role-specific keycards with access logs and automatic revocation when someone leaves the company.
What Are the Real Security Risks in an MCP Deployment?
Most MCP security conversations stop at “the agent could do something bad.” That framing is too broad to be operationally useful. Security teams evaluating MCP security best practices need a more specific threat model — five distinct risk categories, each requiring a different control. These risks align with OWASP’s LLM Top 10, which flags insecure plugin design as one of the primary threats in agentic AI deployments.
Risk 1: The Authorization Gap — Why Does Every Tool Come On by Default?
When you enable an MCP server, every tool that server exposes becomes available to every agent or employee that can reach it. There is no native way to block a single destructive action — say, delete_repo on a GitHub MCP — while leaving the rest of the server enabled.
This matters because user permissions alone do not bound the blast radius in an MCP deployment. A single compromised or manipulated agent inherits the full tool surface of every MCP it can reach. Indirect prompt injection — where an attacker embeds instructions in content the agent reads (a Jira ticket, a support email, a webpage) — does not require new credentials. It just exercises the ones the agent already has.
The control you need: per-tool and per-action policy, not per-server toggles.
Risk 2: The User Permission Gap — Why Does Every User Have Access to Every MCP?
To use a system through an MCP, a user needs a valid login to that underlying system — if you can’t access Salesforce directly, you can’t access it through an MCP either. The problem is what happens when you can.
When an MCP is enabled, the agent inherits whatever permissions that user already has. There is no separation between what a person can do as a human and what an AI agent can do on their behalf. That matters because humans and AI agents make mistakes differently. A misunderstood instruction or a prompt injection can trigger a deletion or an unintended update before anyone catches it. The user didn’t intend the outcome. No policy stopped it.
This applies whether the AI is Claude, ChatGPT, or an internal agent. Once an MCP is enabled, every user whose credentials can reach that system can use it through AI with no native way to limit access by user, role, or team.
OAuth and your IdP govern whether someone can authenticate. They do not govern whether an AI agent should be allowed to act on that person’s behalf.
The control you need: per-user and per-group MCP scoping, driven by your enterprise IdP.
Risk 3: Silent Vendor-Side Changes — What Happens When Your MCP Vendor Ships a New Tool Without Telling You?
Vendor-hosted servers are the fastest-growing deployment pattern in MCP — the SaaS companies you already use ship and operate the MCP for their own products. That is convenient, but it creates a supply-chain risk most governance programs have not caught up to.
When a vendor ships a new tool, deprecates an existing one, or — most critically — adds a new destructive action like delete_all_records or send_email_as_user, your agents inherit it the moment the update deploys. No change notification.
Your last risk assessment is stale the moment the vendor pushes a release. For regulated industries, this is also an audit problem: your governance program assumes you have reviewed every privileged action your agents can take, but the hosted MCP model breaks that assumption continuously.
The control you need: change detection on hosted MCP tool catalogs, with new and modified tools off by default until explicitly reviewed and approved — least privilege by design.
Risk 4: Fragmented Policy Across AI Clients — Why Do the Same Users Get Different MCP Rules Depending on Which AI They Use?
Most enterprises in 2026 are not running one AI client. Engineering teams use Cursor and Claude Code. Analysts use Claude or ChatGPT. Product teams build internal agents. Each client maintains its own settings for which MCPs are enabled, which credentials are in use, and who has access.
The result: the same user, with the same identity, gets a different MCP policy depending on which tool they opened this morning. Security teams end up maintaining separate policy sets across multiple clients, with no unified audit log and no single place to revoke access when an incident occurs.
The control you need: a centralized control plane for access, policy enforcement, and audit logging — consistent across every AI client, every user, every tool.
Risk 5: Sensitive Data Exposure — What Stops PII and Regulated Data From Flowing Into the Model?
MCP servers have no native filtering, redaction, or classification layer between the source system and the model. When an agent calls a tool and gets a response, that response — including any PII, PHI, PCI data, or credentials it contains — flows directly into the model’s context window.
The underlying system’s DLP controls may flag the same data if accessed directly. Through an MCP, those controls are bypassed unless an explicit policy layer sits between the tool response and the model.
The control you need: a data protection policy engine that intercepts tool responses, classifies sensitive fields, and applies transformations — mask, redact, tokenize, omit — before the data reaches the model.
What Should Security Teams Require From an MCP Gateway?
This is where MCP security best practices get concrete. The following requirements are not aspirational, they are the minimum bar for a production-grade deployment. Treat any vendor that cannot demonstrate all of them as not yet enterprise-ready.
Your existing enterprise IdP (Okta, Entra, or any SAML/OIDC-compliant provider) must drive identity and authentication. Identity should flow end-to-end from the AI client through the MCP gateway to the downstream tool. Shared service-account credentials are not acceptable; each call must attribute to the actual user who initiated it. When a user leaves and your IdP removes them, their MCP access stops automatically.
Access control must operate at the tool level, not the server level. This means the ability to block, gate, or restrict individual actions — including destructive ones — while leaving the rest of the server available. Access control should support both role-based (RBAC) and attribute-based (ABAC) models, with IdP group membership as a first-class attribute. Policy should be expressible as code (JSON, YAML, or a policy language), not only through a UI form, so it can be version-controlled and reviewed in existing security workflows.
Policy enforcement must be real-time and pre-execution. A gateway that logs what happened after the fact is better than no gateway, but it is not an MCP security solution. Enforcement needs to happen before the tool call reaches the downstream system, with multi-dimensional scoping: per tool, per user, per agent, per server, and per action.
Change management requires a catalog of approved MCP servers and tools, with change detection that flags any modification to a tool’s definition — new tool added, description changed, schema changed. Any detected change sets the tool to denied by default until an admin explicitly reviews and re-enables it.
Data protection requires a policy engine that sits in the gateway path, with coverage for PII, PHI, PCI, source code, and secrets. The same rules should apply to both MCP tool responses and direct LLM prompts and completions — operating at a unified control plane, not two separate policy systems.
Audit logging must include full attribution: user, agent, tool, server, timestamp, policy decision, and the basis for that decision — on every call. Logs should be tamper-proof and exportable to your SIEM.
What Does Good MCP Security Look Like in Practice?
A mature MCP gateway deployment looks like this in practice for end users.
A sales analyst opens Claude and asks it to pull a customer account summary from Salesforce. The MCP gateway intercepts the tool call and confirms the user’s IdP group membership. It checks the specific tool against the user’s role policy. It redacts credit card numbers from the response. It logs the full call with attribution. The analyst gets a useful answer. The sensitive fields never reach the model. The call is in the audit log.
Now consider what a staged rollout looks like. A security team wants to pilot a new GitHub MCP with senior engineers before opening it to the broader engineering organization. The gateway scopes the MCP to an IdP group — engineering-senior — and blocks it for all other users. Two weeks later, the rollout is ready. One policy change, applied once, in one place, propagates to every AI client in the organization.
MCP security best practices deliver predictable enforcement, clean audit trails, and policy changes that propagate once across every AI tool in the stack — no replication required.
Barndoor MCP Governance builds on this operational model. The policy engine enforces at the tool and action level, pulls identity from your IdP, applies data protection transformations inline, and holds any vendor-side tool changes in a pre-approval catalog until a security team member reviews them. Policies live in code and move through a full lifecycle: draft → active → inactive → archived.
How Should You Evaluate MCP Gateway Vendors?
When running demos and POCs, the following questions consistently separate mature platforms from early-stage tools.
Ask about default posture. What happens before the first policy is created? A default-allow platform permits every tool call until someone writes an explicit deny. A default-deny platform blocks everything until an admin explicitly grants access
Set up a test environment with no policies and attempt a tool call. The result tells you more about a vendor’s security philosophy than any slide deck.
Ask about policy as code. Can policies be defined in JSON, YAML, or a policy language — or is a web form the only interface? Form-only policy tools lock you out of version control, pull request reviews, and CI testing. When policies are code, they live in existing security review workflows.
Ask about policy lifecycle. What happens to a policy that is no longer needed? Mature platforms support a full lifecycle — draft, active, inactive, archived — with retained enforcement history. Platforms that only support create-and-delete leave you without a historical compliance record.
Ask about policy testing. Can a policy be tested against real or simulated traffic before enforcement? The ability to validate intended behavior in-platform, and catch conflicts with existing policies before they go live, is a meaningful differentiator.
Ask for a live demonstration of each. Not a description of the feature. Not a slide. A live demo in the actual product.
See How Barndoor Stacks Up
If you’re actively evaluating MCP gateway solutions, Barndoor’s Enterprise Buyer’s Guide to MCP Gateways walks through all 15 evaluation categories and maps them directly to the risks covered in this article — built for RFPs, vendor demos, and internal architecture reviews.
Ready to see it in practice? Start a free trial or book a demo to see how Barndoor MCP Governance addresses every requirement on this list.
