MCP in enterprise: access control and audit logging

#ai #security #devops #webdev

MCP in enterprise: access control and audit logging

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.

What MCP is and what it connects (quick recap)

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.

The default security posture: one service account for everything

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.

The six enterprise controls MCP does not ship with

Enterprise MCP governance needs, at minimum, six things the base protocol leaves as an exercise for the implementer:

OAuth 2.0 authentication. Real user identity flowing through the request, not just a static key.
Per operation RBAC or ABAC. Role based or attribute based access control scoped to the specific tool call, not the whole server.
Attribution level audit logging. Every call tied to the person who triggered it, not just the service account that executed it.
Path and scope controls. Limits on which resources a given call can reach, even within a tool the agent is otherwise allowed to use.
Rate limiting. Protection against an agent that gets stuck in a loop and hammers a downstream system.
Sensitivity label evaluation. A check on whether the data being requested is even the kind of thing this caller should see, independent of whether the underlying credential technically permits it.

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.

What an MCP gateway gives you, and when you need one

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.

The minimum viable audit log capture set

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:

Identity of the caller (not just the service account)
Tool name invoked
Full arguments passed, not a summary
Execution outcome (success, failure, denied)
Authorization context under which the call was allowed
Lineage back to the parent LLM request that triggered it
A cryptographic integrity hash so the log itself cannot be quietly edited after the fact

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.

Compliance implications: HIPAA, GDPR, SOX gaps in naive MCP

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.

FAQ

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.