MCP is now the default way agents reach tools and data, and that reach is the attack surface. This post looks at where the real risk sits in 2026, what has changed since last year, and the controls that address each one.
Co-Author: ShalabhPradhan
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. Anything that acts has a trust boundary, and 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 rather than trust 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.
The protocol deliberately does not enforce security for you. It defines how clients and servers talk, and the rest is your responsibility. Treat "we reviewed MCP last year" as out of date, and revisit your assumptions with each release.
The main risks in 2026
Some of these are the risks we flagged last year. Some have shifted, and authorization in particular has been reworked. Each entry below covers the same three things: what the risk is, what happens if it is exploited, and the controls that help most.
Figure 1: MCP Security Overview1. 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 usually does not.
What could happen: The agent follows the attacker's instructions instead of the user's. It might exfiltrate data through a tool call that looks legitimate, call the wrong tool, or take an action nobody approved.
Controls: Treat tool descriptions and outputs as untrusted input, and inspect the full schema before you approve a server. Put the tool list through a human approval step, and show the full tool call rather than a friendly summary. Keep sensitive servers isolated from general-purpose ones so a poisoned tool cannot reach across without further safeguards.
2. Authorization and the confused deputy
What it is: This is where the protocol moved most. MCP servers are now treated as OAuth 2.0 resource servers, and the guidance has settled on OAuth 2.1, PKCE, and tokens 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 does not have them, or a proxy that can be tricked into handing an attacker a valid authorization code.
What could happen: An attacker uses the server's privileges to reach data or actions the user was never entitled to, sometimes without the user approving anything.
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 issued for one server cannot be replayed against another. Put an identity-aware gateway in front of every server and reject any call that does not carry 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.
Figure 2: Confused Deputy Problem
3. Over-broad access and credential aggregation
What it is: A single MCP server often holds credentials for several systems at once, and asks for wider scopes than it needs, such as full mailbox access where read-only would do.
What could happen: One compromised server, or one leaked token, becomes a breach path of every system it touches. Wide scope means a wide blast radius.
Controls: Apply 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 of those is a way in. A typo squatted package, a compromised dependency, or a change of ownership behind the same URL can all turn a trusted server hostile. Also, known as a 'rug pull' attack where a server behaves while it is being reviewed, earns approval, then changes once agents and workflows already depend on it.
What could happen: The server you approved is no longer the server you run. 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 cannot be a one-time event. Build a Secure By Design Registry and register every server in a design-time catalog so you have a known-good baseline, pin tool definitions and alert on drift so you have a tripwire for rug pulls, and route everything through a gateway that re-checks identity and policy on every call. Azure API Center inventories your APIs and MCP servers, and the OWASP MCP Top 10 mapped to Azure controls lines the risks up against what you already run.
Figure 3: Supply Chain- Rug Pull. The approved dependency remains trusted even after ownership, version, or behavior changes.
5. Shadow MCP
What it is: This is shadow IT for the AI era. A developer stands up a server to unblock a demo or get some work done quickly, a team wires an agent to whatever endpoint is handy, and nobody registers or verifies it.
What could happen: You cannot govern, patch, or revoke what you cannot see, and ungoverned servers are where supply chain problems tend to hide.
Controls: Start with visibility, of what exists, and 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, you have command injection or path traversal, and that 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 traffic 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
MCP has not changed what good security looks like, only where you need to apply it. The risks that matter most now sit at the supply chain, in identity, and in servers nobody verified, and the controls that address them are ones you already know: strong identity, least privilege, a gateway in front of every server, sandboxing for local servers, and an alert when an approved tool changes. The spec continues to keep improving, but it still leaves the security decisions to you.
If you would like to help improve the protocol, you can contribute to the specification here.
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.
With thanks to Sarah_Young for their inputs and collaboration on this post.
Microsoft