Copilot Studio agents are becoming a core part of business workflows- automating tasks, accessing data, and interacting with systems at scale. That power cuts both ways. In real environments, we repeatedly see small, well‑intentioned configuration choices turn into security gaps: agents shared too broadly, exposed without authentication, running risky actions, or operating with excessive privileges. These issues rarely look dangerous- until they are abused.
Top 10 risks you can detect and prevent
Imagine this scenario: A help desk agent is created in your organization with simple instructions.
The maker, someone from the support team, connects it to an organizational Dataverse using an MCP tool, so it can pull relevant customer information from internal tables and provide better answers. So far, so good.
Then the maker decides, on their own, that the agent doesn’t need authentication. After all, it’s only shared internally, and the data belongs to employees anyway (See example in Figure 1). That might already sound suspicious to you. But it doesn’t to everyone.
You might be surprised how often agents like this exist in real environments and how rarely security teams get an active signal when they’re created. No alert. No review. Just another helpful agent quietly going live.
Now here’s the question: Out of the 10 risks described in this article, how many do you think are already present in this simple agent?
1: Agent shared with the entire organization or broad groups
Sharing an agent with your entire organization or broad security groups exposes its capabilities without proper access boundaries. While convenient, this practice expands the attack surface. Users unfamiliar with the agent’s purpose might unintentionally trigger sensitive actions, and threat actors with minimal access could use the agent as an entry point.
In many organizations, this risk occurs because broad sharing is fast and easy, often lacking controls to ensure only the right users have access. This results in agents being visible to everyone, including users with unrelated roles or inappropriate permissions. This visibility increases the risk of data exposure, misuse, and unintended activation of sensitive connectors or actions.
2: Agents that do not require authentication
Agents that you can access without authentication, or that only prompt for authentication on demand, create a significant exposure point. When an agent is publicly reachable or unauthenticated, anyone with the link can use its capabilities. Even if the agent appears harmless, its topics, actions, or knowledge sources might unintentionally reveal internal information or allow interactions that were never for public access.
This gap appears because authentication was deactivated for testing, left in its default state, or misunderstood as optional. The results in an agent that behaves like a public entry point into organizational data or logic. Without proper controls, this creates a risk of data leakage, unintended actions, and misuse by external or anonymous users.
3: Agents with HTTP request action with risky configurations
Agents that perform direct HTTP requests introduce a unique risks, especially when those requests target non-standard ports, insecure schemes, or sensitive services that already have built in Power Platform connectors. These patterns often bypass the governance, validation, throttling, and identity controls that connectors provide. As a result, they can expose the organization to misconfigurations, information disclosure, or unintended privilege escalation.
These configurations appear unintentionally. A maker might copy a sample request, test an internal endpoint, or use HTTP actions for flexibility during testing and convenience. Without proper review, this can lead to agents issuing unsecured calls over HTTP or invoking critical Microsoft APIs directly through URLs instead of secured connectors. Each of these behaviors represent an opportunity for misuse or accidental exposure of organizational data.
4: Agents capable of email-based aata exfiltration
Agents that send emails using dynamic or externally controlled inputs present a significant risk. When an agent uses generative orchestration to send email, the orchestrator determines the recipient and message content at runtime. In a successful cross-prompt injection (XPIA) attack, a threat actor could instruct the agent to send internal data to external recipients.
A similar risk exists when an agent is explicitly configured to send emails to external domains. Even for legitimate business scenarios, unaudited outbound email can allow sensitive information to leave the organization. Because email is an immediate outbound channel, any misconfiguration can lead to unmonitored data exposure.
Many organizations create this gap unintentionally. Makers often use email actions for testing, notifications, or workflow automation without restricting recipient fields. Without safeguards, these agents can become exfiltration channels for any user who triggers them or for a threat actor exploiting generative orchestration paths.
5: Dormant connections, actions, or agents within the organization
Dormant agents and unused components might seem harmless, but they can create significant organizational risk. Unmonitored entry points often lack active ownership. These include agents that haven’t been invoked for weeks, unpublished drafts, or actions using Maker authentication. When these elements stay in your environment without oversight, they might contain outdated logic or sensitive connections That don’t meet current security standards.
Dormant assets are especially risky because they often fall outside normal operational visibility. While teams focus on active agents, older configurations are easily forgotten. Threat actors, frequently target exactly these blind spots. For example:
- A published but unused agent can still be called.
- A dormant maker-authenticated action might trigger elevated operations.
- Unused actions in classic orchestration can expose sensitive connectors if they are activated.
Without proper governance, these artifacts can expose sensitive connectors if they are activated.
6: Agents using author authentication
When agents use the maker’s personal authentication, they act on behalf of the creator rather than the end user. In this configuration, every user of the agent inherits the maker’s permissions. If those permissions include access to sensitive data, privileged operations, or high impact connectors, the agent becomes a path for privilege escalation.
This exposure often happens unintentionally. Makers might allow author authentication for convenience during development or testing because it is the default setting of certain tools. However, once published, the agent continues to run with elevated permissions even when invoked by regular users. In more severe cases, Model Context Protocol (MCP) tools configured with maker credentials allow threat actors to trigger operations that rely directly on the creator’s identity.
Author authentication weakens separation of duties and bypasses the principle of least privilege. It also increases the risk of credential misuse, unauthorized data access, and unintended lateral movement
7: Agents containing hard-coded credentials
Agents that contain hard-coded credentials inside topics or actions introduce a severe security risk. Clear-text secrets embedded directly in agent logic can be read, copied, or extracted by unintended users or automated systems. This often occurs when makers paste API keys, authentication tokens, or connection strings during development or debugging, and the values remain embedded in the production configuration. Such credentials can expose access to external services, internal systems, or sensitive APIs, enabling unauthorized access or lateral movement.
Beyond the immediate leakage risk, hard-coded credentials bypass the standard enterprise controls normally applied to secure secret storage. They are not rotated, not governed by Key Vault policies, and not protected by environment variable isolation. As a result, even basic visibility into agent definitions may expose valuable secrets.
8: Agents with model context protocol (MCP) tools configured
AI agents that include Model Context Protocol (MCP) tools provide a powerful way to integrate with external systems or run custom logic. However, if these MCP tools aren’t actively maintained or reviewed, they can introduce undocumented access patterns into the environment.
This risk when MCP configurations are:
- Activated by default
- Copied between agents
- Left active after the original integration is no longer needed
Unmonitored MCP tools might expose capabilities that exceed the agent’s intended purpose. This is especially true if they allow access to privileged operations or sensitive data sources. Without regular oversight, these tools can become hidden entry points that user or threat actors might trigger unintended system interactions.
9: Agents with generative orchestration lacking instructions
AI agents that use generative orchestration without defined instructions face a high risk of unintended behavior. Instructions are the primary way to align a generative model with its intended purpose. If instructions are missing, incomplete, or misconfigured, the orchestrator lacks the context needed to limit its output. This makes the agent more vulnerable to user influence from user inputs or hostile prompts.
A lack of guidance can cause an agent to;
- Drift from its expected behaviors. The agent might not follow its intended logic.
- Use unexpected reasoning. The model might follow logic paths that don’t align with business needs.
- Interact with connected systems in unintended ways. The agent might trigger actions that were never planned.
For organizations that need predictable and safe behavior, behavior, missing instructions area significant configuration gap.
10: Orphaned agents
Orphaned agents are agents whose owners are no longer with organization or their accounts deactivated. 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.
Because ownerless agents bypass standard review cycles, they often contain outdated logic, deprecated connections, or sensitive access patterns that don’t align with current organizational requirements.
