AzureFeeds

Co-Author(s): ShalabhPradhan​ , Sarah_Young​

A year ago we published Understanding and mitigating security risks in MCP implementations.  

The core idea still holds: the moment a model can choose and call tools, it stops being a question-and-answer box and becomes software that acts. And software that acts has a trust boundary. Tool descriptions, schemas, outputs, and credentials all sit inside it. 

What has changed is scale. The Model Context Protocol has gone from a promising idea to the way agents connect to tools, data, and systems. Enterprises have stopped experimenting and started shipping into production. This post is a checkpoint: the main risks as they stand now, which of them have moved, and what good security looks like for each.

A specification that keeps moving

MCP is still evolving quickly, and the spec is revised on a regular cadence. The latest release candidate raises the security baseline in ways worth knowing: requests now carry what they need, so a gateway can inspect and enforce on every call instead of trusting a hidden session; identity checks between clients and servers are tighter; and a new MCP Apps capability lets a server ship interactive UI that the host renders inside a sandbox. 

One theme runs through all of it: the protocol deliberately does not enforce security for you. It defines how clients and servers talk; the locks are yours to fit. So treat “we reviewed MCP last year” as out of date, and revisit your assumptions with each release.  

That is exactly why the risk list below matters.

The main risks in 2026

Some of these are the same risks we flagged last year. Some have moved, and authorization in particular has been reworked. Each entry below is the short version: what it is, what happens if it is exploited, and the controls that help most. 

1. Prompt injection and tool poisoning

What it is: An agent treats everything in its context as trustworthy: tool descriptions, parameter schemas, and the data tools return. Anyone who can plant instructions in any of those can steer the agent. Tool poisoning is the sharp edge, malicious instructions hidden in a tool’s description or schema that the model reads and the user mostly ignores. 

What could happen: The agent follows the attacker’s instructions instead of the user’s. It might quietly exfiltrate data through a legitimate-looking tool call, invoke the wrong tool, or take an action nobody approved. 

Controls: Treat tool descriptions and outputs as untrusted input, and inspect the full schema, before approving a server. Make sure the tool list goes through a human approval process, and show the full tool call rather than a friendly summary. Isolate sensitive servers from general-purpose ones so a poisoned tool can’t reach across without high level safeguards.

2. Authorization and the confused deputy

What it is: This is where we had the biggest expansion. MCP servers are now treated as OAuth 2.0 resource servers and the guidance has hardened around OAuth 2.1, PKCE, and tokens that are bound to a specific audience. The risk it targets is the confused deputy: a server acting with its own broad privileges on behalf of a user who doesn’t have them, or a proxy that can be tricked into handing an attacker a valid authorization code. 

What could happen: An attacker rides the server’s privileges to reach data or actions the user was never entitled to, sometimes without the user approving anything at all. 

Controls: Adopt the current authorization model: OAuth 2.1 with PKCE, per-client consent, strict redirect-URI matching, and audience-bound tokens so a token minted for one server can’t be replayed against another. Put an identity-aware gateway in front of every server and reject any call without a valid, audience-bound token. Azure API Management can validate Microsoft Entra tokens and check issuer, audience, and expiry before the request reaches a tool.

3. Over-broad access and credential aggregation

What it is: A single MCP server often holds credentials for several systems at once and requests far wider scopes than it needs: full mailbox access where read-only would do. 

What could happen: One compromised server, or one leaked token, becomes a breach of every system it touches. Wide scope means wide blast radius. 

Controls: Least privilege, per resource: scoped, narrow OAuth scopes over wildcards; short-lived tokens over long-lived secrets. Give every agent an identity you can govern, like Microsoft Entra Agent ID, so you can apply policy to a whole class of agents or shut them down in one operation.

4. Supply chain and rug pulls

What it is: An MCP server is never just the server. It is the server, its dependencies, and the infrastructure it runs on, and each is a way in. A typosquatted package, a compromised dependency, or a change of ownership behind the same URL can all turn a trusted server hostile. The rug pull is the clearest case: a server behaves while it is being reviewed, earns approval, then changes after agents and workflows already depend on it. 

What could happen: The server you approved is not the server you are running. An ordinary tool call starts leaking its arguments, rewriting a response, or exfiltrating a token, and nothing about the request looks different from the thousands before it. 

Controls: Approval can’t be a one-time event. Register every server in a design-time catalog so you have a known-good baseline, pin tool definitions and alert on drift as your rug-pull tripwire, and route everything through a gateway that re-checks identity and policy on every call. Azure API Center inventories your APIs and MCP servers; the OWASP MCP Top 10 mapped to Azure controls lines the risks up against what you already run. 

What it is: This is shadow AI for the agent era. A developer stands up a server to unblock a demo; a team wires an agent to whatever endpoint is handy; nobody registers it. 

What could happen: You can’t govern, patch, or revoke what you can’t see, and ungoverned servers are exactly where supply chain problems hide. 

Controls: Visibility first: a design-time registry of what exists, plus a runtime gateway that everything routes through. The GSA AI Gateway helps you surface the unregistered, shadow servers you didn’t know were running.

6. Command injection and sandbox escape

What it is: Many MCP servers run locally and talk over standard input/output, spawning subprocesses and touching the file system. If a server passes unsanitized input into a shell or a file path, that is command injection or path traversal, and it has been one of the largest classes of MCP vulnerabilities reported this year. 

What could happen: Arbitrary code runs on the host, or a server reaches files and credentials well outside what it should, in the worst cases with no user approval at all. 

Controls: Sandbox local servers in containers with only the file-system and network access they need, and block outbound egress by default. Validate and sanitize every input and output, and never pass raw shell commands or unsanitized paths. Keep servers and SDKs patched, because this class of bug is being fixed in the field constantly.

Wrapping up 

The protocol got simpler and the trust boundary got busier. Authorization is in better shape, the new release candidate gives us cleaner ways to govern traffic, and the highest-impact failures have shifted toward supply chain, identity, and unregistered servers. For leaders, the job is to make adoption deliberate: know which servers exist, require identity and policy on tool calls, monitor drift, and revisit those controls as the spec changes. 

For enterprises running MCP, the practical step is to have platform and security teams validate the current docs and SDKs, then contribute back whatever holds up in production. Clear examples for authorization, gateway enforcement, sandbox defaults, audit events, and schema drift are what turn individual enterprise hardening into ecosystem guardrails. 

We encourage you to contribute to and suggest security related MCP RFCs to make this protocol even better! Open an issue in the specification repository. For implementation questions, the relevant Working Group channel on the contributor Discord is the fastest path to an answer. 

In the next part, we’ll get practical: a hands-on guide to implementing these controls in depth, with the patterns and configurations you can put to work.