Why Model Context Protocol Could Become Your Next Attack Surface

Run MCP across a whole company without losing control of it (Sponsored)

Companies are seeing dozens of MCP servers spun up by their devs, each with its own API keys. Nobody can say what any of them can read or send out.

Archestra is an open-source AI control plane, that runs MCP at company scale, inside your own Kubernetes cluster:

• A private registry of approved MCP servers - no more pasting random repos from GitHub

• Each server runs in its own pod, with its own network boundary and logs

• A policy on every tool call: a prompt-injected agent can read the email but can’t act on it

• API keys injected at call time. The model never sees them

• Every call logged: which agent, which tool, which identity

Try it on GitHub →

Model Context Protocol, or MCP, is one of the most important pieces of AI infrastructure.

At a high level, MCP gives AI applications a standardized way to connect to external systems. Instead of every AI assistant, coding agent, internal chatbot, or workflow agent needing a custom integration for every database, SaaS tool, file system, API, or developer platform, MCP creates a common protocol for connecting models to tools and data.

That is why developers like it.

It reduces integration work. It makes agents more useful. It gives AI systems access to context beyond their training data. It allows models to move from “answering questions” to actually performing tasks.

But for SREs and platform engineers, that usefulness is also the warning sign.

The moment an AI agent can connect to enterprise systems, call tools, retrieve files, query databases, or trigger workflows, MCP becomes more than an integration standard.

It becomes part of the attack surface.

And like every new infrastructure layer before it, MCP will create risk not because it is useless, but because it is powerful.

MCP Is the USB-C Port for AI Agents

The official MCP documentation describes the protocol as an open-source standard for connecting AI applications to external systems. It compares MCP to a USB-C port for AI apps: a standardized way to connect AI systems to data sources, tools, and workflows.

That analogy is useful, but it should also make security teams nervous.

A port is valuable because it connects things. But anything that connects systems can also become a path for abuse.

For enterprise AI, MCP can enable agents to access calendars, documents, databases, search engines, developer tools, internal APIs, cloud resources, and business workflows. That is exactly what makes it attractive for companies trying to deploy AI beyond simple chat.

• A support agent can pull customer history.

• A coding agent can interact with repositories.

• A finance agent can read invoices.

• A platform agent can query infrastructure.

• A security agent can investigate alerts.

• An operations agent can summarize incidents and recommend remediation.

But each of those integrations introduces a trust question:

• Should this agent be allowed to access this system?

• Should it be allowed to take this action?

• What happens if the tool is malicious?

• What happens if the tool description changes?

• What happens if the model is tricked into calling the wrong tool?

• What happens if an attacker hides instructions in data the agent reads?

MCP makes AI systems more capable. It also makes them more connected.

And connected systems need security boundaries.

The Risk Is Not MCP Alone. It Is MCP Plus Agency.

MCP is not dangerous simply because it connects systems. Enterprises have connected systems for decades through APIs, service accounts, integrations, plugins, webhooks, CI/CD tools, and automation platforms.

The difference is agency.

With traditional integrations, the logic is usually deterministic. A developer writes the code. The system calls a specific API under specific conditions. The workflow may still have bugs, but the decision path is explicit.

With AI agents, the model may decide which tool to use based on a prompt, retrieved context, tool metadata, prior messages, user intent, and other inputs. The action path is more dynamic.

That creates a new class of operational and security risk.

• A model might choose the wrong tool.

• It might pass the wrong parameters.

• It might trust malicious external content.

• It might reveal data in a generated response.

• It might perform an action that is technically allowed but contextually unsafe.

• It might misinterpret a tool’s description.

• It might be manipulated by instructions hidden in a document, webpage, issue, ticket, or email.

This is why MCP security is not just an AppSec problem. It is a platform engineering problem.

Platform teams will be the ones asked to standardize how agents connect to tools. SREs will be the ones asked to monitor whether those agents behave safely in p