MCP + API Keys = A Security Gap Most Organisations Are Not Ready For
Everyone is talking about AI adoption. Not enough people are talking about what that adoption is quietly opening up.
Everyone is talking about AI adoption. But not enough people are talking about what that adoption is quietly opening up.
What is MCP?
Model Context Protocol (MCP) lets AI assistants connect to external tools — your SaaS platforms, internal databases, productivity tools — through a standardised interface.
Think of it as a universal adapter. One AI. Connected to everything.
And that is exactly where the risk begins.
The Authentication Problem Nobody Is Talking About
MCP provides authorization mechanisms, but authentication and authorization are not automatically enforced across all implementations. OAuth support was only added to the spec in March 2025 — and even today, it remains optional. Researchers have reported over 1,800 MCP servers on the public internet running with no authentication at all.
Many MCP integrations authenticate using just an API key. A static string. No device check. No session. No identity verification.
Now think about your SaaS stack — Notion, Slack, GitHub, Jira. Most organisations do not monitor API requests at the individual platform level. No alert when a key is generated. No visibility into what is calling it, from where, or on whose behalf.
When a human logs in, there is a session, a device, a browser, an IP. Something to track. When an MCP server calls an API, most of that disappears.
The Personal Subscription Problem
This is the part security teams should pay attention to.
Employees can buy personal AI subscriptions — Claude Pro, Claude Max, ChatGPT Plus — and connect them to corporate tools through MCP servers, API keys, or OAuth tokens.
That creates a new shadow access path.
Many organisations still lack reliable controls to distinguish personal AI use from approved enterprise AI use, especially when users connect tools through locally configured MCP servers. Unlike Microsoft 365 or Google Workspace, where tenant restrictions enforce account separation, no equivalent straightforward control exists for Claude desktop today.
The Desktop app runs at OS level with broad local privileges — outside the browser, outside most proxy and DLP inspection paths. Most EDR and DLP tools are not monitoring at this layer. Very few DLP vendors offer even limited visibility into AI agent activity, and even those cover only a fraction of what MCP can do.
Data movement through a personal AI subscription connected to corporate tools does not look like exfiltration. It looks like productivity.
Where Device Assurance Helps — And Where It Does Not
Platforms like Google Workspace require OAuth 2.0 — no API key option. Device assurance and Conditional Access can intercept that flow. A personal Claude subscription on an unmanaged device will hit those controls and get blocked. That is real protection.
But only for platforms that enforce it.
Tools like Notion, Slack, GitHub, Jira — they support API token authentication with no device binding. An API key generated on a corporate device can be copied and used anywhere, by any application, including an MCP server running under a personal AI subscription.
The key leaves the device. The control does not.
This Is Not Just a Claude Problem
The MCP spec does not enforce auditing, sandboxing, or verification. Most organisations are not managing this at all.
A malicious MCP server discovered in the wild that silently BCC'd every outgoing email to an attacker. Internal memos, password resets, invoices — all of it, invisibly.
Researchers demonstrated that a malicious email with hidden instructions could cause an MCP-connected AI agent to forward sensitive messages without the user ever knowing.
Researchers at LayerX demonstrated a vulnerability where a malicious calendar event could trigger arbitrary code execution on a user's machine.
Some are documented incidents. Others are demonstrated attack paths. Both matter because they expose the same control gap.
What Security Teams Should Be Doing Now
- Monitor API activity. Every API key connected to a corporate SaaS platform is now a potential MCP entry point. Audit who generated them, when, and what is calling them. Anomalous API activity is the signal you will likely miss first.
- Update acceptable use policies. Most AUPs say nothing about MCP, personal AI subscriptions, or connecting third-party AI tools to corporate data. Users are doing this without realising it is a risk — because nothing tells them it is.
- Enforce device assurance where OAuth is available. For platforms that support it, device-bound authentication is a real control. For platforms that only offer API keys, that is your risk register item.
- Treat every MCP server like a software dependency. Allowlist approved servers. Block unapproved ones. Route MCP access through a centralised gateway with logging.
The Gap Nobody Is Looking At
We are moving towards autonomous monitoring. Agentic SOC. AI-driven detection and response. That is the right direction.
But here is the irony — the very protocol enabling AI agents to connect to enterprise systems is a blind spot in almost every current monitoring stack. SIEM rules are not written for MCP-initiated API calls. DLP is not inspecting what an AI agent pulled through a personal subscription. SOC tools are not watching MCP server connections.
We are building AI-powered defences while AI-powered attack surfaces are growing faster than the defences can adapt.
This is not a future problem. It is a current gap. And almost nobody is looking at it.
API keys bypass device policies.
Personal AI subscriptions bypass enterprise account controls.
MCP bypasses the visibility your security team spent years building.
The attack surface did not change because AI arrived. It just became invisible again.