MCP Security Overlooks the Data Your AI Agents Can Reach

Every MCP server your organization connects to is holding something valuable: live, authenticated access to whatever systems it was built to reach. Salesforce. Microsoft 365. Slack. A code repository. A finance database. Ask most security teams what their AI agents can actually see through that connection and you will get a shrug, not an inventory.

That is the part of MCP security most of the market skips. The conversation right now is almost entirely about patching servers and hardening authentication, which matters, but it treats MCP like a code vulnerability problem. It is also a data exposure problem, and a bigger one than most security teams have priced in.

One Connection, Every Credential

The Model Context Protocol standardizes how AI assistants call external tools and services, which is exactly why it spread so fast after Anthropic introduced it in late 2024 and OpenAI adopted the standard soon after. An MCP server sits between an AI client and the systems it touches, and it typically holds the authentication tokens for every one of those systems at once.

That is the structural risk. A single compromised MCP server does not expose one application. It can expose every service it was configured to reach, and a stolen token used through MCP can look like ordinary API traffic, which makes it harder to catch than a traditional account compromise.

What Has Already Gone Wrong

This is not theoretical. Security researchers tracked more than 30 CVEs filed against MCP servers, clients and infrastructure components between January and February 2026 alone. Command injection accounts for a large share of them, the same class of vulnerability web applications have been patching for two decades, now showing up in brand-new AI infrastructure.

The clearest example of the data risk specifically, not just the code risk, was the postmark-mcp package. Rather than a loud exploit, it quietly added a hidden recipient to every email an AI agent sent through the server, redirecting copies of internal communications to an attacker. No crash, no alert, no obvious signal. Just a slow, silent leak that looked like normal operation.

Forcepoint X-Labs walked through a similar chain in a simulated attack: an over-permissive AI assistant leaks a token, the token escalates privileges on the MCP server, and the compromise pivots outward from there. The pattern is consistent. The server is the pivot point, and the data is the target.

Authentication Fixes the Door, Not the Data

The current MCP specification formalized OAuth 2.1 as the standard for remote server authentication, and most 2026 guidance centers on getting that right: validating tokens, isolating servers in containers, curating which servers get approved. All of it is necessary. None of it answers the question a security team actually needs answered, which is what data moved through that connection, to where, and under whose authority.

An MCP server can be perfectly authenticated and still hand a sensitive customer record to an agent that had no business seeing it. OAuth confirms the connection is legitimate. It says nothing about whether the data behind that connection was ever classified, scoped or watched once it started moving.

What to Ask Before You Trust Any MCP Deployment

Sandboxing and audit logging are table stakes at this point. The harder questions are the ones that determine whether a compromised or careless MCP server can actually reach and export something that matters:

• Does the agent hold direct credentials, or brokered ones? An agent that authenticates directly to Salesforce or M365 is a bigger blast radius than one working through short-lived, revocable tokens issued at the point of use.
• Is enforcement scoped to the field, or the application? Access to "Salesforce" is not a control. Access to specific fields, with sensitive ones classified and governed before an agent can reach them, is.
• Are high-risk actions gated by a human? Reading a file is low signal. Writing, deleting or transmitting data externally is where human approval earns its cost.
• Is there a full attribution trail? Agent identity, triggering user, data accessed, action taken. Without it, an incident becomes a guess instead of an investigation.

This is the same logic data loss prevention has applied to email and endpoint traffic for years, extended to a channel that did not exist two years ago. The classification and policy work most security teams have already done for their sensitive data does not get thrown out for agentic AI. It becomes the foundation the agent has to work within.

The Forcepoint AI Agent Gateway is built around exactly this gap: agents connecting to business applications through MCP without holding direct credentials, field-level enforcement instead of blanket application access, and human approval gates on the operations that actually carry risk. It is not a replacement for hardening the server. It is the layer that governs what happens after the connection is trusted.

Start With the Data, Not the Server

MCP is not going away, and the risk it introduces is not going to stay contained to the AppSec team's patch queue. Every agent your organization connects through MCP inherits a slice of your data estate. The question worth asking is not only whether that server is secure. It is whether you would know, right now, what it can reach and what it has already done.

For a fuller look at where AI is creating data exposure across shadow tools, sanctioned platforms and autonomous agents, and what a maturity model for closing those gaps actually looks like, get The Enterprise Guide to AI Data Security.