The Model Context Protocol (MCP) is quickly becoming a foundational building block for AI agents. It enables large language models (LLMs) to interact with external tools, APIs, and data sources in a standardized way, turning AI assistants from passive chatbots into systems that can take real action.

But with that power comes a new and rapidly expanding attack surface.

There is growing concern across security and platform engineering communities that unmanaged MCP deployments are extremely dangerous, particularly as thousands of MCP servers are now publicly available online. Without clear governance, MCP can introduce risks that traditional security controls were never designed to handle.

This post breaks down why MCP is risky when left unmanaged and outlines the minimum controls organizations should be implementing today.

MCP Changes the Security Model

Traditional application security assumes that integrations are:

  1. Designed by engineers
  2. Reviewed before deployment
  3. Static and predictable at runtime

MCP breaks all three assumptions.

With MCP, end users—not just developers—can connect AI agents to external systems. Agents dynamically decide which tools to call based on context and data they encounter at runtime. That behavior is a feature, not a bug—but it also means you can no longer rely on static code review or traditional API security models.

In effect, MCP turns AI agents into dynamic integration engines that operate across trust boundaries.

The Real Risk: Unvetted MCP Servers

The largest risk today isn’t MCP itself—it’s the ecosystem around it.

There are thousands of MCP servers available in public registries, many of which:

  • Are unofficial or community-maintained
  • Lack authentication or authorization controls
  • Have never undergone security review
  • Can be updated at any time without notice

Installing an MCP server is often as simple as running a package install command. In many environments, that means executing third-party code with access to local credentials, environment variables, network connectivity, and downstream systems.

From a security perspective, this is equivalent to letting users install browser extensions that can also call internal APIs and production systems.

Why MCP Is Especially Dangerous When Unmanaged

An unmanaged MCP deployment creates several compounding risks:

1. Expanded Attack Surface

Each MCP server adds new tools, permissions, and data paths. When agents are connected to multiple systems—email, ticketing, databases, cloud services—a single weak link can expose everything.

2. Instruction Injection via Data

AI agents consume user-generated content: support tickets, emails, documents, issues, logs. Malicious instructions embedded in otherwise legitimate data can influence agent behavior and cause unintended actions such as data exfiltration or unauthorized writes.

3. Over-Permissioned Tools

Many MCP servers expose broad or generic tools (for example, arbitrary SQL execution or file deletion). Without restriction, agents gain far more power than they actually need.

4. Lack of Visibility and Auditability

Without centralized logging and governance, it becomes nearly impossible to answer basic questions:

  • Which agent accessed what data?
  • Which tools were invoked?
  • Which MCP server initiated an action?
  • Was sensitive data exposed?

Minimum Guidance: Start With the Basics

While more advanced controls (such as gateways, sandboxing, and behavioral monitoring) are strongly recommended, the current baseline guidance is to enforce least privilege everywhere.

At a minimum, organizations should:

Default to Read-Only Access

All API and tool calls should be read-only by default. Write, update, or delete permissions should only be enabled when there is a clear, reviewed business requirement.

Explicitly Approve Write Capabilities

Write access should never be implicit. It should be:

  • Explicitly enabled
  • Scoped to specific tools or operations
  • Tied to a defined role or use case

Reduce Tool Scope

If an MCP server exposes multiple tools, only enable the subset that is required. Avoid generic or high-risk operations whenever possible.

Treat MCP Servers as Third-Party Code

Any MCP server—especially those sourced from public registries—should be treated like third-party software:

  • Assume it is untrusted until reviewed
  • Avoid local execution when possible
  • Prefer centrally managed deployments

Why Least Privilege Matters So Much for MCP

Least privilege is not just a best practice in MCP environments—it is a containment strategy.

When an agent is compromised (whether through malicious data, a supply chain issue, or emergent behavior), the blast radius is defined by what the agent is allowed to do. Read-only access dramatically limits the damage. Broad write access turns a mistake or exploit into an incident.

In MCP ecosystems, permission creep happens fast. Defaulting to minimal access is the only sustainable way to scale safely.

Final Thoughts

MCP enables powerful, flexible AI integrations—but unmanaged MCP environments are a serious security liability. The combination of dynamic agent behavior, unvetted public servers, and over-permissioned tools creates risks that traditional security models do not adequately address.

Until stronger governance frameworks are universally adopted, the safest path forward is clear:

  • Lock down permissions
  • Default to read-only
  • Treat every MCP server as potentially hostile
  • Require explicit justification for write access

MCP doesn’t have to be dangerous—but leaving it unmanaged absolutely is.