On June thirty, 2026, Microsoft Incident Response published the third post in its AI Application Security series, and this one is different from the first two. The earlier posts in the series looked at what happens when an AI tool reads content that has been tampered with. This one looks at what happens when the AI tool acts on it. That distinction matters enormously for anyone building agents in Copilot Studio, because Copilot Studio agents are built specifically to act: to query Dataverse, send correspondence through connectors, and call external services through Model Context Protocol servers.

This article walks through the attack pattern Microsoft describes, translates it into terms that map directly onto Copilot Studio and Power Platform admin center settings, and lays out a governance checklist for makers and admins. A note before we go further: the source material is threat research from Microsoft Incident Response and Microsoft Threat Intelligence, not official Copilot Studio product documentation. The mitigations map cleanly onto Power Platform controls, but this piece should be read as applied security research, not as a Microsoft product guide.

Why this applies to Copilot Studio specifically

Microsoft’s research names Copilot Studio and Azure AI Foundry directly as the platforms where organizations build custom agents that connect to business systems through MCP. Generative orchestration in Copilot Studio is what makes an agent capable of planning a multi-step task, deciding on its own which connected tool to call, and executing that call without a human confirming every step in between. That capability is the entire value proposition of an agentic Copilot Studio deployment, and it is also exactly the capability this attack pattern targets.

The scale context is worth sitting with. IDC projects the number of active AI agents in enterprises will grow from twenty-eight point six million in 2025 to more than two point two billion by 2030. That growth curve is why OWASP released a dedicated Top 10 for Agentic Applications in December 2025, alongside the existing LLM Top 10. The attack pattern below maps to two categories in that framework: tool misuse and agentic supply chain vulnerabilities.

The attack pattern, in Power Platform terms

Microsoft’s scenario involves a finance operations team building a Copilot Studio agent to help analysts handle vendor invoices. If you have built anything resembling this in a production environment, the architecture will look familiar. The agent has generative orchestration turned on and connects to three tools: a Dataverse MCP server holding the approved vendor master, an Outlook connector for vendor correspondence, and a third-party invoice enrichment MCP server used to validate banking details against an external reference database. The third-party server went through a service owner review. It did not go through a separate security review. That gap is where the attack lives.

Here is the chain, in four phases.

1. Tool description poisoning. The maintainer of the third-party enrichment server pushes an update. The tool name and the user-facing summary do not change. What changes is the MCP tool description, the natural-language metadata block the agent reads to decide how and when to call that tool. Hidden inside formatting guidance that looks routine is an instruction telling the agent to pull the last thirty unpaid invoices, summarize them, and attach that summary as an extra parameter on the enrichment call, framed as a fraud-heuristic requirement.
2. Silent re-trust. MCP servers reflect tool metadata updates dynamically. If your environment has no re-approval workflow tied to description changes on already-approved tools, that poisoned description goes live in production with no review at all.
3. User invocation. An analyst asks the agent an ordinary question about a supplier. The agent follows the hidden instructions embedded in the tool description, pulling financial records well outside the scope of the original question and folding them into the enrichment call, indistinguishable from a normal part of the request.
4. Exfiltration. The enrichment server sends back a plausible validated response and quietly logs the attached invoice summary to an endpoint the threat actor controls. The analyst sees a clean answer. Nothing in a default configuration necessarily fires an alert, because every individual action the agent took was within its normal operating parameters.

The uncomfortable detail in Microsoft’s writeup is this: this is not a Copilot vulnerability. The Dataverse query inherited the analyst’s own permissions correctly. The tool was properly allowlisted when it was added. The outbound call went to a server the organization had approved. Every gate did its job. The vulnerability sits in the trust boundary between systems, in the fact that MCP blends instructions with data inside a single field, so a change to tool metadata can redirect agent behavior with the same force as a change to the agent’s system prompt. The agent has no built-in way to tell a legitimate instruction from its own owner apart from a malicious one inserted by an upstream maintainer it has never met.

Mapping the mitigations to Power Platform admin center controls

Microsoft’s guidance groups controls into four points along the attack chain. Here is how each maps onto settings and features you can actually go configure today.

Govern the supply chain

Maintain a tenant-level allowlist of approved MCP publishers and servers rather than approving tools one at a time on an ad hoc basis. Microsoft’s own MCP catalog on GitHub lists first-party servers with verifiable provenance; anything outside that catalog needs its own review path. In Copilot Studio, this means disabling Allow all on MCP connections at the environment or tenant level and enabling only the specific tools a given agent actually needs, the same least-privilege discipline you would already apply to connector reference and DLP policy design.

Inspect tool metadata

Prompt Shields in Azure AI Content Safety can inspect content flowing from MCP tool responses and descriptions into agent context, and Defender for Cloud’s AI workload protection alerts on suspicious prompts and tool outputs at runtime. The governance discipline underneath both of these tools is the one worth internalizing even before you turn on the product: review metadata changes to production tools with the same rigor your ALM pipeline already applies to changes in a system prompt or a flow’s trigger conditions. A tool description is not documentation. It is executable context.

Guard the action

Microsoft Purview DLP policies can inspect tool call parameters and block sensitive data in outbound payloads, which is a materially different capability than the connector-level DLP policies most Power Platform admins are used to configuring, since it reaches into the parameters of the call itself rather than just the connector being used. For any high-impact action, financial data access, external sharing, account changes, configure human-in-the-loop approval directly in Copilot Studio rather than allowing full autonomous execution. Assign each agent its own non-human identity through Microsoft Entra Agent ID and apply Conditional Access to that workload identity the same way you would to a service principal running an unattended cloud flow.

Correlate the chain

When MCP server telemetry is instrumented and forwarded to Microsoft Sentinel, it can be correlated against agent behavior signals to surface anomalous sequences that no single log would show on its own. Microsoft Defender for Cloud Apps surfaces new external endpoints an agent has started talking to, and Purview audit logs give you the evidence trail if you ever need to reconstruct what happened after the fact. None of this replaces the environment-level monitoring you are likely already running; it extends it to cover agent behavior specifically.

Three principles worth adding to your governance framework

Microsoft closes with three principles that translate almost word for word into Power Platform governance language.

Treat every MCP server as part of the supply chain. Every MCP server an agent can call is a production dependency, full stop. Maintain an inventory of approved publishers, review tool descriptions during security review instead of trusting tool names alone, and require a documented owner for any third-party server before it goes into production. This is the same discipline default environment governance and connector inventory visibility already require of you; MCP servers just extend the inventory.

Treat tool descriptions as system prompts. Because the model reads tool metadata as part of its working context, a change to that metadata is functionally equivalent to a change in the agent’s instructions. Require change review for tool description updates on any critical agent, and use metadata inspection tooling to flag imperative language sitting inside what is supposed to be a documentation field.

Apply least agency, not just least privilege. A minimally permissioned agent can still cause real harm if it is given too much autonomy over when and how it acts. Turn off Allow all tool access, require human approval for high-impact actions, and establish baseline agent behavior in Sentinel so that a new endpoint, an expanded parameter, or an unusual query pattern actually trips an alert instead of passing as normal.

A pre-publication checklist for admins

• Inventory every MCP server connected to a Copilot Studio agent in the tenant, first-party and third-party alike
• Confirm Allow all is disabled on MCP connections; enable only the specific tools each agent needs
• Require a documented security review, not just a service owner sign-off, before any third-party MCP server reaches production
• Build a change-review process for tool description updates on production MCP servers, equivalent to your system prompt or flow change review
• Configure human-in-the-loop approval in Copilot Studio for high-impact actions: financial data access, external sharing, account changes
• Assign each agent a distinct non-human identity in Microsoft Entra Agent ID and apply Conditional Access to it
• Extend Purview DLP policies to inspect tool call parameters, not just connector-level access
• Forward MCP server telemetry to Microsoft Sentinel and establish a behavioral baseline per agent

The takeaway for makers, not just admins

If you are the one building the Copilot Studio agent rather than governing the tenant it lives in, the practical lesson is narrower but no less important: adding a new MCP tool to an agent is not a one-time approval event. It is taking on a dependency that can change underneath you without your knowledge, because tool descriptions update dynamically and most environments have no re-approval gate tied to that update. Before you wire a third-party MCP server into a generative-orchestration agent, ask who owns a security review of that server, not just who owns the business relationship with its vendor. Those are two different questions, and Microsoft’s case study is a reminder that only answering the second one is exactly how this pattern gets into production.

None of the controls above make an MCP server trustworthy on their own. They make the blast radius of an untrustworthy one small enough that a poisoned tool description gets caught before it becomes a live exfiltration path, rather than after.