Copilot Studio Security: Six Settings That Decide the Blast Radius

Somebody in operations stood up a low-code agent two quarters ago. It answers staff questions out of a document library and reaches a line-of-business system through a connector. No human name is recorded against it anywhere, and nobody in the security function has ever opened it. That is the normal case on this platform, not the alarming one.

Nothing below dissects a breach. Searching turned up no disclosed case in which a real organisation's own Copilot Studio agent was abused, so what gets pulled apart below is the platform surface itself: what the product permits by default, taken from the vendor's documentation, and what researchers have been able to make it do in a lab, taken from dated outside write-ups. Zenity sells tooling into this category, so its framing is treated here as a vendor's framing. No tenant was examined to write this, and none of it replaces an assessment by somebody who can actually see your configuration.

Five Dated Items, No Incident

When	What is on the record	Who published it
Black Hat USA, August 2025	Zenity Labs demonstrates hijack chains against enterprise agents, with Copilot Studio among the platforms named	eSecurityPlanet
8 September 2025	Advanced real-time protection during agent runtime enters public preview	Microsoft
11 December 2025	A travel agent built on the platform is steered off its instructions into disclosure and a fraudulent edit	Tenable
Updated September 2026	An Agent status summary is documented, grouping readiness, governance and security issues by severity	Microsoft Learn
Undated on the page	The automatic pre-publish scan, and the admin governance surface it sits beside	Microsoft Learn
Not disclosed	Abuse of one of these agents inside a real organisation	Nothing found

Every row there is either vendor documentation or a named researcher's write-up. The empty last row is the one that shapes the method: with no incident corpus to reason from, the only honest approach is to reason from the defaults and from what a lab has already achieved against them.

The Exposure, Setting By Setting

1. Who gets to start a conversation. The platform ships set to authenticate with Microsoft. Turning that off publishes something anybody holding the link can talk to.
2. What outside wording reaches the model. Knowledge sources, inbound mail triggers and uploaded files all deliver text somebody else chose into the context window. Zenity's page notes that agents "introduce new considerations around access" and data handling, and the runtime decision about that text belongs to the model.
3. Whose access the tools borrow. Out of the box, a connector or flow runs as whoever is chatting. Switch the credential mode across to the builder and every single conversation then executes with the builder's reach, which is the one setting that turns a manipulation into an escalation. The general mechanism sits in our note on how privilege escalates inside an agentic system.
4. How many people can trigger it. A new agent is shared with nobody. Sharing it organisation-wide is a release event wearing the clothes of a settings change.
5. What the tools can actually do. This is the item the defaults do not touch at all, and it is where the most recent research landed.
6. Which routes carry data out. Connectors, HTTP actions and published channels are all exits, and they need to be inventoried as exits.

Microsoft names the underlying problem on its own scan page: secure defaults get changed "for valid scenarios without knowing the risk". The scan raises a flag on three of the six items above. On the other three it is silent.

Which Setting Caps Which Blast Radius

Setting	What holding it buys	Owner	Cost
Authentication stays on	An agent that answers without one should hold no internal tool and no private knowledge source. Read the switch as a request to re-scope the agent, not as a toggle	Maker, admin signs off	Low
Triggers get reviewed	Where an agent is woken by inbound mail, the wording it reads was chosen by a stranger, with nobody present to notice anything odd	Security	Medium
End-user credentials kept	Where maker credentials are genuinely unavoidable, stand up a narrow purpose-built identity, record who owns it, and set the date it gets revisited	Maker and admin	Low
Organisation-wide sharing gated	Three lines before it stays: who owns this, what it reads, what it can change	Agent owner	Low
Write operations scoped to fields	The expensive row, and the one no product default will do on your behalf	Maker	Medium
Data policies on connectors and HTTP actions	Block in the admin centre whatever should never appear inside an agent in the first place	Platform admin	Medium

Ranking tool risk before scoping it is the step teams skip, and our model for tool misuse across agent architectures is the shortest way into that ordering. The third row is also the one that quietly costs the most, for the reasons set out in why least privilege gets harder once an agent holds the credential.

Two Things Changed Since Those Defaults Were Written

One is a product capability. In September 2025 Microsoft put advanced real-time protection during agent runtime into public preview, and the announcement describes an external security system reviewing the agent's planned actions and deciding whether to approve or block them, configured per environment or environment group from the Power Platform Admin Center. Microsoft Defender is the only partner named; third-party providers and custom-built tools are referred to without names. Two operational details belong in any plan built around it. The external system gets one second to answer, and if no answer arrives inside that window the action counts as approved and the agent carries on. The payload sent out to it holds the user's prompt, the chat history, tool details with their input values, and metadata identifying the agent, the user and the tenant.

The other is a research result with a very specific shape. In December 2025 Tenable's research team built a travel booking agent on the platform and reported that a straightforward injection moved it off its own instructions into data disclosure and a fraudulent change. The mechanism is worth more than the headline. A retrieval action meant to fetch a single reservation handed back several once it was asked for several identifiers, and the action meant for editing trip details also reached the price, because edit permission there applied to the price field as well. Fake customer records including card data came out, and the price of a trip went to zero.

None of the three settings the pre-publish scan watches would have prevented that. Authentication was not the weak point, the credentials were not borrowed, and the audience was not wide. The weak point was a tool whose real capability ran wider than its name, which is why Tenable's own remediation list opens with mapping every tool and data store the agent can reach before narrowing write and update capability down to named fields or permitted values. That is a sixth checklist item, and the scan will never raise it.

There is at least somewhere in the product to look now. Microsoft's preview documentation for the Agent status summary describes issues grouped as blocking, warning or informational on the agent's overview page, each row carrying the state it applies to, draft or published or both, and a source such as authentication, models or permissions, with the specific admin policy named for anything blocking. Admins can also set an environment-level plain-text guidance message, capped at 400 characters, so a blocked maker reads your instruction instead of generic advice to contact an admin. Microsoft is explicit in the same documentation that the summary does not replace admin-level governance or compliance reporting.

Fail-Open Monitoring Is Not Where the Money Goes

The runtime protection preview is the thing a vendor will put in front of your security team this year, and it is a real improvement on having nothing. It is still the wrong first purchase, and the vendor's own documentation is what makes that argument. A control working to a one-second budget that treats a missing answer as approval is availability-shaped rather than boundary-shaped: under load, its failure mode is that the agent proceeds. And a control that forwards prompts, chat history and tool input values to an outside system, with that forwarding not configurable, relocates part of your exposure as well as reducing part of it.

Order the work by what survives a slow Tuesday. The six settings above are deterministic and inspectable. An admin can show their current state, put a name against each one, and demonstrate that the state has not drifted, with no model and no network round trip involved. Field-scoped write permission belongs in that same category, and on the published evidence it is the one that actually bit. Buy the runtime integration after that, wire it to an alert queue a human reads, and judge it on whether it tells you which agents are being probed. Hold it to the evidence standard in our piece on the records an agent investigation actually needs.

The conditions that would make this ordering wrong are narrow but real. If the timeout became configurable and failed closed, and the forwarded payload became scoped to what the reviewing system needs, then runtime protection would be a boundary and buying it early would be the correct call. It is also the wrong ordering for an agent that reads only public material, holds no write action and keeps nothing durable. There the blast-radius work is finished before it starts, and detection is genuinely the only lever left worth paying for.

An Afternoon's Inventory

• Enumerate every published agent with a named human beside it. The ones carrying no name go to the top of the queue.
• Sort that list by authentication mode, and re-scope rather than merely review each agent that answers without one.
• Find every connector running on maker-provided credentials. Move it to the end user, or write down the reason it cannot move, who owns the exception, and when it gets looked at again.
• For each agent holding a write action, list the fields that action can change rather than the fields it was built to change. The documented case lived entirely in that gap.
• Anything shared to the whole organisation gets the three-line test before it is allowed to stand, because that share is a release.
• Check in your own tenant which of the two logging surfaces are licensed and switched on: Purview for what makers did, Sentinel for alerting on agent activity. The governance page describes both; it cannot tell you yours are live.
• Open the Agent status summary on your three busiest agents and clear whatever sits at blocking severity.

What None of These Sources Can Tell You

How many tenants are running with the risky settings is not public, and no dataset answers it. Preview availability and fix status both move, so verify the state of runtime protection and of the Agent status summary inside your own environment rather than from any article, including this one. Microsoft has described an Agent 365 control plane that gives agents identities in Entra, which has not been examined here; check what your licence actually covers before planning on it.

The hard limit deserves saying plainly. Each control above narrows the reach of an agent that has already been steered. Not one of them prevents the steering. Microsoft's governance documentation is clear that content moderation addresses predefined harmful-content categories rather than arbitrary tenant-defined conversation blocking, so the pre-publish scan is neither an injection defence nor a review. It fires on a changed default, and it has no opinion at all about whether the sources, tools and instructions you assembled suit the data behind them. A paid layer exists above all of this, covering agent discovery, checks at build time and detection while the agent runs. The Zenity page for this platform says its results are expressed against the OWASP list for language-model applications and against MITRE ATLAS. The only test that matters for any of it: does your inventory get more complete and your detection more specific. Regulated data in scope, a trigger fed from outside, or write access into a payroll, ledger or customer system: any one of those three is the signal to bring in a qualified assessor instead of working from a list.

Questions about securing low-code agents

Is the pre-publish scan a security review?

No. It raises a flag when a secure default gets changed. It takes no position on whether the sources, tools and instructions you assembled are appropriate for the data sitting behind them.

What makes maker-provided credentials the dangerous setting?

Every conversation then runs with the builder's reach rather than the asker's. Steering it then becomes a route into records the asker was never cleared for.

Does the new runtime protection block a bad action?

It can, inside its one-second window. Microsoft's announcement states that a missing answer in that window counts as approval and the agent continues, so plan for the proceed case as the default behaviour under load.

Where does an audit trail come from?

Two surfaces are documented: Purview records what makers did, and Sentinel raises alerts on agent activity. Each depends on licensing and on being switched on, so confirm both in your own tenant rather than assuming them.