What's changed: Created SC-100 Chapter 5 (Domain 4 "Application and data security": M365 protection (Microsoft Secure Score/Defender for Office 365/Defender for Cloud Apps (CASB)/Intune/Purview labels/DLP); Copilot for Microsoft 365 (permission/label inheritance/oversharing/DSPM for AI/Purview Audit); app protection (threat modeling/secure development lifecycle/workload identity/API Management/Azure WAF); data protection (discovery/classification/encryption at rest-in transit/CMK/Key Vault/Defender for Storage/Defender for Databases/Azure SQL/Synapse/Cosmos DB/Storage)).
5.2Data security for Microsoft 365 Copilot
Understand evaluating data security and compliance controls for Microsoft 365 Copilot: inheritance of existing access permissions and sensitivity labels, curbing oversharing, and applying Purview auditing and DLP.
The generative-AI assistant Microsoft 365 Copilot answers across tenant data. Powerful, but it risks "data the user can access being surfaced en masse via Copilot," so architects design evaluation/controls from a data-governance standpoint.
5.2.1Inheriting permissions and sensitivity labels
Copilot creates no new permission model—it references and answers only within the access the user already has. It also respects Microsoft Purview sensitivity labels, so handling of encrypted/usage-restricted content follows the label’s protection, and generated responses inherit appropriate labels. The architect’s starting point: "Copilot’s security equals the health of the underlying M365 access permissions and labels."
5.2.2Curbing oversharing and auditing
The top risk is oversharing—confidential files that became "shared with everyone" or stale loose permissions. Before deploying Copilot, tighten permissions via Purview Data Security Posture Management (DSPM for AI), access reviews, and SharePoint sharing reviews. Copilot activity is auditable in Purview Audit, and DLP and sensitivity labels control the boundaries of responses/references. Architects make explicit the requirement: "a precondition for AI adoption is least-privilege data hygiene."
Cues: "prevent Copilot from touching sensitive data" = minimize existing M365 access + sensitivity labels + fix oversharing (Purview DSPM for AI). "audit Copilot activity" = Purview Audit. Key point: Copilot creates no new permissions—it inherits existing permissions/labels.
Watch the mix-ups: (1) Copilot does not "widen access"—it surfaces/traverses within existing access; the root fix is healthy permissions and labels. (2) Sensitivity labels (Purview) are data-following protection, not network controls. (3) Use AI-specific governance (DSPM for AI) alongside general DLP.
5.2.3Section summary
- Copilot creates no new permissions—it inherits existing M365 access and sensitivity labels
- Top risk = oversharing; before deployment, apply least privilege via Purview DSPM for AI/access reviews/sharing reviews
- Audit Copilot activity in Purview Audit; control response/reference boundaries with DLP/labels
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. What is the most fundamental precondition to prevent sensitive-data exposure when adopting Microsoft 365 Copilot?
Q2. Which is true of Copilot’s data access?
Q3. Before Copilot deployment, to find/fix oversharing such as confidential files "shared with everyone," which is best?
Q4. To obtain audit logs of Microsoft 365 Copilot activity (prompts/responses), which is best?
Q5. How does Copilot handle encrypted content with a sensitivity label?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.