Model Context Protocol (MCP) empowers AI to work with the tools and data that we mortals work with in our SaaS tools. Therefore, it’s unsurprising that MCP adoption has accelerated across industries in 2026. This adoption will continue to grow rapidly, especially as the MCP spec gets its biggest update yet: stateless MCP servers. That makes MCP servers even more reliable at scale, since any server can now handle any request.
This update will only accelerate a familiar pattern that I’ve seen over this last year when helping orgs roll out AI to employees: the technology has moved faster than the infrastructure to govern it.
What is unfamiliar, though, is how compliance and governance are now an accelerant for innovation. In past tech cycles, the same could not be true. But today, to move fast with AI, teams must first figure out how to use it in a governed and safe way.
While engineers have quietly been connecting AI agents to internal systems with MCP for over a year now, this shadow AI use doesn’t immediately prompt a dramatic incident or wake-up call for organizations. More often it is a quiet realization, as IT, security, and/or engineering leaders recognize that they can’t tell you what is connected to what, who authorized it, or what data has moved where.
This is the governance gap in enterprise AI. And right now, it is widening faster than most organizations can close it.
Because MCP is so transformative and (quite frankly) table stakes for the productivity gains that teams working with AI crave, its use often spreads organically within organizations. While companies are encouraging this type of AI innovation, it remains unclear who owns governance. IT? DevOps? The AI team? And of these teams, do they have the correct mental models to understand the unique vulnerabilities that MCP can introduce to an org?
Unlike APIs, MCP does not offer a pinned version. Servers can (and do) change over time without IT’s knowledge. Rug pull attacks, data exfiltration, and prompt injection are some of the exposure areas that companies need to protect against. Beyond that, companies also need guardrails around ensuring that employees don’t unwittingly share PII, PHI, or other sensitive data with AI clients.
Controlling what data and tools flow to AI tools through MCP connectors actually enables teams to move quickly. What follows are eight problems that companies must address to get the exact type of AI innovation that they want and need. These problems are also addressable by having a centralized layer (or MCP gateway) that monitors and controls how data flows between AI systems and MCP servers.
1. Nobody Knows What’s Actually Running
Foundational to safe and secure MCP use across the enterprise is knowing what MCP servers are being used. After all, you can’t secure what you can’t see.
Ask most IT or security teams to list every MCP server their organization is using, and you’ll get one of two answers: (1) “we’re blocking MCP until we can figure out how to control it” or (2) “we have no idea.”
Some MCP servers are running locally on developer machines, such as Playwright (a popular testing server that needs access to the browser). However, most servers are hosted in the cloud, either published by popular SaaS brands, built in-house, or accessible through open-source.
The consequence of this smorgasbord of servers isn’t just administrative untidiness. This lack of visibility means you cannot assess the risk of tools agents can access, the trustworthiness of the servers themselves, or the data flowing from the server to the AI client (and vice versa).
In other words, you cannot enforce access policy on servers that aren’t registered anywhere. And when something goes wrong, such as data exposure, requests for audit logs from regulators, or an overly privileged agent that goes rogue, there isn’t much recourse for companies that don’t have visibility.
What organizations actually need is an internal MCP registry. This single, managed view of every MCP integration in use allows IT to decide what is approved. The goal isn’t restriction. It’s accountability.
2. Visibility Is the Exception, Not the Rule
The protocol, out of the box, doesn’t offer logs that are helpful for forensic analysis. Perhaps you can debug with what MCP offers, but organizations need contextual metadata to answer basic questions: Which tools was this agent calling? What data passed through? Did PII or customer data flow to AI models? If so, who triggered it?
Teams typically have no reliable way to answer these questions, which creates compounding problems.
For one, companies can’t respond to audit questions about data handling from regulators. GDPR, HIPAA, the EU AI Act, and DORA (the Digital Operational Resilience Act) are just some of the regulations that companies might need to consider as they relate to both data processing and auditing.
Second, shared service accounts mean individual actions are unattributable.
And finally, without observability, security teams can’t investigate anomalies. Having visibility into what tool calls and data flows through AI is imperative. Later, we’ll also talk about how companies need to be able to control these tool calls and data as well. But first, visibility must be present.
3. Access Is All-or-Nothing
Without team provisioning and RBAC enforcement, MCP connectors can provide more data and tool access than companies feel comfortable with.
There is no inherent mechanism with the protocol to say “this team can use this tool and that team can’t” or “these users have read access and those users have write access.”
Either you block MCP entirely or you allow it entirely.
The practical consequences are significant. A senior employee with broad permissions in a system like a CRM or project management platform can connect it to an AI agent and inadvertently empower that agent to make destructive edits to the source of truth.
What’s needed is granular, role-based access control: the ability to define, at the user or team level, which tools can be reached and with what permissions. Not to restrict. To enable more precisely.
4. Sensitive Data Has No Protection at the Point of Movement
In regulated industries like financial services, insurance, healthcare, and legal, the question of what data moves through an AI integration and where it ends up is not academic. It is a compliance requirement.
PII, PHI, and other sensitive data should never be sent to an AI. This is not only the compliant or ethical thing to do, it’s also what customers are expecting. In fact, it’s been demonstrated that poor AI governance drives consumers to stop spending money with companies. A 2026 Digital Trust report by Usercentrics showed that 47% of global consumers have taken at least one action that adversely affected a company (such as canceling) in the past six months due to concerns about how that company handles their data with AI.
In addition, exposing this data to AI clients that are also connected to other tools can also inadvertently broaden the “blast radius” of this data exposure.
The gap organizations need to close is ensuring that sensitive data, such as consumer data and even IT access keys, never make it to AI clients. Filtering, anonymizing, or hashing sensitive fields before data leaves the source system, rather than relying on downstream controls or user behavior to contain it, is the best way to ensure data leaks don’t happen.
5. The Tools Themselves Can Be Tampered With
This is the problem that security teams are increasingly losing sleep over, and that most organizations haven’t fully internalized yet.
MCP servers don’t just provide access to systems, they embolden AI clients to work with the tools of those systems. However, those tools are not static. And when they change, context drift might happen, which degrades performance. Or in more dramatic situations, an MCP rug pull attack occurs. This is when the tool changes after a server connects to AI, and that tool change ends up doing something nefarious and destructive.
For example, an attacker can modify a tool description to instruct an agent to take actions the user never intended, such as exfiltrate data through channels that look legitimate, or chain together a sequence of calls that bypasses every other control in place.
The supply chain risk from open source MCP servers is real and largely unreviewed. What organizations need is the ability to monitor for changes in tool definitions, pin servers to known-good states, and detect prompt injection attempts before they propagate through a workflow.
6. Identity Doesn’t Scale
For small teams, managing MCP access manually is workable. For organizations with hundreds or thousands of employees, it quickly isn’t.
The problem is that MCP access can, at times, sit outside established identity infrastructure.
While MCP offers OAuth, it is a recommended (but not required) aspect of the spec. Furthermore, if shared service accounts connect to an MCP server, companies can’t trace it back to an individual identity.
Lastly, allocating access to certain servers (which have policies baked in, such as PII blocking) is not something you’ll get out of the box with MCP.
The answer isn’t a new identity system. It’s connecting MCP to the identity infrastructure that already exists: SSO, SCIM provisioning, Entra or Google Workspace or Okta. MCP gateways, such as MCP Manager, provide this. This allows teams to provision access that tracks automatically with organizational reality, rather than requiring manual reconciliation to stay current.
7. Non-Technical Users Are Being Left Behind, or Left Ungoverned
Developers were the first wave of MCP users. However, other knowledge workers are quickly following suit. Increasingly, operations teams, sales, finance, and customer success are part of the same org-wide AI rollout. They, too, have the same expectations around access to connected tools.
Governing non-technical users’ access to systems and data must be both easy and transparent.
While engineers will muscle through to get MCP working as they please, non-technical users need ease of use and direction. IT must make it clear what servers are trusted by provisioning governed access to servers. This concept of giving people the space to explore in a safe, easy, and secure way is bounded freedom. The guardrails provided allow non-techies to know they aren’t going to do anything wrong or harmful.
8. Cost Is Invisible Until It Isn’t
Token spend is the problem that tends to arrive as a surprise. A team deploys a few MCP servers, usage grows, and suddenly a significant share of the AI budget is being consumed by metadata.
Without usage monitoring, workflows that needlessly parse through superfluous data and tool calls can eat up tokens. There are ways to cut down what AI processes, reducing token use along the way.
This need isn’t just visibility. It’s the ability to set limits, attribute costs to teams or workflows, and optimize context loading so that token spend reflects actual value, not overhead.
What This All Points Toward
These eight problems look different on the surface: inventory, observability, access control, data protection, security, identity, usability, cost. However, they share a common root.
The infrastructure for deploying MCP safely at scale doesn’t yet exist inside most organizations. And the teams feeling the pressure to close that gap (e.g. IT, security, AI platform leads) are often working with tools and frameworks that were never designed for this use case.
The organizations navigating this well are not the ones that have slowed AI adoption down. They are the ones that have built or found a governance layer that sits between their people and their MCP integrations, providing the visibility and control that makes moving fast with AI safe rather than risky. Often, these teams are using MCP gateway technology to do so.
These gateways don’t just provide security features and visibility. Ultimately, these MCP gateways provide companies the confidence to say yes to AI.
