I've worked with about 10 firms over the last year - a mix of financial services + consultancies - and MCP implementation is starting to get out of control.

Everyone wants to implement it on their project, but there is not yet sufficient governance in place to manage the risk. Most organisations I've seen manage this right now by exception - they triage AI projects, approve the lowest-risk use cases, and delay the higher risk ones.

The obvious design pattern for MCP is to deploy a middleware gateway solution. I've seen a few who have opted for Azure API Management, and one that's opted for Cloudflare. In my opinion, these are not quite there yet and the control maturity is quite low. I've been recommending that firms build their own control layer (especially the ones that already have internal dev resources assigned to AI), and eventually move to a vendor once they've found what works best for them.

Regardless of what they do, there are three minimum control objectives I try to communicate. If they do these - with or without a gateway - they're typically in an excellent position

1. Ensure every action is attributable to a human

When MCP servers simply inherit OAuth tokens, there's not necessarily a clear record in the integrated system that an action was taken by an AI instead of a user.

Most implementations have moved to OAuth on-behalf-of (OBO) tokens, which is a step in the right direction. But it makes sense to establish your own independent record if you can, and then it doesn't matter how the integrated system handles the identity.

It also means you don't have to integrate logs from all your external platforms into your SIEM - you establish your own native capability and get a consistent logging format across all platforms.

You want to be able to audit that "Agent X took Action Y based on request from User Z".

2. Agents run at least privilege, not the user's privilege

A common source of frustration I see is that a team wants to create an MCP integration for Confluence, and the agent inherits the permission context of its user.

The user has write access to Confluence, but all the team wants to do is allow the agent to read internal documentation. So why are we granting it write access as well, which can be highly destructive if the agent gets confused or is maliciously prompted?

Like with the above, some platforms do have the capability to fine-tune RBACs for agents - but most don't. If you add this capability in a middleware solution that you control, you've now centralised all agent permissions and achieved a simple source of truth.

3. Every request travels a governed path

A middleware gateway that applies business policy only makes sense if MCPs are actually using it. You can enforce that by issuing administrative policies and defining acceptable use, but also by hardcoding the gateway configuration in your agent clients.

By definition, MCPs that don't use a governed path are now "Shadow AI/IT". It's still quite difficult to detect this (M365 Defender for Cloud Apps helps a little). But because MCP is encapsulated in HTTPS, you can only rely on DNS right now, which is highly unreliable.

At some point, I'm certain that FW vendors will develop an ML capability that can detect the signatures for encrypted MCP payloads, which will provide a much more reliable method of detecting shadow usage. But right now the options are fairly limited except to enforce via working culture and managed devices.

I've written up about this in a tad more detail here: https://www.analystengine.io/insights/how-to-secure-mcp-in-the-enterprise