Microsoft 365 Copilot Pre-Deployment Checklist: The Six Areas That Matter Before You Deploy (Agents Included)

Microsoft 365 Copilot has been deploying into enterprise tenants since 2024. Microsoft Agent 365 launched on May 1, 2026, extending the model so tenants can now build, publish, and consume custom Copilot agents that read from SharePoint, OneDrive, Exchange, Teams, and Graph connectors on behalf of end users. Both base Copilot and custom agents follow the same retrieval pattern, and both pull from the same configuration surface. The deployment decision feels like a feature toggle. It rarely is.

Microsoft’s documentation is explicit: Copilot and its agents “respect existing permissions, sharing settings, and policies.” That is by design. It is also the problem. Copilot inherits the configuration of the tenant it runs in. If SharePoint sites have years of accumulated oversharing, Copilot surfaces it. If sensitivity labels are inconsistent, Copilot retrieves unlabeled documents alongside labeled ones. If DLP policies do not cover Copilot interactions, the assistant can put protected content into prompts and responses without producing a single policy event.

Copilot does not weaken your tenant. It amplifies whatever posture already exists, which makes the pre-deployment work the gating issue rather than the technical rollout.

This post walks the six prerequisite areas that need to be in order before Copilot goes live, and the specific failure modes that follow when each one is skipped. Sections 1, 2, 3, and 5 apply to any Copilot deployment, whether you are turning on base Copilot or layering agents on top. Sections 4 and 6 cover the additional governance work that custom and third-party agents introduce.

What Microsoft 365 Copilot Does (and What Agents Add)

Microsoft 365 Copilot is the user-facing AI assistant that reads from Microsoft Graph (mail, calendar, files, chats) on the calling user’s behalf and produces grounded responses inside Teams, Outlook, Word, Excel, PowerPoint, and the Copilot chat surface. The platform supports three deployment paths in production tenants today:

1. Out-of-the-box Microsoft 365 Copilot retrieving from Graph for the calling user.
2. SharePoint agents, scoped to a specific site, library, or document set, represented as .agent files governed by SharePoint permissions.
3. Custom agents built in Copilot Studio with bespoke instructions, knowledge sources, and actions.

All three retrieve grounded content using the user’s existing permissions. None of them grant new access on their own. The risk is that Copilot surfaces, restructures, and accelerates whatever is already inside that access. Agents add an additional risk surface around how they are registered, who can install them, and how they are governed centrally. Sections 4 and 6 below address that surface specifically.

The Six Pre-Deployment Areas

1. SharePoint Permission Hygiene

The most consistent finding across M365 assessments is that SharePoint permissions drift over time. Sites inherit external sharing from parent containers that were configured years ago. Anyone-link policies created for one project remain in place. Groups accumulate members who left the project, the team, or the company.

When Copilot retrieves from SharePoint, it does not flag stale access. It returns the content. A user with implicit access to a board memo through a forgotten group membership receives that memo in the response.

What needs to happen first:

• Run a tenant-wide access review covering site collections, document libraries with unique permissions, and Microsoft 365 groups.
• Audit anyone-links and remove ones tied to closed projects.
• Enable Restricted SharePoint Search if the tenant is not ready for full Copilot scope on day one. This limits Copilot to a curated list of allowed sites while permission cleanup completes.
• Confirm SharePoint Advanced Management is licensed if the tenant has E3-only entitlements and needs the Data Access Governance reports.

If skipped: Copilot becomes the fastest way for users to discover content they technically had access to but never knew existed. This is not a breach, but it is the most common cause of post-deployment incident calls.

2. Sensitivity Labels and Information Protection

Copilot honors Microsoft Purview sensitivity labels and inherits them onto generated content, but only when labels are actually applied. In tenants where labeling is partial, optional, or limited to a small pilot, Copilot retrieves unlabeled documents and produces unlabeled outputs. Protected content gets mixed with unprotected content inside a single response, and the response itself carries no label.

What needs to happen first:

• Confirm sensitivity label taxonomy is published, in use, and required (not optional) for the document classes that matter.
• Enable auto-labeling policies for known-sensitive content types if manual labeling coverage is below roughly 70%.
• Verify label inheritance is enabled so Copilot outputs inherit the highest label of any source document.
• Validate label encryption settings do not block Copilot from reading documents that authorized users should be able to query.

If skipped: A Copilot response that summarizes three documents (two unlabeled and one Confidential) produces an unlabeled summary. The Confidential content has now been duplicated into a derivative artifact with no protection chain.

3. DLP Policy Coverage for Copilot Interactions

The CIS Microsoft 365 Foundations Benchmark v7.0.0 added control 3.2.3: Ensure DLP policies are published for Copilot users. The control reflects a real gap. Most tenants have DLP policies for Exchange, SharePoint, OneDrive, and Teams, but zero coverage for Copilot prompts and responses. When a user pastes a credit card, an account number, or a customer PII record into a Copilot prompt, no policy event fires unless a Copilot-scoped DLP rule exists.

What needs to happen first:

• Extend existing DLP policies to include Microsoft 365 Copilot as a location.
• Define separate policies for prompts (user input) and grounding (retrieved content).
• Configure block-with-override or warn actions for sensitive information types relevant to the business (PII, payment data, regulated health data, source code).
• Test policies against representative prompts before broad rollout. DLP detection in conversational contexts behaves differently than file-based detection.

If skipped: Copilot becomes an unmonitored channel for data leaving the controlled boundary, both inbound (sensitive content surfaced in responses) and outbound (sensitive content typed into prompts).

4. Application and Consent Governance (Agent-Specific)

This section applies to tenants building, installing, or publishing custom and third-party Copilot agents. Base Copilot does not introduce new application registrations.

Custom agents and third-party agents register as applications in Entra ID. They request permissions, including delegated and application permissions that can read mail, files, calendars, and Graph data. The same permission model that has been a known M365 risk surface for years (OAuth app consent abuse, overprivileged service principals, unused app registrations) now hosts the agent ecosystem.

What needs to happen first:

• Set user consent for applications to “Do not allow user consent” or, at minimum, “Allow user consent for apps from verified publishers, for selected permissions.”
• Enable the admin consent workflow so users can request agents that require elevated permissions.
• Configure agent policies in the Copilot Control System to govern which agents users can install, share, and publish.
• Run an app registration audit for agents already added during the early-access period. Anything that pre-dates governance configuration was added under whatever defaults existed at the time.

If skipped: Any user can install third-party agents that request Graph-wide read permissions, and the consent grants persist after the agents are forgotten.

5. Identity and Conditional Access Prerequisites

Copilot inherits the calling user’s identity context. Every Conditional Access weakness in the tenant (legacy authentication exceptions, missing device compliance requirements, broad named-location trust, MFA gaps for service accounts) applies to Copilot interactions as well.

The CIS v7.0.0 Benchmark expanded Conditional Access controls significantly. New controls cover periodic reauthentication (5.2.2.13), defined trusted named locations (5.2.2.14), exclusionary geographic access controls (5.2.2.15), token protection for session tokens (5.2.2.16), and blocking of authentication transfer between devices (5.2.2.17). These are not Copilot-specific controls, but Copilot is the workload that makes the gaps measurable. Every grounded query becomes a Graph call carrying the session context.

What needs to happen first:

• Validate that Conditional Access policies cover Copilot endpoints (M365 services, Graph, Office 365).
• Confirm break-glass accounts exist, are excluded from CA policies, and have FIDO2 keys in secured storage (CIS 1.1.2, 2.2.1).
• Enforce MFA on all administrative roles and validate no service account is exempted from CA without compensating controls.
• Apply token protection and session controls for high-sensitivity user populations.

If skipped: A compromised session token now has Copilot-augmented data retrieval capability, beyond just inbox and file access.

6. Agent Registry and Admin Governance (Agent-Specific)

This section applies to tenants that have agents in use or plan to allow them. The Agent Registry in the Microsoft 365 admin center is the central catalog and policy point for all agents in the tenant. It is also where most tenants have not configured anything. The defaults allow agent creation and sharing more broadly than most security teams would choose if asked.

What needs to happen first:

• Review the Agent Registry weekly during the first 90 days of agent adoption.
• Configure agent policies for access, sharing, and publishing aligned to organizational risk tolerance.
• Designate agent admins using least-privilege role assignments rather than Global Admin.
• Establish a request and approval workflow for any agent that will be shared beyond its creator.

If skipped: Agents proliferate without inventory. Removing an agent six months after creation requires reconstructing who built it, what it can access, and who depends on it.

What a Pre-Deployment Assessment Covers

The six areas above are the structural ones. A full pre-deployment assessment also evaluates which sensitive workloads should be excluded from Copilot grounding (HR, legal, M&A workspaces), how Copilot audit logging is configured and where logs route, whether Microsoft Purview eDiscovery and Communication Compliance cover Copilot interactions, and how Copilot usage will be monitored against acceptable use policies once deployed.

Genesis Solutions runs Copilot pre-deployment assessments as a standalone engagement, or as a requested add-on to a CIS M365 Foundations Benchmark assessment. The output is a control-by-control gap report mapped against CIS v7.0.0 (including the new Copilot control 3.2.3), Microsoft’s published agent prerequisites, and the NIST AI RMF Govern and Manage functions. Organizations subject to sector-specific frameworks, such as the new Financial Services AI Risk Management Framework or HHS AI guidance for healthcare, receive an additional overlay against the relevant sector profile.

The order matters. Pre-deployment assessment, governance hardening, then Copilot rollout, in that sequence, produces a deployment that holds up to audit, eDiscovery, and incident response. The reverse order produces a deployment that has to be retrofitted under pressure once the first incident, audit finding, or regulatory inquiry surfaces.

If your organization or your MSP clients are deploying Microsoft 365 Copilot or custom agents, or have already deployed and want a retroactive gap review, Genesis offers wholesale and direct engagements. Contact us to scope an assessment.