An embedded copilot is an AI feature that runs inside an existing application, inherits the authenticated user's session, and reads whatever that session can access. The security implication follows directly from the mechanism: if the user can read it, the copilot can read it, summarize it, and surface it in response to a natural language query. No separate credential. No incremental permission grant. No new principal in your identity model.
Microsoft 365 Copilot is the version of this your accounts have almost certainly already encountered — someone renewed their Microsoft 365 E5 license and the feature was there. By early 2026, Microsoft reported Copilot active in more than 85% of Fortune 500 organizations. Federal civilian deployment accelerated after FedRAMP authorization in late 2024. The security conversation is arriving after the fact, which is the only context in which it ever arrives.
A copilot rollout is a permissions audit event. The AI is working exactly as designed. The problem, when there is one, is what the user's identity was already allowed to reach.
• Embedded copilot: An AI feature that operates inside an existing application using the authenticated user's session. It reads what the user reads — no more, no less, and no separate permission grant required.
How the Session Becomes the Access Model
Microsoft 365 Copilot runs on top of Microsoft Graph, the API layer that mediates between Microsoft 365 applications and the data they contain. When a user asks Copilot a question, Copilot queries Graph using that user's existing authentication token. Graph returns whatever that token can access: SharePoint documents, Exchange emails, Teams messages, OneDrive files, meeting transcripts. Copilot synthesizes across all of it and returns an answer.
The copilot is a new capability attached to an existing principal. The user's token is the copilot's token.
This is where scale starts to matter. A typical enterprise user in a mid-size agency might have read access to 40,000 or 50,000 SharePoint files — documents accumulated across years of broad site permissions, "Everyone except external users" sharing defaults, and project folders that were never cleaned up after the project ended. The user has never opened most of them. They don't know they can. The copilot knows, because the copilot queries Graph comprehensively when it's constructing an answer.
The oversharing problem in SharePoint predates AI by a decade. What's new is the throughput. A human user accessing overshared files is limited by attention, time, and the fact that they have to know to look. A copilot querying Graph has none of those constraints. It will find the HR salary band document that got dropped into a broadly accessible project folder in 2019 and never moved. It will surface it if the query is anywhere adjacent to compensation, budget, or headcount.
The copilot is working correctly. The vulnerability, if that's the right word, is the permissions state the organization has been accumulating for years.
• Session inheritance: The mechanism by which a copilot accesses data using the authenticated user's existing token rather than a separate credential. The copilot's access boundary is identical to the user's access boundary — defined entirely by whatever permissions the identity system has already granted.
The Conversation You're Actually Walking Into
A CISO in a federal civilian agency calls a meeting because someone in the C-suite asked whether M365 Copilot is a security risk. The CISO has read enough to know there's something to worry about but hasn't landed on what, exactly. The conversation will probably start with AI: model behavior, data retention, whether Microsoft is training on agency data, whether the FedRAMP boundary covers Copilot features.
Those are real questions. Worth answering. But underneath all of them sits a more consequential one: what can your users read? Because whatever your users can read, Copilot can now surface at conversational speed. If your SharePoint permissions are clean — if you've enforced least privilege, cleaned up legacy broad-access groups, and kept your data classification current — then Copilot is operating on a well-governed data estate and the risk profile is manageable. If your SharePoint permissions look like most organizations' SharePoint permissions, you have a different problem, and it existed before anyone turned on an AI feature.
In federal environments, this lands with particular weight. Need-to-know is a legal and regulatory requirement, not a best practice. A system that synthesizes across everything a user's identity can reach will test whether need-to-know is actually enforced at the data layer, not just asserted in policy. For many agencies, the honest answer is that it isn't — SharePoint's default sharing model is permissive and the governance work to tighten it never got prioritized over mission work.
The copilot made this exposure visible. Remediation runs through SharePoint site audits, Entra ID group cleanup, and data classification review. That's an identity and data governance project. It may be the most valuable thing the Copilot deployment has surfaced, even if nobody planned for it.
• Permissions audit event: The accurate framing for what a copilot rollout requires. Because the copilot reads what the user reads, deploying one is equivalent to running a comprehensive audit of whether your data permissions reflect your actual access policy — except the audit is performed by an AI that will surface results in response to natural language queries, without waiting for someone to schedule the review.
IDAM Concept Mapping
The closest analogy is OAuth delegated authorization. Where it breaks is the lesson.
In OAuth, a client application requests access to a resource on behalf of a user. The request specifies scopes. The user consents. The authorization server issues a token that encodes the grant. The "what can this app access?" question has a precise answer: the scopes in the token, bounded by what the user consented to grant.
A copilot doesn't work this way. There is no scope negotiation specific to the copilot's data access. There is no consent event. The copilot reads what the user reads because it operates using the user's existing session, not a delegated token with bounded scopes. The "what can this app access?" question doesn't have a scopes answer. It has a "what can this user access?" answer, which is an identity governance question, not an application authorization question.
Your OAuth intuition is useful for understanding why there's no incremental permission grant to audit — the copilot didn't request anything, so there's nothing to review in the authorization layer. It starts to mislead you if it makes you look for a token with scopes to evaluate. The audit target here is the user's effective permissions across the data estate, and that's an Entra ID and SharePoint governance problem. The OAuth mental model gets you to the right door. It doesn't open it.