MCP in the Enterprise: Governing What AI Agents Can Reach
The Model Context Protocol is how AI agents reach your systems. It is what makes agents useful, and it is also the fastest way to give software you did not write access to data you care about. Here is what MCP is, what the specification does and does not protect you from, and the controls worth having before agents go anywhere near production.
MCP is an open protocol that lets AI agents discover and call tools and data in your systems. Treat every MCP server as a new privileged integration: keep an inventory, authorise per user and per tool, route calls through a control point, and log every one. The specification makes good practice possible. It does not make it compulsory.
What MCP is
MCP standardises how an AI application connects to the outside world. An MCP client runs inside the assistant or agent. An MCP server exposes tools, such as "create a ticket" or "look up an order", and resources, such as documents or records, that the client can discover and call. Before MCP, every one of those connections was bespoke. Now one server can serve many agents, and one agent can use many servers. The current specification is version 2026-07-28. MCP specification, version 2026-07-28
Servers come in two shapes. Remote servers run as services over HTTP, like any other API. Local servers run on the user's own machine and talk to the agent directly. The distinction matters for security, as the next section shows.
What the specification gives you, and what it does not
The authorisation part of the specification is sound, and built on established OAuth standards. For remote servers over HTTP it requires that:
- authorisation is based on OAuth 2.1, with the MCP server acting as a protected resource;
- clients state which server a token is for, and servers check that each token was issued specifically for them;
- servers do not accept, or pass through, tokens meant for anything else, which closes off the "confused deputy" problem where a server is tricked into acting with someone else's authority;
- clients ask only for the permissions an operation needs, and step up to more when a server asks, rather than taking everything up front.
Two things limit how much comfort that gives. First, authorisation is optional in the specification. A server can be built without it and still be a valid MCP server. Second, local servers are expected to take credentials from their environment rather than follow the OAuth flow, which in practice often means long lived tokens sitting on developer laptops. MCP authorization specification
An agent with a tool is a user with a script. Whatever an agent is allowed to do, a well crafted prompt hidden in an email, a web page or a document can ask it to do. Design permissions on the assumption that, at some point, the agent will be instructed by someone who is not you.
The risks to plan for
- Over privileged access. Agents connected with broad administrative credentials because it was quicker, so every tool call runs with far more authority than the task needs.
- Shadow MCP servers. Servers stood up by teams or individuals that nobody in security knows exist, and so nobody monitors.
- Tool poisoning and prompt injection. Malicious instructions planted in a tool's description or in the content a tool returns, which the model then follows.
- Credential sprawl. Each server holding its own secrets in its own configuration, with no central rotation or revocation.
- Chained exfiltration. One tool reads sensitive data and another sends it somewhere, each step individually permitted.
Source: Coalition for Secure AI, MCP security paper.
Controls to put in place first
- An inventory and an approved list. Know which MCP servers exist, who owns each one, what it can reach and which agents may use it. Anything not on the list does not get production credentials.
- Identity that follows the user. Agents should act with the permissions of the person they are acting for, scoped to the task, not with a shared service account that can do everything.
- A control point in front of the servers. Route MCP traffic through a gateway that handles authentication centrally, applies access rules per tool, rate limits calls and logs every one. Kong and Azure API Management both document this pattern. Kong AI Gateway documentation; Microsoft, AI gateway capabilities in Azure API Management.
- Read separated from write. Start with read only tools. Where a tool changes something, such as a payment, a record or an email to a customer, require confirmation from a person.
- Untrusted input stays untrusted. Treat tool descriptions and tool output the way you treat anything from the internet. Review third party servers before approving them, and pin the version you reviewed.
- Logs where security can see them. Send tool call logs to the same monitoring and security tooling as everything else, with enough detail to reconstruct what an agent did and on whose behalf.
- A rule for local servers. Decide whether local MCP servers are allowed on managed devices, and if so, which ones and with what credentials.
Where to start
The fastest safe route is usually not to build lots of bespoke MCP servers. Most organisations already have APIs for the systems agents need, with authentication and rate limits in place. Gateways can now publish those existing APIs as MCP tools, so the agent gets a tool and security keeps the controls it already trusts. Pick one read only use case, expose two or three tools through the gateway, log everything, and expand from there.
MCP governance is also a subset of a wider question about controlling AI traffic. Our guide to AI gateways covers the model side: cost, routing and data protection.
How we help
We design and deliver the control layer for AI agents: the inventory, the identity model, the gateway in front of MCP servers and the logging that lets security sleep. We start from the use case and the data involved, not from a product, and we deliver it alongside your existing security and integration teams. For the gateway itself, Kong is usually where we start, because its MCP controls sit in the same runtime as your API and AI model traffic, but we build on the platform you already run where it fits.
Letting AI agents near your systems?
Tell us which agents and systems are involved and where you are with security sign off. We will help you set up the inventory, identity and gateway controls that let agents go into production safely. We design and deliver it.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
Frequently asked questions
Is MCP secure?
The protocol can be used securely. Its authorisation specification is built on OAuth 2.1 and requires servers to check that tokens were issued for them and not to pass other tokens through. But authorisation is optional, local servers rely on credentials in their environment, and nothing in the protocol stops an agent following malicious instructions. Security depends on how you deploy it.
Do we need an MCP gateway?
If more than a handful of MCP servers will be in use, a gateway in front of them is the simplest way to centralise authentication, control which agent can call which tool, and log every call. Many AI gateway and API management platforms now include this, so it may be a feature of something you already run or plan to buy.
Can we expose our existing APIs as MCP tools?
Yes. Several gateways, including Kong and Azure API Management, can publish existing REST APIs as MCP tools. That is often the safest starting point, because the APIs already have authentication, rate limits and owners, and the gateway keeps those controls in place.
Who should own MCP in the organisation?
Usually the team that owns API management or integration, working with security. MCP servers are integrations with privileged access, so they need an owner, a lifecycle and a review process like any other integration, not just the team that wanted the agent.
What is a shadow MCP server?
An MCP server running without the knowledge of security or IT, often set up by a team or individual to connect an agent to a system quickly. Because nobody knows it exists, nobody monitors it, rotates its credentials or reviews what it can reach.