All 16 Microsoft 365 Copilot checks - what each one checks, why, and the access used to evaluate it.

16 checks. Column "Access used" lists the application permissions and collected data sources this check's evaluation reads; "None" means Watchtower reads no tenant data for it.

Check	Severity	What it checks	Why it matters	Access used
Copilot agents (Copilot Studio) are gated by admin approval `wt.copilot.agents.admin-approval-gate`	HIGH	Copilot agents created in Copilot Studio require admin approval before they can be deployed to the Copilot chat surface, and only approved agents appear in the user-facing agent picker.	Copilot Studio agents can be authored by any licensed user. Without an admin approval gate, a power-user agent that retrieves from an unintended source - or one that exfiltrates via an HTTP-out connector - becomes available to the agent's audience without governance review.	`CopilotSettings-LimitedMode.Read` - via `copilotAdminSettings`
Copilot interactions appear in the unified audit log `wt.copilot.audit.unified-audit-log-enabled`	HIGH	Microsoft Purview unified audit logging is enabled tenant-wide and includes the CopilotInteraction record type - every Copilot prompt and response is auditable.	Without audit logging, Copilot interactions are invisible to compliance and incident response. Any subsequent investigation (data leak, prompt-injection, abuse) hits a dead end.	`Exchange.ManageAsApp` - via `adminAuditLogConfig`
Copilot usage analytics retention is at or above one year `wt.copilot.audit.usage-analytics-retention`	MEDIUM	Copilot usage analytics retention is set to at least 12 months so trend analysis and incident retrospective queries have at least a year of history.	Copilot usage analytics default to short retention. For compliance reporting, ROI evaluation, and incident retrospectives that span quarters, longer retention is required.	None - manual attestation (documented review step)
Conditional Access policies cover the Copilot app cluster `wt.copilot.ca.conditional-access-covers-copilot`	HIGH	A Conditional Access policy targets the Microsoft 365 Copilot app cluster and applies the workspace's standard auth controls (MFA, compliant device, sign-in risk).	Copilot inherits the access controls of its target service (SharePoint, Teams, Exchange) but the Copilot app itself is a separate first-party app that can be targeted independently. A CA policy that excludes Copilot but covers the underlying services leaves a vector where an attacker on a non-compliant device can reach grounded content through Copilot even though the same content would be blocked via SharePoint Online directly.	`Policy.Read.All` - via `conditionalAccessPolicies`
Copilot is excluded from guest-user access by default `wt.copilot.ca.guests-excluded`	HIGH	Guest users (Entra B2B accounts) are explicitly excluded from Copilot access by default - either via license non-assignment or a Conditional Access block.	Guest accounts that hold a paid license are an attack surface (the guest's home tenant is compromised → the attacker reaches the host tenant's Copilot, which grounds against host tenant data). Most workspaces do not deliberately license guests; this control catches the case where Copilot was added to an `All Users` group that silently includes B2B guests.	`Directory.Read.All`, `Group.Read.All`, `Organization.Read.All`, `User.Read.All` - via `copilotLicensing`
Microsoft Graph connectors are inventoried and reviewed `wt.copilot.connectors.inventory-reviewed`	HIGH	Microsoft Graph connectors registered in the tenant have been reviewed by the workspace owner. Connectors that grant Copilot access to external systems (ServiceNow, Salesforce, custom HTTP) widen the grounding-data surface and need explicit approval.	Graph connectors silently extend what Copilot can read. A connector that pulls Salesforce account records becomes Copilot context for every user who sees the Salesforce content in Search. Reviewing and listing every connector is the only way to know what Copilot can actually retrieve.	None - manual attestation (documented review step)
Copilot rollout is gated by a governance approval `wt.copilot.licensing.gated-rollout`	HIGH	Joining the Copilot licensed group requires explicit approval - either via an Entra ID access package, a service-desk ticket workflow, or a documented manager approval gate.	Self-service or open-membership Copilot groups remove every governance lever in this framework. The training, data-handling acknowledgement, and DLP-readiness checks all assume the user was reviewed before getting access. An open group means every new hire and every contractor gets Copilot the moment their Entra account exists.	`Directory.Read.All`, `Group.Read.All`, `Organization.Read.All`, `User.Read.All` - via `copilotLicensing`
Copilot licenses are assigned via groups, not directly `wt.copilot.licensing.group-assigned`	HIGH	Copilot licenses are assigned via Entra ID security groups rather than directly to individual users. Group-based assignment is the only way to apply Conditional Access and lifecycle automation at scale and is a prerequisite for every other governance control in this framework.	Direct license assignment bypasses the only enforcement seam Microsoft offers for Copilot governance. Without group-based assignment, an offboarded user retains Copilot access until manual cleanup; a Conditional Access policy targeting the Copilot app cluster never matches the right principals; and rollout cannot be staged. A direct-licensed tenant has effectively no governance lever beyond turning Copilot off entirely.	`Directory.Read.All`, `Group.Read.All`, `Organization.Read.All`, `User.Read.All` - via `copilotLicensing`
Third-party plugin installation is restricted `wt.copilot.plugins.third-party-restricted`	HIGH	Third-party Copilot plugins (those not published by Microsoft) are blocked or admin-approved-only, rather than user-installable on demand.	Third-party plugins run with the user's Copilot context - a malicious or poorly-engineered plugin can exfiltrate prompts or inject misleading grounding. Letting users install plugins on demand means the plugin-allowlist is whatever Microsoft's marketplace contains today, which is not a security review.	`CopilotSettings-LimitedMode.Read` - via `copilotAdminSettings`
Microsoft Purview AI Hub is enabled and monitored `wt.copilot.purview.ai-hub-enabled`	HIGH	Microsoft Purview AI Hub (data security posture management for AI) is enabled and a workspace owner is monitoring its risk signals (sensitive content exposure, oversharing recommendations).	AI Hub is Microsoft's own visibility tool for Copilot governance. It surfaces the oversharing risk, the over-permissioned data, and the policy gaps that this framework's other controls only attest in principle. Without AI Hub on, the operator has no objective signal about what Copilot is actually grounding against.	None - manual attestation (documented review step)
Data Loss Prevention (DLP) policies cover Copilot endpoints `wt.copilot.purview.dlp-covers-copilot`	HIGH	Microsoft Purview Data Loss Prevention policies include the Microsoft 365 Copilot location so DLP rules can match Copilot prompts / responses and block, audit, or override based on sensitive-info-type detection.	Without DLP coverage, a user can paste a credit-card number into a Copilot prompt and the standard DLP rule that would have blocked the same action in Outlook never fires. Copilot's chat surface is a regulated-data exfiltration vector that DLP must cover.	None - manual attestation (documented review step)
Retention policies cover Copilot interactions `wt.copilot.purview.retention-policies-cover-copilot`	HIGH	Purview retention policies explicitly include the Copilot interactions location, so prompts and responses retain alongside the rest of the tenant's regulated communications.	Copilot prompts and responses are eDiscoverable, but only if a retention policy includes them. A retention policy that covers Exchange + Teams + SharePoint but omits the Copilot location leaves a regulated communication channel without coverage - which is a defensible-deletion gap on inbound discovery requests and a sliding window before Microsoft's default retention applies.	None - manual attestation (documented review step)
Sensitivity labels are published and applied to AI-eligible content `wt.copilot.purview.sensitivity-labels-published`	HIGH	Microsoft Purview sensitivity labels are published and applied (manually or via auto-labelling) to the content that Copilot can reach: SharePoint document libraries, OneDrive, Exchange mail folders, and Teams chat retention.	Copilot honours sensitivity labels at retrieval time - content labelled `Confidential` or `Strictly Confidential` is excluded from Copilot's grounding context when the user is not authorised. Without labels published and applied, every file in every accessible library becomes Copilot-grounding material. The governance lever exists; this control verifies it is engaged.	None - manual attestation (documented review step)
Restricted SharePoint Search is configured to limit Copilot blast radius `wt.copilot.sharepoint.restricted-search-configured`	HIGH	Restricted SharePoint Search (RSS) is configured so Copilot's grounding is limited to a curated allowlist of SharePoint sites and OneDrive contents, rather than every site the user has access to.	Default Copilot retrieval pulls from every SharePoint site the user can read. In tenants with permission sprawl (the common case), this means Copilot surfaces shared-with-everyone documents the user could find with effort but never would in practice. RSS converts retrieval into an explicit allowlist - a major reduction in the over-sharing blast radius until the SharePoint permission model is cleaned up.	None - manual attestation (documented review step)
Copilot extensibility is disabled until governance is in place `wt.copilot.tenant.extensibility-disabled-initially`	MEDIUM	On first Copilot rollout, the tenant's Copilot extensibility (plugins, agents, Graph connectors) is disabled by default and re-enabled control-by-control after the rest of this framework's governance is in place.	Day-one Copilot adoption with default-on extensibility means every governance control in this framework is shipping concurrent with active use - the gap between rollout and governance is exposure. Disabling extensibility on day one collapses the rollout to its narrowest, well-understood grounding surface, then re-enables features as the rest of the framework is attested.	`CopilotSettings-LimitedMode.Read` - via `copilotAdminSettings`
Copilot web search is set per organisational policy (block vs allow) `wt.copilot.tenant.web-search-configured`	HIGH	The tenant-level Copilot web-search switch is configured deliberately (either deliberately enabled with a documented data-handling acknowledgement, or disabled if the workspace's data-handling policy forbids Bing grounding).	Default-on Bing web search in Copilot is a third-party data flow that may not match the workspace's data-classification policy. The control here is not 'must be off' - it is 'must be deliberately chosen' with documentation. Some workspaces correctly enable it; others must disable it.	`CopilotSettings-LimitedMode.Read` - via `copilotAdminSettings`