You've built AI agents on Azure. Has anyone checked who else can use them?
Agentic AI and MCP integrations have introduced an attack surface that most Azure security models weren't designed for. CVEs are appearing, real exploits have hit production M365 environments, and the deployment conversation has moved considerably faster than the security one.
There's a version of this post that opens with "AI agents are everywhere now." You don't need that version. You know they're everywhere, because you've been deploying them.
What's less certain is whether the security conversation has kept pace. Based on the CVEs, research, and documented incidents from the last twelve months, for most organisations it hasn't.
The MCP attack surface
If you're wiring Azure AI Foundry or Copilot Studio agents to external tools via MCP, the threat model is different from anything in the traditional Azure threat matrix. The attack surface isn't the network perimeter. It's the context window.
Tool poisoning is the pattern to understand. Invariant Labs published the first proof of concept in April 2025: a poisoned calculator tool silently exfiltrated SSH private keys from a developer's machine. When an agent connects to an MCP server, it ingests that server's tool descriptions as part of its operating context. Those descriptions sit in the same privileged position as developer-authored instructions. The agent cannot distinguish between a legitimate tool description and a payload embedded inside one.
A March 2026 study across seven major MCP clients found five had no static validation of tool descriptions at all. The MCP spec doesn't require it.
Trail of Bits documented a variant called "line jumping": attacks that execute before any tool is called, at the moment the client calls tools/list. There's also the rug pull. Tools that behave legitimately during your evaluation, then change behaviour after you've approved them. MCP has no version pinning, no re-consent mechanism, and no integrity check on tool definitions between sessions.
The documented production case is the Supabase/Cursor incident from mid-2025: attackers embedded SQL instructions in support tickets processed by a Cursor agent that had service-role access. Integration tokens ended up in a public support thread. Not a proof of concept.
EchoLeak: zero-click data exfiltration from M365 Copilot
CVE-2025-32711, CVSS 9.3. Discovered by Aim Security, patched by Microsoft in June 2025.
An attacker sends a crafted email. When the user later asks Copilot anything about their M365 data (an HR record, a financial report, a contract), Copilot processes both the legitimate query and the hidden instructions absorbed from that email. The instructions embed the sensitive answer in an image URL pointing to an attacker-controlled server. The client auto-fetches the image. Data leaves.
The bypass that made it work: Microsoft's output filters caught inline Markdown links but missed reference-style syntax. The exfiltration request was proxied through Microsoft's own Teams async preview API, which sat on the CSP allowlist. Zero clicks. Nothing anomalous for a CASB.
Microsoft patched this specific exploit. The underlying class, indirect prompt injection through content the agent is legitimately authorised to read, is not something a patch fully resolves. OWASP's Top 10 for Agentic Applications lists it as the leading risk category. OpenAI, Anthropic, and Google DeepMind have all stated in published work that this class of attack cannot be fully prevented in current LLM architectures.
The Connected Agents problem in Copilot Studio
Zenity Labs published research on a feature worth knowing about: Connected Agents, enabled by default on all new Copilot Studio agents since Build 2025. An attacker with any foothold in your M365 or Power Platform environment can connect a malicious agent to one of your legitimate privileged agents. Those with email-sending capability, SharePoint access, or business data connectors. Connected Agents invocations generate zero messages in the targeted agent's activity tab. No native audit trail.
CVE-2026-21520, CVSS 7.5, patched January 2026. Capsule Security showed what this enables: malicious instructions injected via a SharePoint form's Comments field redirected a Copilot Studio agent to extract customer data and send it to an external address using the agent's own Outlook connector. The permissions were never technically misused. The agent did what it was told, by someone it had no business listening to.
The permissions problem is a blast radius problem
Research across enterprise AI deployments puts 97% of non-human identities carrying excessive privileges. The pattern that keeps appearing in Azure: Managed Identity granted Contributor, Key Vault Administrator, or Owner at subscription or resource group scope rather than scoped to the specific resource. Identity chaining does the rest.
The Azure Instance Metadata Service matters more now than it used to. Every VM, container, or function running with a managed identity exposes IMDS at 169.254.169.254. No authentication required, accessible from any process on the host. Any process can request tokens for Key Vault, Graph, ARM, Storage. If an agent has a URL-fetching tool and someone can influence its instructions via prompt injection, reaching IMDS takes one tool call. Microsoft's Storm-2949 threat intelligence report from May 2026 documents what this chain looks like once it completes: from a single compromised credential with Key Vault Owner, the attacker spent four minutes getting database connection strings, storage access, and App Service publishing credentials. Full blast radius, in the time it takes to make a coffee.
The scale difference matters too. Agents don't work at human pace. Research puts agent data movement at roughly sixteen times the volume of an equivalent human user. That's what you're attaching to your Managed Identity chain.
What Microsoft has shipped
From 1 July, AI agent security for Copilot Studio and Foundry agents moved to Microsoft Agent 365 licensing. The Defender portal has a dedicated AI Agents section under Assets with per-agent risk indicators and observability logs. Microsoft Entra Agent ID is the new framework for managing agent workload identities, separate from app registrations and service principals, with blueprint-level controls and a kill-switch that disables all instances of an agent class instantly.
Prompt Shields in Azure AI Content Safety will inspect content from MCP tool responses before it enters agent context. The February 2026 security blog on Copilot Studio misconfigurations is worth reading if you missed it, particularly the secrets management section. People are still storing credentials in agent definitions. It keeps showing up in production incidents.
The honest position
Prompt injection cannot be fully prevented in current LLM architectures. Defense in depth is the only viable approach.
For Azure agent deployments that means a few things. Scope Managed Identities to the resource, not the subscription. Use PIM for anything sensitive. Run access reviews against AI service principals on the same cadence you use for human identities. Block agent egress to 169.254.169.254 at the network layer. A Copilot Studio agent has no legitimate reason to reach IMDS. Treat MCP server dependencies as a supply chain: know who controls them, audit changes, assume tool descriptions can change between sessions. Put human-in-the-loop gates on high-impact actions in code, not in the system prompt, because system prompts can be overridden.
And get agent pipelines into your red team scope. Unit 42 documented twenty-two distinct payload engineering techniques from live campaigns earlier this year. Someone has probably already tried several of them against your stack.
