Microsoft Security Copilot: Use and Govern Generative AI in Microsoft Security Tools

Microsoft Security Copilot gives analysts a generative AI assistant and a set of agents that read data from Defender, Sentinel, Intune, Entra and Purview, so who can use it, what it can reach and what it records need to be decided deliberately rather than left at defaults. Microsoft describes Security Copilot as a generative AI security solution with a standalone portal and embedded experiences inside its security products, extended by plugins and agents. Since November 2025 Microsoft has been rolling out an included capacity allocation for Microsoft 365 E5 and E7 customers, which means many tenants now have Security Copilot available without a separate purchase decision. This guide is for security operations leads, identity administrators and platform owners who need to set up and govern Security Copilot: roles and access, capacity, plugins and agents, audit logging, data handling settings and a practical hardening baseline. For the vendor-neutral view of AI in the security operations centre, see the AI SOC Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Copilot roles open the platform, not the data. Copilot owner and Copilot contributor control features; data reached through Microsoft plugins still depends on the signed-in user's own permissions through on-behalf-of authentication.
• Several Entra roles inherit Copilot owner. Global Administrator, Security Administrator, Billing Administrator, Intune Administrator and Entra Compliance Administrator inherit owner, so review which inherited roles you keep selected.
• Agents need an identity decision. Each agent runs under a dedicated Microsoft Entra Agent ID identity or under the account of the user who set it up; choose the agent identity where it is offered and grant only what the agent needs.
• Turn on Purview audit logging early. Admin events, activity metadata and prompt and response pairs reach Microsoft Purview only after the "Logging audit data in Microsoft Purview" option is enabled.
• Plan capacity as a control. Security Compute Units (SCUs) govern how much Security Copilot can run; provisioned, overage and E5 included capacity behave differently, and usage should be watched like any other consumption service.

What Security Copilot is and how it is licensed

Microsoft lists embedded experiences in Microsoft Defender XDR, Microsoft Sentinel, Microsoft Intune and Microsoft Entra, with integrations for third-party services such as ServiceNow and Jamf. Prompts in an embedded experience run in the context of the product the analyst is using; the standalone portal at securitycopilot.microsoft.com supports sessions, promptbooks, plugins and agent management.

Capacity models

Microsoft's inclusion page states that the rollout began on 18 November 2025 for existing Security Copilot customers with Microsoft 365 E5 and continues for other eligible E5 and E7 customers, and that Microsoft Sentinel customers without E5 or E7 can use the standard purchase model. Agents consume SCUs like other features. Allocation figures and dates are as published at the time of writing; confirm current values on Microsoft Learn.

How identity and access work in Security Copilot

Access has two layers. Security Copilot role-based access control decides who can use the platform and its features. Each plugin then reaches data with the user's own rights: Microsoft documents that Microsoft plugins use on-behalf-of (OBO) authentication and that Copilot does not go beyond the user's access.

• Contributor assignment: New instances default to "Recommended Microsoft Security roles", which gives contributor access to users who already hold security permissions. Older instances may still use the "Everyone" option. Microsoft recommends replacing Everyone, and notes that removal of Everyone is permanent, so set up the replacement groups first.
• Groups: Security Copilot supports role-assignable groups for permissions. Assign owner and contributor to groups, not individuals.
• Conditional Access: Microsoft recommends layering Conditional Access on top of Security Copilot RBAC. Apply your phishing-resistant authentication and compliant device policies to the Security Copilot app. See the Conditional Access Guide.
• Shared sessions: Viewing a shared session needs only the Copilot contributor role in the same tenant, and plugin access is not re-checked for viewers. Share sessions with people who are entitled to see the underlying data.
• Multitenant access: Microsoft documents tenant switching for B2B guests, GDAP through Partner Center and Azure Lighthouse. Managed service providers should map each route to a named, reviewed delegation.

Admin roles and privileged access

The Copilot owner role controls tenant-wide settings: plugin availability, custom plugin policy, data sharing, file upload, capacity and Purview audit logging. Treat it as a privileged role.

• Inherited owner roles: Microsoft lists Billing Administrator, Entra Compliance Administrator, Global Administrator, Intune Administrator and Security Administrator as inheriting Copilot owner, and notes that only the selected roles inherit owner on the workspace. Keep the selection as narrow as your operating model allows.
• Least privilege: Microsoft advises against assigning Security Administrator only to give someone Copilot access. Create a security group and assign it Copilot owner or contributor instead.
• Two owners minimum: Security Copilot keeps at least two owners at all times. Make those named, monitored administrators, and keep emergency access accounts outside normal Conditional Access dependencies. See the Break-Glass Account Guide.
• Just-in-time elevation: Where owner rights come through Entra roles, use Privileged Identity Management so the inherited owner right is active only when needed. See the Privileged Identity Management (PIM) Guide.
• Capacity rights: Provisioning capacity needs Azure Contributor or Owner on the subscription or resource group plus Security Administrator or higher in the tenant. Scope the Azure role to a dedicated resource group.

Integrations, API tokens and service accounts

Plugins

Microsoft groups plugins as Microsoft plugins, non-Microsoft plugins, website plugins such as Public web, and custom plugins. Owners control them under Owner > Plugin settings.

• Custom API plugins: Custom plugins use a YAML or JSON manifest with Descriptor and SkillGroups, pointing to an OpenAPI 3.0 or 3.0.1 specification. Microsoft's custom plugin page documents bearer authorisation for API plugins. Store those bearer tokens as managed secrets with an owner, expiry and rotation plan, and scope each to read-only APIs where possible.
• Per-user plugin setup: Plugins such as Microsoft Sentinel and Azure AI Search are configured per user. Include them in onboarding so analysts connect to the right workspace.
• Agent plugins: Setting up an agent enables its required plugins for that agent only, without changing organisation-wide availability.

Agents

Agents automate recurring tasks and can run on a trigger or schedule. Microsoft documents two identity choices at setup: a dedicated agent identity through Microsoft Entra Agent ID, currently available for Microsoft-built agents, or an existing user account whose access the agent inherits while it is active.

• Prefer the agent identity: A dedicated identity can be scoped, reviewed and disabled without affecting a person. See the Microsoft Entra Agent ID Guide.
• Where a user account is used: Use a dedicated, named account owned by the SOC with only the permissions the agent needs, rather than an administrator's daily account.
• Recertify: Review each agent's identity, permissions, triggers and owner on a schedule. See Agent Identity Recertification.

Data handling settings

• Workspace location: Customer data is stored in the location chosen when the workspace is created, and that choice is fixed for the workspace, so pick it deliberately.
• Data sharing: Copilot owners control two data sharing options, one for human review to validate product performance and one to build and validate Microsoft's security AI model. Microsoft documents both as on by default. Decide on them with your privacy and legal teams, record the decision and set them during onboarding.
• Prompt evaluation location: Prompts are evaluated in Australia, the EU, the UK or the US, with an option to evaluate anywhere with capacity. Evaluation location does not change storage location. Choose based on your data transfer position.
• Microsoft 365 data access: Owners can allow queries against Purview-processed Microsoft 365 data such as DLP alerts and eDiscovery review sets. Microsoft notes that data retrieved this way follows Security Copilot's retention rules, so include this in your records of processing.
• Retention: Microsoft Learn publishes retention periods for sessions, deleted capacity and shared data. Confirm the current values in Microsoft's privacy documentation before writing them into policy.

Logging and detection

Security Copilot audit data flows to Microsoft Purview through the Unified Audit Log, Data Security Posture Management (DSPM) for AI and the Office 365 Management API, after a Security Administrator enables Owner > Owner settings > Logging audit data in Microsoft Purview.

Microsoft states the default audit retention is 180 days and can be extended with audit retention policies. Forward the events to your SIEM so changes to owner settings raise an alert. See the Microsoft 365 Unified Audit Log Guide for Detection and the Microsoft Sentinel Guide.

Metrics

• Number of direct (non-group) Copilot owner and contributor assignments: target zero.
• Agents running under a user account rather than an agent identity, each with a documented reason.
• Custom plugins with a named owner and a token expiry date: target 100%.
• Monthly SCU use as a percentage of provisioned or included capacity.
• Alerts raised for owner setting changes within one hour of the change.

Hardening baseline

An NHI Mgmt Group baseline, ordered for rollout. Pilot with a small analyst group first, review audit events for two weeks, then widen.

1. Enable Purview audit logging before broad rollout, and confirm events arrive in the Unified Audit Log.
2. Decide data sharing and evaluation location with privacy and legal teams and set them in owner settings.
3. Replace Everyone with Recommended Microsoft Security roles or a custom group model.
4. Narrow inherited owner roles to those your operating model needs and use PIM for elevation.
5. Apply Conditional Access to the Security Copilot app with phishing-resistant authentication.
6. Keep custom plugin settings at Owners only and restrict preinstalled plugins the SOC does not use.
7. Set agents to the agent identity where available and document each agent's owner, trigger and permissions.
8. Set an overage maximum or monitor included capacity, with a named capacity owner.
9. Review output. Microsoft advises reviewing promptbook output for accuracy; require analyst sign-off before Copilot output drives containment actions. See the Prompt Injection Guide for why untrusted content in prompts needs care.

Rollback is simple for most settings: plugin availability, custom plugin policy and contributor groups can be changed back by an owner, and the change takes effect immediately. Capacity changes are billed by the hour, so schedule them.

Common misconfigurations

• Everyone left as contributor: Users without security data access see a confusing experience, and access is broader than intended. Move to role-based groups.
• Security Administrator granted just for Copilot: This hands out far more privilege than Copilot needs. Use Copilot roles assigned to groups.
• Audit logging not enabled: Without the Purview option, admin changes and prompt activity are not available for investigation. Turn it on during onboarding.
• Agents set up under an administrator's account: The agent then carries that person's full access. Use the agent identity or a dedicated, scoped account.
• Shared sessions sent widely: Viewers see full results without plugin checks. Share only with people entitled to the data.
• Data sharing defaults never reviewed: Both options start on. Make an explicit, recorded decision.

Framework mapping

Practitioner checklist

• Enable "Logging audit data in Microsoft Purview" and confirm events reach the Unified Audit Log and your SIEM.
• Record decisions on both data sharing options, workspace location and prompt evaluation location.
• Assign Copilot owner and contributor to role-assignable groups and remove Everyone.
• Narrow the Entra roles that inherit Copilot owner and use PIM for elevation.
• Apply Conditional Access to Security Copilot with phishing-resistant authentication.
• Keep custom plugin policies at Owners only and restrict unused preinstalled plugins.
• Store custom plugin bearer tokens as managed secrets with owner, expiry and rotation.
• Run agents under an agent identity where available and recertify them quarterly.
• Set an overage maximum or track included capacity monthly, with a named owner.
• Require analyst review before Copilot output drives containment or configuration changes.

Standards and references

• Microsoft Learn: What is Microsoft Security Copilot?
• Microsoft Learn: Understand authentication in Microsoft Security Copilot
• Microsoft Learn: Security Compute Units and capacity
• Microsoft Learn: Security Copilot for Microsoft 365 E5 and E7 included customers
• Microsoft Learn: Privacy and data security in Microsoft Security Copilot
• Microsoft Learn: Access the Security Copilot audit log
• Microsoft Learn: Manage plugins in Microsoft Security Copilot
• Microsoft Learn: Microsoft Security Copilot agents overview

Related NHI Mgmt Group resources: AI SOC Guide · Microsoft Defender XDR · Microsoft Entra Agent ID Guide · Agent Identity and Access Guide