Securing Microsoft Copilot Studio Agents Guide: Connectors, Authentication and DLP

Microsoft Copilot Studio lets any licensed maker build an agent that signs users in, calls hundreds of connectors, reads SharePoint and websites, and reacts to events on its own, and the security of each agent depends on a handful of settings that makers choose, often in the default environment. The questions that matter are concrete: does the agent authenticate users at all, whose credentials do its tools run under, which connectors and channels do Power Platform data policies allow, who can edit or chat with it, and what lands in the audit log. This guide explains how identity, access, connectors, DLP, logging and runtime protection work in Copilot Studio, based on Microsoft Learn documentation, and sets out a hardening baseline and the common misconfigurations. It is for Power Platform administrators, Microsoft 365 security teams and identity architects. Features change frequently; check the Microsoft Learn pages in the references before relying on a setting.

Key takeaways

• Authentication is a per-agent choice. Agents can use No authentication, Authenticate with Microsoft or Authenticate manually; with No authentication anyone with the link can chat, and only a data policy can stop makers choosing it.
• Credentials decide the blast radius. Tools run with each user's own credentials by default, but maker-provided credentials and event triggers run with the maker's connection, so every user or every trigger acts as the maker.
• Data policies are the main tenant control. Power Platform data policies are enforced for all Copilot Studio agents with no exemptions, and can block unauthenticated chat, HTTP requests, individual connectors (including MCP tools), skills, triggers and publishing channels.
• Environments are the security boundary. Build production agents outside the default environment, use environment routing to keep makers out of it, and use Dataverse security roles to control who authors and who reads transcripts.
• Audit and quarantine exist, but you must wire them up. Maker and usage events go to Microsoft Purview audit, runtime threat detection can be added per environment, and admins can quarantine an agent through the Power Platform API.

How identity and access work in Copilot Studio

Three identities are involved in every agent: the end user chatting with it, the maker who built it and owns its connections, and the app registrations that sit behind manual authentication, Direct Line and integrations. Agent authentication is configured under Settings > Security > Authentication and takes effect only after the agent is published.

• Require users to sign in: available only with Authenticate manually. It creates a read-only system topic that triggers for any unauthenticated user; it cannot be switched off when a data policy requires authentication.
• Single sign-on: the Token exchange URL field is required for SSO with manual authentication; Teams deployments follow Microsoft's separate Teams SSO configuration.
• Scopes: Microsoft's guidance is to request only the scopes the agent needs. Manual authentication lets makers request broad delegated permissions, so review the app registration, not just the agent.
• Prefer federated credentials or certificates: manual authentication supports Entra ID V2 with federated credentials and with certificates (certificate loaded from a Key Vault URL), which avoid long-lived client secrets.
• Admin lock: a Power Platform admin control can lock the Authenticate manually option so makers cannot turn it on or off.

Web and Direct Line channel security

Without Require secured access (Settings > Security > Web channel security), anyone who knows the agent ID can connect through the Demo website and Custom website channels. With it on, clients need a Direct Line secret or token. Each agent has two secrets, Secret 1 and Secret 2, so you can swap and regenerate without downtime; regenerating disconnects anything using the old secret. Microsoft's guidance is never to expose the secret in browser code, but to exchange it server side for a conversation token at /v3/directline/tokens/generate. A Direct Line secret authorises channel access only; it does not authenticate the end user. The setting can take up to two hours to apply.

Admin roles and privileged access

Copilot Studio administration is split between tenant roles, environment roles and per-agent sharing. Tenant-level roles do not automatically grant Dataverse data access; a tenant admin also needs System Administrator in the environment to work with its data.

• Co-authors can publish: anyone shared for collaborative authoring can change authentication, add tools and publish. Treat co-author lists as privileged access and review them.
• Transcripts are sensitive data: Bot Transcript Viewer applies across the environment, which is one reason Microsoft suggests separate environments when transcript access must be restricted.
• Chat sharing needs licensing and security groups: sharing for chat works with security-enabled groups, not Microsoft 365 groups where SecurityEnabled is false.
• Flows are separate: sharing an agent does not share its Power Automate flows, so ownership of flows used as tools needs its own review.

Environments as the boundary

Copilot Studio creates a default environment when a user first builds an agent, and Microsoft recommends a non-default production environment for production agents. Trial environments expire after 30 days and their agents are deleted. Managed Environments add controls including limit sharing, default environment routing (sending makers to a designated environment instead of the default one), maker welcome content, IP firewall, IP cookie binding, customer managed keys, pipelines and solution checker. Copilot Studio's security overview also lists a tenant-wide setting to disable publishing of generative AI agents.

Integrations, API tokens and service accounts

Every tool an agent uses runs through a connection, and the credential mode of that connection is the most important security decision after authentication.

Maker-provided connections and trigger connections are non-human access in practice: a person's account is being used as a service account for an unbounded set of users. Where an agent genuinely needs shared access, use a dedicated account or app identity with its own owner and review, not a maker's everyday account. Connections can be shared with "Can use + share" permission, which spreads that access further. See the Low-Code Agent Platforms Guide for the general pattern across platforms.

Data policies (DLP) for agents

Power Platform data policies (Power Platform admin center > Security > Data and privacy > Data policy) have been enforced for all Copilot Studio tenants since early 2025, and agent exemptions are no longer supported. Connectors sit in Business, Non-business or Blocked groups, and an agent cannot combine connectors from different groups. The Copilot Studio-specific connectors make most agent capabilities controllable:

• Chat without Microsoft Entra ID authentication in Copilot Studio: block it to force authenticated agents.
• HTTP: block it, or use endpoint filtering to allow named endpoints. Endpoint filtering also applies to SharePoint and public website knowledge sources.
• Skills with Copilot Studio: blocks Azure Bot Service skills.
• Channel connectors: Microsoft Teams + M365 Channel, Direct Line channels (allowed by default, covering demo and custom websites), Facebook, Omnichannel, SharePoint and WhatsApp channels in Copilot Studio. If no unblocked channel exists, the agent cannot be published.
• Microsoft Copilot Studio: blocks event triggers and automated evaluations that run with authenticated accounts.
• Application Insights in Copilot Studio: controls telemetry export.

Violations show in real time: the Publish button is unavailable and a downloadable list of violations appears. See the Generative AI Data Loss Prevention Guide for content-level controls beyond connector policy.

Logging and detection

Copilot Studio writes administrative events to Microsoft Purview audit by default; Microsoft states this logging cannot be switched off for Copilot Studio itself, though tenant-wide audit settings and retention apply. Logging is not available for FedRAMP tenants. Events can be pulled programmatically through the Office 365 Management API, and Microsoft lists Sentinel monitoring of agent activity among its governance controls.

Runtime protection

Microsoft states that generative agents block user prompt injection (UPIA) and cross-domain prompt injection (XPIA) by default. Admins can add an external threat detection provider, Microsoft Defender or a custom or third-party service, per environment under Security > Threat detection in the Power Platform admin center. Before each tool call the agent sends the prompt, recent history, previous tool outputs and the proposed tool call to the provider, which returns allow or block. This is in preview, applies only to agents using generative orchestration, must be enabled for each environment separately, and defaults to allowing the call if no answer arrives within one second unless error behaviour is set to Block the query. Setup uses an Entra app registration with a federated identity credential, not a secret.

Containment

The Power Platform API exposes botQuarantine, SetAsQuarantined and SetAsUnquarantined for an agent. A quarantined agent stays visible to makers and testable, but no one can use it in any channel. Callers need Global Administrator, AI administrator or Power Platform administrator and a token for an app with the CopilotStudio.AdminActions.Invoke scope; classic chatbots are not supported. Build this into the incident playbook before you need it. Relevant ATT&CK and ATLAS techniques include T1528 Steal Application Access Token, T1566.002 Spearphishing Link, AML.T0051.001 Indirect LLM Prompt Injection and AML.T0086 Exfiltration via AI Agent Tool Invocation.

Hardening baseline

1. Inventory first: list agents per environment (the CoE Starter Kit has a Copilot Studio dashboard), their authentication mode, channels, connectors, credential modes and owners.
2. Route makers away from the default environment: enable default environment routing and create development, test and production environments, with production built from solutions and pipelines.
3. Stage data policy changes: data policies have no report-only mode and enforcement is real time, so draft the policy, use the CoE data and downloaded violation lists to find affected agents, warn makers, then apply. Block Chat without Microsoft Entra ID authentication, HTTP (or filter endpoints), Skills with Copilot Studio and unneeded channels.
4. Decide trigger policy: block the Microsoft Copilot Studio connector in environments where autonomous agents are not approved; allow it only in a governed environment.
5. Require web channel secured access for any agent on Direct Line, with server-side token exchange.
6. Replace maker-provided credentials on sensitive connectors with user credentials, or with a dedicated least-privilege account that has an owner.
7. Restrict sharing: use security groups for chat sharing, limit sharing in Managed Environments, and review co-authors.
8. Turn on monitoring: forward Purview Copilot Studio events to your SIEM and add threat detection in production environments.
9. Test and roll back: pilot policies in one environment, and keep the previous data policy version documented so a blocking change can be reversed quickly.

Small tenants may manage with a single tenant-wide data policy and one production environment; large tenants usually need environment groups with policies per stage and a named platform owner. Tie consent controls to this work: the Entra ID user consent policy and app registration settings decide what a malicious agent could obtain. See the Consent Phishing and Illicit OAuth Grants Guide.

Framework mapping

Common misconfigurations

• Public demo websites on Microsoft domains: in CoPhish, Datadog Security Labs showed a Copilot Studio agent's demo website, served from a genuine Microsoft domain, with a login topic pointed at an OAuth consent prompt and a topic forwarding the resulting token. Block Direct Line channels where not needed, restrict user consent and monitor BotComponentUpdate on login topics.
• No authentication on internal agents: an agent built for staff left on No authentication can be used by anyone with the link.
• Maker credentials on powerful connectors: an agent connected to SharePoint, Dataverse or a mailbox with the maker's credentials gives every chat user the maker's access.
• Autonomous agents reading external content: triggers on inbound email with maker credentials and write tools let external senders influence actions. The EchoLeak flaw affected Microsoft 365 Copilot rather than Copilot Studio, but it shows how a crafted email retrieved as context can push an assistant to leak data.
• Everything in the default environment: every licensed user can build there, transcripts sit alongside unrelated agents, and production agents share policy with experiments.
• Threat detection enabled once: runtime protection has no tenant-wide switch, so new environments are left unprotected unless setup is part of environment creation.

Practitioner checklist

• Block Chat without Microsoft Entra ID authentication in Copilot Studio in every environment that does not host approved public agents.
• Enable default environment routing and move production agents to managed, non-default environments.
• Block or endpoint-filter the HTTP connector, and block Skills with Copilot Studio and unneeded channel connectors.
• Review every agent using maker-provided credentials or event triggers, and assign a dedicated least-privilege account where shared access is justified.
• Require web channel secured access and keep Direct Line secrets server side, with a rotation process.
• Prefer federated credentials or certificates over client secrets for manual authentication app registrations.
• Restrict Bot Transcript Viewer and co-author access, and review agent sharing quarterly.
• Forward Purview Copilot Studio audit events to the SIEM and alert on BotAuthUpdate, BotShare and BotPublish in production.
• Enable external threat detection per production environment with Block the query as error behaviour, after testing latency.
• Script and test agent quarantine through the Power Platform API as part of incident response.

Standards and references

• Microsoft Learn: Configure user authentication in Copilot Studio
• Microsoft Learn: Configure data policies for agents
• Microsoft Learn: Security and governance in Copilot Studio
• Microsoft Learn: View audit logs for Copilot Studio
• Microsoft Learn: Event triggers in Copilot Studio
• Microsoft Learn: External threat detection for Copilot Studio agents
• Microsoft Learn: Share agents with other users
• OWASP: Top 10 for LLM Applications 2025

Related NHI Mgmt Group resources: Low-Code Agent Platforms Guide · Enterprise AI Copilot Security Guide · Microsoft 365 Security Guide · Agentic AI Security Guide