Copilot Studio Security: 10 Important Admin Questions

Copilot Studio security depends on Microsoft-managed service protections and the controls configured by your organization. Administrators should understand the identities an agent uses, restrict its connectors and knowledge sources, test authorization, and confirm that audit records meet operational requirements.

1. Are older multitenant Entra ID app registrations automatically unsafe?

No. A multitenant Microsoft Entra ID application registration is not, by itself, evidence of a security problem. Copilot Studio uses application registrations to authenticate communication with channels and Azure Bot Service resources. Newly created agents use a single-tenant application registration, while some existing agents may retain the earlier multitenant registration.

Still, administrators should review enterprise applications, permissions, consent, credentials, owners, and sign-in activity as part of normal identity governance. Do not interpret �managed by the service� as a reason to ignore unusual configuration or activity.

2. Does Copilot Studio support Power Platform tenant isolation?

Copilot Studio does not use the Power Platform tenant-isolation feature in the same way as connector connections. Power Platform connections may cross tenant boundaries when a user supplies valid credentials unless tenant isolation and related policies restrict that behavior. Administrators should review both inbound and outbound connection rules and test the connectors their agents use.

3. Why are service identities and certificates created?

An agent needs an application identity to authenticate with supported services, channels, and data sources. Copilot Studio can create and manage an Entra ID application and linked service principal for this purpose. The exact objects and credentials depend on the agent's authentication and channel configuration.

Inventory these identities, restrict their permissions, avoid unnecessary owner assignments, and monitor certificate or secret lifecycles. For custom integrations, document who is responsible for credential rotation and incident response.

4. Can administrators prevent all agent creation?

Microsoft's current guidance says agent creation cannot be completely disabled. Administrators can instead use Power Platform data policies to prevent users from chatting with agents and to restrict the capabilities that make an agent useful or publishable. Environment access, licensing, security roles, and managed-environment policies provide additional control.

5. Where should security and privacy claims be verified?

Use the current Microsoft Product Terms, Data Protection Addendum, Trust Center, service documentation, and your organization's contract. Verify how prompts, responses, knowledge sources, model processing, content moderation, data residency, and support access apply to the specific features and regions in use.

A practical overview is available in our guide to Copilot Studio security and administration controls. Formal requirements should be checked through a documented Copilot Studio compliance assessment.

6. What can administrators audit?

Copilot Studio and Power Platform activities can appear in Microsoft Purview audit. Relevant questions include who created or modified an agent, who owns it, how it was shared, and which runtime or tool activities were recorded. Microsoft Sentinel can also consume supported events for monitoring.

Before relying on logs, verify the available event types, required licenses, retention period, identities recorded, and delivery delay. Build a test agent, perform known actions, and confirm that investigators can find the corresponding events.

7. How can generative AI features be restricted?

Use the Power Platform admin center and data policies to control features at the appropriate tenant or environment scope. Depending on current product support, policies can restrict public websites and other knowledge sources, connectors, HTTP requests, channels, triggers, publishing, and cross-geography processing.

Start with a restrictive baseline and allow only capabilities required by an approved use case. Reassess the policy whenever an agent gains a new data source or action.

8. How are knowledge sources controlled?

Data policies can allow or block categories of knowledge sources, including SharePoint, public websites, and uploaded documents. Access control must also be enforced at the source. A policy that permits SharePoint does not fix overly broad SharePoint permissions.

Test the agent as users with different access levels. Ask for content that each test user should and should not be able to retrieve, and record the result as part of agent testing in Copilot Studio.

9. Can Copilot Studio data use customer-managed encryption keys?

Eligible Copilot Studio environments support customer-managed keys (CMK). CMK can give an organization control over the key used to protect covered data at rest, but coverage, prerequisites, operational procedures, and recovery consequences must be reviewed carefully. Confirm exactly which data and services are covered before stating that �all data� uses the customer key.

10. How is confidential knowledge kept from unauthorized users?

Copilot Studio can use the signed-in user's identity and source permissions when retrieving protected content. Supported sensitivity-label information and endpoint filtering can provide additional safeguards for SharePoint knowledge. These controls work only when authentication, source permissions, and the connector configuration are correct.

Do not publish a confidential-data agent anonymously. Use least-privilege permissions, remove overshared source content, require authentication, and test with accounts representing each access tier. Microsoft�s current Copilot Studio security FAQ should be checked for feature changes and limitations.