What is MCP and why do we care?#
MCP is a communication protocol that allows an AI agent – any AI agent – to use a tool. That tool could do anything. It could check for new emails, send a Slack message, or query a database.
AI agents can use tools without MCP, but they would have to be developed on every agent across every device. MCP encapsulates that logic into a single container that can be trivially integrated into your AI stacks, across all AI surfaces.
It provides a simple way of expanding what your AI can do across the business. If you give your AI platforms access to the systems you use daily, they'll be able to do more valuable work that could previously only be done by a human.
An MCP server lets any agent communicate with your business systems
In an ideal universe, we would create one MCP, develop the integrations we want once, and then let any authorised AI agent make use of them.
In reality, however, it's not that simple. Most vendors publish their own MCP servers to make it easier for your team to use it with their AI. This means there is never going to be "just one" MCP server in your environment, there will be many, and the attack surface will be large.
What MCP use actually looks like
When a vendor adds a new MCP server and encourages its adoption, there is nothing stopping one of your users from integrating it with their AI, and now it can work natively within that platform. Perhaps it's your CRM or ERP.
- Could you stop that integration if you wanted to?
- Can you differentiate human use from AI use?
- Do you have safeguards to prevent AI from causing destructive actions, such as deleting everything?
And all of those points assume benign intention. When we consider malicious activity – such as prompt injections or poisoning attacks – the impacts can get considerable.
Threat Scenario
This is why MCP is an ecosystem problem. When AI agents can use MCP to bridge multiple integrations, a simple prompt injection attack can quickly escalate into a worst-case cybersecurity incident.
The core challenge that MCP presents to organisations is therefore quite simple: how can we channel it through an approved vector, so that we can extend organisational control over how it's used?
Control objectives for MCP#
Securing MCP in an enterprise environment means meeting the following high-level control objectives.
- Attributable connections: We must monitor and log all MCP interactions and ensure that every agentic request is attributable to an initiating user.
- Least privilege operations: We must authenticate the user and mint delegated tokens for agent use, which will often involve a smaller subset of permissions compared with the original user.
- Governed pathway: We must enforce business policy irrespective of upstream logic. For example, we can require human-in-the-loop approval before any autonomous write action is taken, even if the upstream MCP does not support that.
We can't rely on every MCP server being compliant with these objectives, so we must architect a middleware solution that ensures these control objectives are met regardless of the integrations.
Every path runs through the gateway
How the gateway works#
The gateway sits between our AI agents and the MCP servers they want to reach. From the agent's point of view, it is just another MCP server. Copilot or Claude connects to it, asks what tools are available, and gets a list back. The key difference is that we've filtered this list for tools that only this user is authorised to use, and every attempt to use these tools is checked and audited.
Let's say a user asks their agent to update a Confluence page. Here's what happens:
- The client sends that request to the gateway.
- The gateway knows who the user is, because they've authenticated with Entra, and it knows which agent is asking. It records both against the request.
- It then looks at what the request is trying to do and checks whether the policy for that use case allows it. In this case it does, but only if the user approves it first. So the gateway sends an alert back to the user asking them to manually approve the request.
- Once approved, the gateway asks Entra for a token to call Confluence with, scoped to the write permission that tool needs and nothing else.
- Confluence sees the agent acting for the user, does the work, and sends the result back through the gateway, where it is checked again before the model sees it.
Nothing in this sequence depends on the vendor who built the MCP server supporting any of this logic. The gateway allows us to apply the necessary controls before the request reaches their server.
A single request through the gateway
Business policy as a technical control#
The main advantage of an MCP gateway is that you can evaluate every request and response against business policy. The policy can allow a request, block it, slow it down, or hold it until a human has approved it.
What policies or rules you want to apply depend on the situation, but I've noted some common examples below.
| Policy | What it looks like | What it protects against |
|---|---|---|
| Human-in-the-loop approval | High-risk actions – deletion, permission changes, sharing outside the organisation – are held until the requesting user or a designated approver confirms them. | Destructive and irreversible actions completing on the agent's judgement alone. |
| Write rate-limiting | Above a per-use-case threshold, write requests are rejected. | A runaway agent loop, or a poisoned agent told to modify at scale, is capped at a rate a human can notice and stop. |
| Bulk-read throttling | A cap on the number of documents or records an agent can retrieve per session. | Mass exfiltration, which is the usual payoff of an injection attack. A bulk theft becomes a slow, detectable one. |
| Inbound content screening | Tool responses run through a prompt-injection classifier before they enter model context, in the same way an email gateway scans an attachment. | Instructions hidden in a document, ticket or email steering the agent. Screening is best-effort, so the other policies still carry the residual. |
| PII and classified-data handling | Responses are inspected and personal or classified data masked where the use case has no need for it. | Sensitive data being drawn into model context beyond need-to-know. |
| Agent-autonomy caps | A limit on execution depth and tool calls per originating request, with explicit re-authorisation beyond it. | Long-running or scheduled agents drifting many steps from what a human actually asked for. |
| Kill switch | A standing deny on a server, a tool, an agent identity or a use case, set directly by SecOps. | A compromised or misbehaving component staying live while we wait for the owning team to act. |
Think back to the SharePoint scenario from earlier. With these policies in place, the poisoned document is screened on the way in. If it gets through, the bulk read is throttled, the attempt to send data outside the organisation needs approval, and every step is audited and available to your SecOps team.
Without the ability to apply policies like this to MCP use, you simply don't have the control infrastructure to defend against novel AI attack vectors.