Is Copilot Studio Secure? What the 2026 CVE, the Secure Defaults and the Connector Model Actually Cover

Copilot Studio is secure by default and weakenable by a maker in about three clicks. Agents authenticate with Microsoft Entra unless someone changes it, connectors run on end user credentials unless someone changes it, and a new agent is shared with nobody until someone shares it. Microsoft runs an automatic scan that warns the maker when any of those three defaults is modified. What the platform does not do, and cannot currently do, is guarantee that an agent following instructions it read in a document, a form or an email is following yours.

That gap is not hypothetical. It has a CVE number and a patch date. Here is what the record actually says, separated from the marketing on both sides.

What Microsoft secures for you

Give the product its due first, because a lot of what a security team would go shopping for is already in the license. The Copilot Studio security and governance documentation on Microsoft Learn, last updated August 8, 2026, lists a control set that covers most of the configuration surface.

Power Platform data policies let admins govern maker and user authentication, knowledge sources, actions, connectors and skills, HTTP requests, publication to channels, Application Insights, and triggers. Maker audit logs flow into Microsoft Purview, and agent activity can be monitored and alerted on through Microsoft Sentinel. Customer-managed encryption keys are available per environment. Environment routing gives new makers a controlled place to build rather than dropping them into a shared space. And Microsoft Agent 365, a separate control plane, can represent Copilot Studio agents as identities in Microsoft Entra so they can be governed with Conditional Access and role-based or attribute-based access controls.

One detail deserves flagging because it is easy to miss and Microsoft states it plainly: the configured Customer Lockbox does not cover all outbound data from Copilot Studio. Security audit telemetry, including agent invocation events, tool and action calls and policy enforcement decisions, is processed through the Purview audit pipeline rather than the Copilot Studio service, and certain Agent 365 governance and audit events are also excluded. If your compliance posture leans on Lockbox, read that exclusion list before you rely on it.

What the automatic security scan actually checks

This one is worth being precise about, because the name suggests more than the feature does. Microsoft documents the automatic security scan as warning makers when secure default settings are updated, and the documented list is three items:

• Authentication mode set to No authentication, which lets anyone with the link interact with the agent, instead of the default Authenticate with Microsoft.
• Maker-provided credentials selected for connectors and flows instead of the default End user credentials.
• The agent shared with everyone in the organization instead of the default of shared with nobody.

Those three are well chosen. They are almost certainly the settings Microsoft has watched go wrong most often, and the second one in particular matters more than it looks: maker-provided credentials mean every user of the agent acts with the maker's rights, so the agent quietly becomes a privilege escalation path for anyone who can talk to it.

But note what the scan is not. It is a check on three configuration values at publish time. It does not evaluate whether the agent's tool list is too broad, whether the content it will process is authored by strangers, or whether an approved connector gives it a route out of the tenant. Copilot Studio does also run a real-time risk assessment that surfaces findings while a maker configures knowledge, tools and actions, which catches more, but it is still a design-time review of a configuration rather than a decision about a live action.

What CVE-2026-21520 showed

Capsule Security disclosed it as ShareLeak, and the chain contains no clever step at all.

An attacker fills in an external SharePoint form and puts instructions in a free-text field. The submission triggers a Copilot Studio agent, which concatenates the untrusted input with its own system instructions. The injected text overrides the legitimate ones. The agent then reads connected SharePoint Lists and sends customer data to an attacker-controlled email address. Microsoft scored it CVSS 7.5, classified it as information disclosure, patched it on January 15, 2026, and said the mitigation was carried out internally with no action required from users. Capsule had reported it on November 24, 2025, and the finding went public on April 15, 2026.

Two features of that chain generalize well beyond Microsoft.

The attack arrived through a business process, not a chat window. Nobody had to have access to the agent's interface. The company had deliberately published a form to the public, which is what forms are for. Capsule found the same technique against Salesforce Agentforce through a lead form. Salesforce characterized that one as configuration-specific and pointed at human-in-the-loop controls as the mitigation; the researchers replied that requiring manual approvals undermines the very purpose of autonomous agents. That disagreement is the whole industry argument in miniature, and it has not been settled.

Nothing was bypassed. The agent emailed data out because emailing was on its list of permitted actions, and read the lists because reading them was its job. There was no broken permission check. Which means the fix that survives the next variant is not a smarter filter on the input, it is a shorter list of things the agent is allowed to do with the output. We walk through that reasoning in more depth on Copilot Studio security and governance.

One layer down: the framework problem

In May 2026 Microsoft's own security research team published findings on remote code execution in AI agent frameworks, including CVE-2026-25592 in the Semantic Kernel .NET SDK, fixed in version 1.71.0. The mechanism is almost comic in its simplicity: a file-download method had been accidentally marked with a KernelFunction attribute, which, in Microsoft's words, "officially advertised it to the AI model as a callable tool." A single prompt was enough to write a payload into a Windows startup directory. A companion issue, CVE-2026-26030 in the Python semantic-kernel package before 1.39.4, came from unsafe string interpolation in filter functions where model-controlled values reached an injection sink.

Microsoft's own framing is the quotable part: prompt injection "draws a thin line between being just a content security problem and becoming a code execution primitive." That line is the reason a content filter is a mitigation rather than a control. Agents no longer only generate text. They read files, query connected systems and run code, and every capability you expose is a capability the model may decide to call.

So is it safe enough for your business?

Sort your agents into three buckets and the answer stops being one answer.

The middle row is the one teams get wrong, because the agent feels internal. It is sitting behind Entra, in the tenant, answering employees. But if the content it reads was typed by someone outside the company, the trust boundary is not where the login page is. It is wherever untrusted text enters the context window.

The third row is where the cost of being wrong changes character. An agent that can only answer questions produces a bad answer. An agent that can approve something, or send something, or delete something produces a consequence. Approval gates on that small set of actions are cheap. Teams running agents in procurement usually discover this the first time an automated workflow touches a purchase order, which is why the systems that handle purchase order approvals tend to keep a human signature step even after everything around it is automated. The same instinct belongs in your agent design.

A short checklist

1. Verify the three defaults on every published agent: Authenticate with Microsoft, End user credentials, not shared with everyone.
2. Set Power Platform data policies covering connectors, HTTP requests and triggers before makers need them, not after.
3. Use environment routing so new makers land somewhere governed.
4. For any agent that reads externally authored content, treat that content as hostile and cut the tool list accordingly.
5. Gate the irreversible actions: outbound mail to external domains, record deletion, permission changes, anything financial.
6. Build an inventory that answers four questions in minutes: which agents exist, who owns each, what each can reach, when it last acted.
7. Keep the action record somewhere the action path cannot rewrite.

None of that is an argument against Copilot Studio. It is a good product, the native controls are better than most buyers assume, and for a large share of internal agents a properly configured tenant is the right answer on its own. The argument is narrower: know which of your agents are in the second and third rows of that table, and put the enforcement where the actions happen rather than where the configuration lives. If you want the vendor-neutral version of the same reasoning, it is on AI runtime security, and the general injection problem is covered on prompt injection detection.

Try the threat console at the top of this page against a Copilot Studio style agent and see which actions get held, or see pricing if you already know the shape of what you need.