Ship an MCP server at a company with compliance requirements and you will hit the same wall every team hits: the protocol connects your AI agent to tools beautifully, and it gives you almost nothing to control what that agent is allowed to touch once it is connected.
That gap is not a bug. MCP was built to solve connectivity, not governance. But if your agent touches a database, a ticketing system, or a support inbox with real customer data in it, connectivity without governance is exactly what gets you a very uncomfortable meeting with security.
MCP (Model Context Protocol) standardizes how an AI agent talks to external tools and data sources. Instead of writing custom glue code for every integration, you stand up an MCP server that exposes a set of tools, and any MCP compatible client (an agent, an IDE, a chat app) can call them the same way.
That is the whole pitch, and it works. What it does not include is anything resembling per user permissions.
Here is the part that catches teams off guard. Default MCP implementations authenticate with a single service account, and that account gets whatever access it was granted at setup. There is no concept of "this specific user should only see their own records" baked into the protocol itself.
So if your MCP server connects to a CRM using one API key with read and write access to every record, every agent call through that server inherits the full blast radius of that key. It does not matter if the human on the other end of the request is a support rep who should only ever touch their own five open tickets. The agent, and by extension anyone who can reach the agent, effectively has the same reach as the service account.
This is fine for a weekend project talking to your own sandbox. It is not fine for a production system touching HIPAA, GDPR, or SOX regulated data, and it is the single most common reason enterprise MCP rollouts stall in security review.
Enterprise MCP governance needs, at minimum, six things the base protocol leaves as an exercise for the implementer:
None of this comes free. You either build it yourself around your MCP servers, or you put something in front of them that already has.
An MCP gateway sits between your agents and your MCP servers as a central broker. Instead of every agent talking directly to every server, calls route through the gateway first, which enforces policy and records a single unified audit log of everything that happened.
Practically, this means the gateway is where you implement the six controls above once, instead of rebuilding them inside every MCP server you stand up. New server, same gateway policy layer in front of it. That is the point.
You need one the moment more than one team is deploying MCP servers independently, or the moment a single MCP server touches anything regulated. If you are running one internal tool for one small team with nothing sensitive behind it, you can probably get away without one for a while. That window closes fast in a real company.
If you are building this yourself before a gateway exists, here is the floor, not the ceiling, for what a defensible audit log needs to capture on every call: Skip any of these and you have a log that looks reassuring in a demo and falls apart the moment an auditor asks a follow up question.
MCP's native logging is minimal and ephemeral. That phrase does a lot of work. Minimal means it was never designed to answer "who accessed this specific record and why." Ephemeral means even the logging it does produce may not persist long enough to satisfy a retention requirement.
For HIPAA, that is a problem the moment protected health information passes through a tool call. For GDPR, it is a problem the moment a data subject access request forces you to reconstruct exactly what an automated system touched on their behalf. For SOX, it is a problem the moment financial data flows through an agent that has no attribution trail back to a specific authorized user. None of these frameworks care that the gap came from the protocol rather than your code. The audit still has to happen, and the burden of proof still lands on whoever deployed the system.
Is MCP secure for enterprise?
MCP itself is a connectivity protocol, not a security framework. It can be run securely in an enterprise, but only once you add authentication, authorization, and audit logging around it. Deployed with the default single service account setup, it is not enterprise ready on its own.
What is an MCP gateway?
A broker layer that sits between agents and MCP servers, enforcing access policy and centralizing audit logging so you are not rebuilding those controls inside every individual server.
How do you audit MCP tool calls?
Capture caller identity, tool name, full arguments, execution outcome, authorization context, and request lineage on every call, with a cryptographic hash so the log cannot be silently altered later. A gateway is the practical place to implement this once instead of per server.
If you want a deeper look at securing agent deployments in production, I cover it in more detail on my blog.
If you want this wired up on your own stack end to end, that is exactly the kind of work I take on.
Curious how other teams are handling MCP access control in production. Drop a comment if your setup looks different, especially if you have landed on a gateway pattern that works well.