How Microsoft Copilot Studio Creator Permissions Expand the Blast Radius of Prompt Injection Attacks
Published
Question: What permissions are organizations giving Microsoft Copilot Studio AI agents today in terms of read access, write access, workflow execution rights, and delegated identity permissions, and what is the potential blast radius if those privileges are abused? Also, what logging, segmentation, or approval workflows are currently missing in most deployments?
Simon Maxwell-Stewart, Staff Cyber Security Researcher at BeyondTrust
Most organizations are handing these agents a broader set of permissions than they realize, because the access is assembled quietly through the agent's tools, knowledge, and identity rather than granted in one obvious step.
On the read side, agents are pointed at business knowledge sources and given file analysis and search over that content. On the write and execution side, the majority are enabled for generative actions and wired to connectors and cloud flows, which lets them call out to other systems and trigger automations.
The piece that matters most is delegated identity:
- Copilot Studio defaults to the creator's own credentials for a tool's connection.
- So the agent typically acts with the maker's access rather than the access of whoever is actually chatting with it.
That delegation is where the blast radius comes from. The connectors in play reach across the everyday Microsoft estate:
- mail,
- files,
- directory,
- collaboration,
- And into the major SaaS platforms used for CRM
- IT service management,
- source control, and
- developer workflows.
- And into the major SaaS platforms used for CRM
Because the agent runs on maker credentials, its effective reach is the maker's reach, which is often far higher than the people consuming the agent.
Once an agent is published to a channel such as Teams, a lower privileged user can reach a higher privileged agent, which is the lateral movement path.
Indirect prompt injection through
- web content,
- documents, or
- tool responses
- are the trigger that turns all of that read and action capability against the organization, since the agent will faithfully follow instructions it encounters while doing its job.
The controls that would contain this are usually the ones missing, and they are missing for a simple reason: they are all opt-in.
Connector segmentation through Data Loss Prevention (DLP) policies is frequently absent,
- so any agent can combine any connectors.
Environments tend to be left unmanaged, and their creation is rarely gated by approval,
- which is how shadow agents proliferate without oversight.
Auditing at the data layer is not consistently turned on,
- so there is little visibility into what an agent or its connections actually did.
And maker credentials remain the default,
- so least privilege is the exception rather than the rule.
None of these are exotic misconfigurations. They are the platform's out-of-the-box posture, which is exactly why the same gaps show up almost everywhere unless someone deliberately closes them. That deliberate
- Hardening,
- Segmenting connectors,
- Requiring managed environments and approvals,
- Enabling audit, and
- Replacing maker credentials with least-privilege identities is the work that actually shrinks the blast radius
Related
