Securing Copilot Studio agents with DLP and compliance controls

How do Copilot Studio agents differ from what we usually call “AI”? We are so used to it taking the guise of a chatty entity that hides behind a minimalistic interface, speaks in familiar structures, and leaves a cliffhanger at the end of each phrase to keep you engaged. 

Copilot Studio agents, however, can do much more than that: query, retrieve, and even modify your enterprise data. They can be integrated with Dataverse, Dynamics 365, Microsoft Graph, custom APIs and can act autonomously within those environments. However, with great power comes great responsibility. Having an AI agent access sensitive data introduces new risks, ranging from accidental data leaks to malicious prompt injections. And since this is rather new technology, traditional security models don’t fully address these issues.  

In this article, we explore real-world risk scenarios and outline specific measures you can apply today. We also cover compliance considerations and monitoring strategies to achieve safe, auditable AI. Finally, we summarize design best practices and provide a checklist for production readiness. Let’s get started! 

Highlights

• Explore real-world risk scenarios for AI in Power Platform 
• Enforce strong identity with Entra ID
• Apply least-privilege access across environments
• Scope connectors to control data exposure
• Use Power Platform DLP (Data loss prevention) as key guardrails
• Address compliance requirements (GDPR, data residency, audit logs)
• Implement monitoring with Purview, Sentinel, and Defender for Cloud
• Achieve safe, transparent, and auditable AI operations

Risk management and mitigation

As mentioned earlier, AI technologies are relatively new in the mass market. Businesses are actively implementing it to their processes and figuring out the best ways it works for them. And, just like anything new and evolving, AI agents can be misused or misconfigured in surprising ways. The table below summarizes some of the most common misuse scenarios along with preventive measures: 

Each of the above mitigations is actionable today using built-in Power Platform features or Microsoft security tools. In the sections below, we unpack how to implement these: from identity controls to DLP policies to monitoring. 

1. Identity & access control

• Enforce Entra ID identities. Copilot Studio agents run under identities managed in Azure AD. Agents use “non-human” identities to call Microsoft Graph and connectors. It’s crucial to treat these identities like service accounts: tightly control their lifecycles. For example, Copilot Studio can automatically create a federated identity credential for each agent (no stored secrets, short-lived tokens). Make sure only authorized admins can publish agents and restrict who can create and deploy agents at the tenant level. 

• By default, “Authenticate with Microsoft” is turned on for new agents. This means the agent enforces sign-in by Microsoft Entra ID. Agent makers can override this to “No authentication,” which effectively makes the agent public. To block that, create a Power Platform data policy that blocks the “Chat without Microsoft Entra ID authentication” connector. Once that policy is in place, any agent must require Microsoft login (teams, SharePoint, Power Apps, etc.) before use. 

• Review each agent’s permissions. Does it need all Graph scopes (Mail. Read, User. ReadWrite, etc.)? Limit to just the ones necessary for its tasks. Similarly, for custom connectors or API calls, only add necessary OAuth scopes. Restrict agents so they can only see & do what’s needed for their specific job. For example, if an agent only updates Dynamics 365 records, don’t give it SharePoint read access. 

• Use Entra ID Identity Governance to manage these non-human identities. Review app registrations, rotate secrets and federated credentials, and retire unused agents. In other words, guard against non-human identity sprawl: periodically audit service principals created by Copilot, remove stale tokens, and reassign ownership if a maker leaves. 

In summary, treat agents like apps: restrict who can publish them, require Azure AD sign-in for users, and scope their permissions narrowly (use security roles and environment roles). 

2. Data access & boundaries 

Once identity is locked down, what data an agent can touch must be controlled: 

• Dataverse table and record security. Copilot agents often use Dataverse for knowledge or workflows, which has a rich role-based model. Assign security roles to limit which tables (entities) the agent can read or write. For instance, give the agent read-only access to certain tables if it only needs to generate reports. If it must write, grant only the specific table-create or update rights needed. 

• Row-level security. If your data requires extra partitioning, use Dataverse’s hierarchical or field-based security. For example, only allow the agent to act on records owned by a specific team (create a team, assign the agent’s identity, and a security role scoped to that team or BU). 

• Environment separation. Copilot Studio agents are built and hosted in Power Platform environments. This allows you to use separate environments for development, testing, and production. In the Power Platform admin center, restrict who can create environments and what data they contain. This way, even if an agent is misbehaving, it’s contained in a non-critical environment. 

• Connectors scope. Limit Dataverse connector usage to certain tables using solution or endpoint filtering. For non-Microsoft connectors (Salesforce, HTTP), treat them with even more caution. By default, any new or custom connector falls into a “Non-business” group, which your DLP may block. If you trust a connector, explicitly put it in “Business”. Otherwise, block or monitor it. 

In short, control the data boundaries around the agent: use Dataverse RBAC (tables, roles, business units), separate environments for life-cycle stages, and carefully assign connector scopes. 

3. Connector governance 

Connectors are both the most powerful and most dangerous tools in an agent’s belt at the same time. They define external actions and data flows, so govern them strictly: 

• Use built-in certified connectors when possible. Microsoft’s certified connectors (Graph, Outlook, SharePoint, Dataverse, etc.) are security-reviewed. Custom connectors can call any API, so they require extra care. If you must use a custom or premium connector, pay extra attention to its security. 

• Limit connector scope and endpoints. Restrict usage even within a connector (SharePoint, for instance). If an agent only needs one SharePoint site, use the “endpoint filtering” setting to whitelist that site only. Similarly, block broad connectors like “public websites” or “documents” unless necessary. 

• Avoid “god-mode” connectors. A pitfall is using an agent as a proxy to write to any system (Dynamics, ServiceNow, etc.). Instead, provide only the specific “create record in X” or “send email via Graph” actions. For example, do not allow the agent to create or delete Dataverse solutions if it only needs to add rows. 

Ultimately, any connector that can leave the tenant (like public web or external API calls) should be treated as untrusted unless explicitly approved. Power Platform DLP policies that are described in the next section of this article can help you to codify these connector rules across agents and flows. 

4. Data loss prevention (DLP)

Data policies in Power Platform are your AI guardrails. They ensure that data doesn’t flow to unauthorized connectors or cross organizational boundaries. Copilot Studio fully respects these policies in real time. If an agent tries to connect to a blocked connector, the action fails with an error. Below, you will find the key steps to establishing a secure environment: 

• Define connector groups. In the Power Platform admin center under Security > Data policies, classify each connector type (Copilot connectors included) into Business, Non-business, or Blocked categories.  
  For example, SharePoint, Dynamics, Teams can go to Business; generic HTTP and “public websites” to Non-business or Blocked. The rule is: connectors in different groups cannot share data. So a Business connector cannot pass data to a Non-business one. 

• Block Non-business connectors by default. Many tenants configure DLP to automatically block connectors in the “Non-business” group. That means any unknown or new connector will be blocked until an admin moves it to Business. Copilot Studio honors this: if an agent uses a blocked connector, the maker or user sees an immediate error.  

• Use data policies to enforce authentication. As mentioned earlier, configure a policy that blocks the “Chat without Microsoft Entra ID” connector. Similarly, you can block the ChatGPT (if present) or other unregulated channels. 

• Prevent cross-tenant flows. If you have multiple environments or tenants, use DLP to separate them. For instance, block your internal Dataverse connector from moving data to any external REST API by placing them in different groups. 

• Business vs. Non-business isolation. Remember: a Business connector can only be used with other Business connectors in the same app or agent. So, if you do need to allow, say, Teams and Graph to work together, put both in Business. By contrast, if you put an external Salesforce connector into Non-business, any attempt to mix that with Dataverse will be blocked. 

In summary, treat DLP as a must-have enabler. It’s all about preventing accidental or malicious data exfiltration. With a well-defined DLP policy, you ensure that Copilot agents can’t slip data from critical systems to unapproved destinations.  

5. Compliance & regulatory considerations

AI agents don’t exempt you from GDPR, HIPAA, or other compliance rules, but rather extend your data processing. Here are some ways Microsoft supports compliance for Copilot agents, and what you should do: 

• GDPR & data subject rights. Copilot Studio is designed to comply with GDPR: you can keep data within regional boundaries and handle subject requests. If agents process personal data, treat the conversation as personal data. Ensure you have processes to delete logs or transcripts on request and perform Data Protection Impact Assessments (DPIAs) for high-risk agents. 

• Data residency. Copilot Studio allows you to choose the Azure region where your tenant data is stored. For EU customers, the EU Data Boundary feature ensures data stays in EU/EFTA regions. As a control, you can disable cross-region data moves if needed.  

• Regional enforcement. Microsoft offers a toggle to disable data movement across geographic locations for Copilot generative features. If your compliance policy forbids data leaving Europe, it is advised to turn this option on. Otherwise, by default Copilot Studio may run some AI services in the “closest” Azure region. 

• Sensitivity labels and purview categories. If your organization uses Microsoft Purview Data Loss Prevention or Information Protection labeling, you can extend this to Copilot. For example, when an agent uses a SharePoint source, the labels on those documents can influence what the agent can output. Train agents or use policies to respect data classification. 

• General compliance. Copilot Studio supports many standards (ISO, SOC, and many others) like the rest of Power Platform. Review the Microsoft Trust Center for specific certifications. But remember, using the tool doesn’t guarantee compliance. It remains your responsibility to configure it correctly. 

6. Monitoring, auditing & observability

You can’t secure what you can’t see. Establish an observability layer for your agents: 

• Audit logs (Purview). As mentioned, Copilot Studio logs all admin and user actions in Microsoft Purview. This includes who published an agent, updated its permissions, and which user chatted with it (but transcripts are separately accessible via DSPM for AI). Regularly review audit logs: set up alerts in Purview or export to a SIEM. Key events to track are agent creation and deletion, permission changes, and suspicious user interactions. 

• Integrate with Microsoft Sentinel. Microsoft recommends sending Copilot audit logs into Sentinel. You can then build analytics rules (for example, “alert if an agent is published outside of a change window” or “too many data records accessed by one agent in one day”). In Sentinel, correlate these AI agent activities with other signals. 

• Purview DSPM (Data Security Posture Management). For deep chat analytics, Purview’s DSPM for AI can reconstruct conversation transcripts and highlight policy violations (like blocked words, data matching sensitive categories).  

• Logging data access. Wherever possible, log exactly what data an agent queried or modified. In practice, this means turning on Power Platform’s built-in logging for connectors (App Insights) and auditing.  

• Retention and privacy. Balance logging with privacy: purge chat transcripts that are no longer needed. Use Purview’s retention labels or policies to auto-delete transcripts on a schedule. Document your logging retention policy for compliance audits. 

In summary, collect logs at every layer and funnel them into your enterprise monitoring. This visibility is what turns agent “actions” into an auditable record of governance. 

Best practices for designing safe agents 

Beyond infrastructure controls, design your agents with security in mind from the start. Here are concise Do’s and Don’ts to follow along the way:

Each of the above mitigations is actionable today using built-in Power Platform features or Microsoft security tools. In the sections below, we unpack how to implement these: from identity controls to DLP policies to monitoring.

Use this design checklist for production readiness: 

• Identity: Agent identity registered in Azure AD, with reviewed credentials (no hard-coded secrets) 
• Authentication:  
  • User sign-in required via Entra ID 
  • “NoAuth” blocked by policy 
• Permissions: Agent’s Azure AD roles and Dataverse roles limited by purpose and reviewed by security team 
• Environment: Deployed to correct environment 
• Data policies:  
  • Appropriate DLP policies assigned 
  • Connectors classified and blocked as needed 
• Security scan:  
  • Copilot Studio built-in security scan used (makers get warnings on risky configs) 
  • Flagged issues fixed regularly 
• Logging:  
  • Purview audit logging enabled 
  • Logs being exported to security monitoring 
  • App Insights on 
• Approval: Final review by IT and security teams, including a list of data sources and intended use 

Conclusion

Does your organization need guidance on safely harnessing Copilot agents? proMX has seasoned Microsoft specialists and MVPs who can audit your setup, define security and DLP policies, and help align AI projects with compliance. Contact our expert consultants to schedule an insightful discovery session tailored specifically for your business. We’ll help you turn autonomous agents into trusted members of your enterprise IT family.