Over the past few months I've watched several organizations move Copilot Studio agents from pilot to production. Some did it in a hurry, others took their time. Again and again, Copilot Studio security turned out to be what separated a smooth business rollout from a data governance fire. Switching an agent on and calling it finished is tempting. Once custom knowledge sources, actions and connectors come into play, though, blind spots appear. If you don't stop and check who gets access, which credentials are used and how permissions flow, you're asking for risk and painful audits. Below is the checklist I now work through before any Copilot Studio agent goes live, along with the security and governance features available as of October 2025.

Authentication decides who operates the agent and under which identity

The first question is who may use the agent, and the second is which identity its actions run under. I still come across agents shared with "everyone" or with no access control at all. Scope access with groups or Entra ID roles instead. The stakes go up as soon as actions (Power Automate flows or connectors) are involved. Does the agent run with the user's own permissions, or with the "maker" credentials, which are often overprivileged? Keeping the "user" and "maker" contexts apart in Copilot Studio matters a lot, because actions performed with maker credentials can reach systems that normal users should never touch. The official security and governance docs cover this in detail.

Knowledge source permissions determine how much data an agent can overshare

Hooking agents up to custom knowledge sources (SharePoint, OneDrive, Azure SQL, etc.) gives them a lot of reach, and it makes oversharing easy. For every configured source I document the permissions and review them regularly. Who can actually access each source? Is the agent quietly extending access through special credentials? SharePoint is the tricky one. An agent that pulls data from a site meant only for HR can turn into a serious exposure. I start restrictive and open things up only when there's a need. If you want the full picture of how Copilot Studio agents access and respect permissions on knowledge sources, read Copilot Studio knowledge sources: Permissions, traps, checklist.

Actions and connectors only stay safe with least privilege

Actions and connectors are what make agents useful in the first place. Each "create a file," "update a record" or "trigger a workflow" is also a risk vector. With standard connectors enabled by default, least privilege is not optional. Work out which actions must run in the user's name, which need read access only, and where automation should be blocked altogether. As a maker, don't hand any agent an all-powerful service principal with owner rights. The new Model Context Protocol (MCP) governance features let you define context and permissions far more precisely. The Copilot Studio security scan also now shows risky permissions and configuration issues before you publish.

flowchart TD
  User["User accesses agent"] --> Auth["Authentication (Entra ID)"]
  Auth --> Agent["Copilot Studio agent"]
  Agent --> Knowledge["Access to knowledge sources"]
  Agent --> Actions["Perform actions/connectors"]
  Actions --> Rights["Check permissions (user vs maker)"]

Figure: Security-critical flows for Copilot Studio agents.

Content moderation and XPIA address prompt injection risks like EchoLeak

Copilot Studio now has content moderation built in, yet in real deployments people still underestimate it. Not every prompt is harmless, and since EchoLeak nobody can dismiss prompt injection as theoretical. Microsoft's Cross-Product Injection Assessment (XPIA) points out common dialog flaws, but you should go through its findings yourself before production. The EchoLeak scenario, in which agents leak sensitive data without meaning to, remains a concern. EchoLeak Copilot: Lessons from CVE-2025-32711 for M365 AI has real-world examples and what I took away from them.

Practical tip: Before publishing, test the agent's dialogs properly with adversarial prompts and role-play. What happens when a user tries to coax out sensitive information or slip in system commands? Content moderation and XPIA help, but they don't replace tight permissions and common sense.

Publishing needs a clean security scan, audit logging and a named owner

Before go-live I always look at the security scan results in the agent list. Copilot Studio now displays the security status and flags configuration or permission risks (security scan docs). For agents that combine knowledge sources and actions, these indicators are a good way to catch things you missed. Audit logging is now integrated with Microsoft Purview, so activities such as agent changes, publishing and user interactions are recorded. Just remember to adjust your audit log retention settings in Purview. The admin logging guide lists every field if you need the technical details. One more thing: document who owns each agent and review it regularly. Otherwise you end up with an orphaned agent and nobody accountable for it.

Environments and DLP policies form the control net for agents

Copilot Studio agents technically live in Power Platform environments, but governance at the environment level often gets overlooked. For production, decide where agents are allowed to exist, ideally in a dedicated "Production" environment with restrictive DLP policies. DLP is your backstop when data would otherwise flow into risky connectors or leave the tenant. I've written more about environment and DLP pitfalls in Copilot Studio governance: risks and controls in 2024.

Copilot Studio security takes a team: technical controls, clean permissions and routine reviews all play a part. Working from a structured checklist is the best protection I know against chaos, and I treat it as a prerequisite before I'm comfortable moving any agent to production.