Copilot Studio Agent Security misconfigurations
While May 1st marks the GA of the Microsoft 365 E7 license, which includes the Agent 365 license (advanced Entra, Defender and Purview features for agents). Although I see the technical & security value of the license(s) above, from a business and financial justification not all organizations can or want to invest in this new license from the start, while still wanting to secure their AI agents as much as possible.
This blog explains baseline security settings for Microsoft Copilot Studio agents. It focuses only on basic security features and/or security misconfigurations, it does not cover the advanced capabilities included in the Agent 365 / Microsoft 365 E7 license, unless explicitly stated otherwise.
Blog contents:
- Maker Credentials
- Authentication
- Sharing
- Send Mail
- HTTP Requests
- Hard-coded credentials
- Dormant Agents
- Orphaned agents
- Audit (the above)
Agent Attack Surface
Before we dive into the topics above, first explain the attack surface of agents. Copilot Studio agents consist of three main components:
- Topics
Topics define the conversation logic and orchestration rules of the agent.
⚠️The attack surface risks are: prompt injection, unsafe orchestration and embedded secrets. - Tools
Tools allow the agent to interact with external systems.
⚠️The attack surface risks are: privilege escalation, data exfiltration and connector governance bypass. - Knowledge Sources
Knowledge sources provide data used by the agent to generate answers. ⚠️The attack surface risks are: sensitive information exposure, indirect prompt injection and data oversharing.
The security of a Copilot Studio agent is determined by the combination of Topics, Tools and Knowledge Sources. Topics define the agent’s logic, tools define what actions it can perform, and knowledge sources define what data it can access. Misconfigurations in any of these components can expose sensitive data, allow unauthorized actions, or increase the attack surface of the agent.
Maker Credentials
When a user creates an agent in Copilot Studio, they can add tools (e.g. connectors or MCP Servers) that require authentication using their own user credentials to access services such as Microsoft SharePoint, Microsoft Teams or Office 365 Outlook.
This behavior is similar to application delegation in App Registrations.
When another user interacts with the agent, the agent authenticates with connected services using the maker’s credentials, not the end user’s credentials.
This can be intentional for autonomous agents, such as scheduled or trigger-based agents.
⚠️Risk
Any end user who interacts with the agent leverages the maker’s access permissions. This can lead to data oversharing, where users may retrieve sensitive information they would not normally have access to.
✅Mitigation
Power Platform admins can disable the use of maker-provided credentials per environment in the Power Platform admin center. This ensures that only end-user credentials are used for authentication.
This feature is not enabled by default.
Once enforced, agents that use tools or MCP servers to access resources require real-time authentication from the end user.
As a result, true autonomous agents will fail due to missing credentials.
Authentication
Agents can be configured with one of the following authentication options.
- No authentication (🔴high risk)
The agent does not verify the identity of the user - Authenticate with Microsoft (🟢no risk - default)
The agent authenticates with Entra ID, this authentication method is used for the Microsoft 365 Channels with user-level permissions. - Authenticate manually (🟡risk depends on the method)
The agent uses custom authentication (e.g. 🟢Federated Identity Credentials (FIC), 🟢certificates or 🔴client secrets) to access application-level (e.g. Microsoft Graph API) permissions. This method is used for third-party channels.
⚠️Risk
The No authentication option means the agent does not require user authentication. This configuration is often used for classic chatbots. Anyone with the link can access the agent and any data it exposes.
Even if the agent appears harmless, its topics, actions, or knowledge sources might unintentionally reveal internal information or allow interactions that were never intended for public access.
✅Mitigation
In Managed Environments (Power Platform admin center), admins can create a Data Policy to Block the connector Chat without Microsoft Entra ID authentication in Copilot Studio to disallow the authentication option: No authentication in Copilot Studio agents (in that specific environment).
Create a dedicated environment for agents that do need the No authentication setting like chatbots
Agents configured with No authentication cannot be published to Microsoft 365 channels. Publishing to these channels requires Authenticate with Microsoft.
Copilot Studio automatically runs a security scan and warns makers before publishing (e.g., to a website) when authentication is set to No authentication.
Sharing
When a maker publishes a Copilot Studio agent, they can share it with specific users, security groups, or (using a single toggle) the entire organization.
⚠️Risk
The core problem is blast radius. When an agent is shared org-wide:
- Every employee can interact with it, including those who have no legitimate business need
- Any data the agent can reach (see previous topic ) is indirectly accessible to the entire org through the agent’s responses
- If the agent runs on maker credentials (see previous topic), the maker’s privileges are effectively extended to the whole organization
The risk compounds with other misconfigurations. An unauthenticated agent shared org-wide is essentially a public endpoint into your internal data.
✅Mitigation
In Managed Environments (Power Platform admin center), admins can set sharing limits. For example, they can restrict agents to a maximum number of recipients or prevent sharing beyond a defined security group.
The following sharing options are available in the Manage sharing configuration.
Send E-mail
The Send an email tool via the Office 365 Outlook (or Gmail, SMTP, etc.) connector, allows agents to send an e-mail as part of the workflow.
The agent determines the recipient and content at runtime, based on its generative orchestration or topic logic.
⚠️Risk
Agents that send emails present a significant security risk. When an agent uses generative orchestration to send email, the orchestrator determines the recipient and message content at runtime. In a direct or indirect prompt injection attack, a threat actor could instruct the agent to send internal data to external recipients.
A well-known example is the first zero-click exploit, named EchoLeak (CVE-2025–32711).
✅Mitigation
There are several mitigation strategies:
0. Block the Send an email (V2) in the Office 365 Outlook connector via the Data protection and privacy -> Advanced connector policies
This option is only available for Environment Groups
1. Hard-coded e-mail address
Using a hard-coded email address can reduce the risk of sensitive data being sent outside the organization to unauthorized recipients.
2. Human in the Loop
Power Automate flows can be used as a human-in-the-loop control, allowing a user to approve or reject emails before they are sent.
3. Responsible AI
Responsible AI provides built-in safeguards and governance principles to help ensure AI agents cannot be abused.
4. Real-time protection during agent runtime [⚠️E7]
Real-time protection during agent runtime [Agent 365 / M365 E7 feature] protects, more details in this blog.
Real-time protection during agent runtime in Microsoft Defender reduces risk by protecting against [in]direct prompt injection attacks by inspecting tool invocations in the prompt before the agent runs any actions.
HTTP Requests
External REST APIs can be used by Copilot Studio agents via the HTTP request node to retrieve data from an external system via an API call.
Authorization: Bearer <your_token>Required is the URL (API endpoint), Method, Headers and body (which can contain the authorization headers with the Bearer Token⚠️).
⚠️Risk
The risks are credential exposure (see also the next item), bypassing connector governance** and excessive privileges (which can lead to data oversharing).
** HTTP requests are only advised when no connector exists.
✅Mitigation
Whenever possible, use built-in connectors instead of HTTP requests.
The security benefits are:
- Secure authentication
Built-in connectors manage authentication through Microsoft Entra ID or secure OAuth flows instead of requiring makers to manually handle credentials. - DLP enforcement
Power Platform connectors are governed by DLP policies (classify connectors Business / Non-Business / Blocked, prevent sensitive data from flowing to external services, etc.) - Better auditing
Built-in connectors provide better logging and observability compared to raw HTTP requests (connector usage, user or agent invocation, configured connections, etc.) - Simplified configuration
Built-in connectors abstract away the complexity of API integrations.
Hard-coded credentials
Agents can embed credentials in Topics or Actions.
POST https://api.finance-app.com/getdata
Headers:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Examples include:
- API keys inside HTTP headers
- Bearer tokens inside a request
- Username/password in a request body
- Database connection strings
- Azure service credentials stored as text
⚠️Risk
1. Credential Exposure via Agent Logic Topics and Actions in Copilot Studio are often visible to agent editors, reviewers, or admins — meaning secrets aren’t protected at rest.
2. Overly Broad Access AI agent credentials are typically service accounts with wide permissions, so a single leaked key can grant disproportionate access.
3. No Rotation Lifecycle Hard-coded credentials tend to never get rotated, meaning a leaked secret stays valid indefinitely.
4. Blast Radius via Agent Sharing If an agent is exported, duplicated, or shared across tenants, embedded credentials travel with it silently.
✅Mitigation
Avoid embedding credentials directly in agent logic. Store secrets in Azure Key Vault, use secure inputs, or leverage connectors with managed authentication.
Dormant Agents
Dormant (not used for a long time) Agents often lack active ownership, without oversight they might contain risk.
⚠️Risk
The Power Platform, IT and/or Security teams often focus on Active agents. Threat actors frequently target these blind spots in the organization.
✅Mitigation
Governance of Agents, Connections and Actions is required to keep the environment clean and secure.
Regularly use the Power Platform Inventory to govern the environment and monitor agent usage across all environments.
Agents can be disabled in the Entra Agent ID portal, where availability is limited and the impact is assessed.
Orphaned agents
Orphaned agents are agents whose owners are no longer with the organization or their accounts deactivated.
⚠️Risk
Without a valid owner, no one is responsible for oversight, maintenance, updates, or lifecycle management. These agents might continue to run, interact with users, or access data without an accountable individual ensuring the configuration remains secure.
✅Mitigation
Regularly use the Power Platform Inventory to govern the environment and monitor valid Owner(s) across all environments.
The example above are agents where the owner is deleted from Entra ID.
Audit | AI Agent Inventory [⚠️E7]
Microsoft Defender has a feature called AI Agents Inventory, this feature can be used for periodic audits of all the (mis)configuration described above (and more).
See my previous blog for more details on deployment and usage.
This features is included in the Agent 365 or Microsoft 365 E7 license and after writing this blog one of the best features I come across to secure AI Agents.
I hope this blog gives some insights in how to better secure Microsoft Copilot Studio agents.
