Enterprise-Ready MCP Brings a Fresh Set of Security Challenges

The Model Context Protocol (MCP) went from an Anthropic proposal to the de facto standard for letting a model call external tools in little more than a year and a half. That fast adoption has a flip side: every MCP server a company plugs into its assistant is a new door into its data and its systems. SecurityWeek devotes an analysis to the latest revision of the specification, the one meant for corporate settings, and the takeaway is clear: what makes MCP fit for production is also what widens its attack surface. You can read the original article on SecurityWeek.

What changed

The enterprise-ready version of the protocol does not add a flashy feature; it closes the gaps that kept it from being used seriously inside an organization. The core piece is authorization: the permission model now leans on OAuth 2.1, with scoped tokens and a clearer separation between who the user is, which server acts on their behalf, and which resources it may touch. Alongside that, the spec formalizes how servers are discovered, how their capabilities are declared, and how activity is logged. On paper, it is exactly what any security team asks for before letting an agent run real actions.

Why it matters

The problem is that a tool protocol inherits the risks of every tool it exposes, and adds its own. Three fronts stand out.

The first is indirect prompt injection. If an MCP server returns text that the model treats as trusted context, that text can carry instructions. A manipulated document, ticket, or web page becomes a way to make the agent do something its user never asked for.

The second is the 'confused deputy'. An agent holding valid tokens and broad permissions is a tempting middleman: if an attacker manages to redirect its intent, the agent will use its legitimate credentials to act. The enterprise spec narrows the margin by scoping access, but it does not remove the pattern.

The third is the supply chain. Installing a third-party MCP server is closer to installing an extension with permissions than to calling an API: it runs with access to data and actions, and almost nobody audits its code. A growing catalog of community servers multiplies convenience and, with it, the risk that a malicious or simply careless one reaches production.

Who it is for

The story matters most to three profiles. Platform and infrastructure teams deciding how to deploy MCP centrally instead of letting each developer wire up whatever they want. Security leads, who need to treat each server as privileged software rather than a harmless plugin. And the people building MCP servers, who now have a serious authorization framework but also the duty not to request more permissions than they need.

For a company already using Claude Code or internal assistants, the practical message is simple: the MCP server inventory is now part of the security inventory. It pays to know which ones are connected, with what scopes, who maintains them, and what they can do in the worst case.

EP's take

We have integrated MCP into enough projects to hold a measured view: the protocol is not insecure by design, but taking something born for the developer's desktop into production demands the same controls as any privileged integration. The enterprise spec is a necessary step, not a guarantee. Anyone deploying MCP servers across an organization would do well to start with the boring parts, minimal scopes, activity logging, and a review of what each server exposes, before the list of new integrations.