What is Microsoft 365 Copilot security?
By Identra · Updated
Microsoft 365 Copilot security is the practice of controlling which business data Microsoft 365 Copilot and its connected agents can reach, and what those agents can do, when employees use them. It depends on correct source permissions, tested data protections, restricted agent connections and audit records that support investigation and response.
How does Microsoft 365 Copilot access company data?
When Copilot answers from work content, it is designed to use only what the signed-in user can already access. Microsoft's privacy and security documentation describes this boundary. So your SharePoint, OneDrive and Teams permissions are the main control.
Having permission and needing access are different things. Someone kept read rights from a project two reorgs ago. A site got shared with Everyone except external users years back. Nobody noticed because nobody went looking. Copilot goes looking every time someone asks a question. Clean up with least privilege before you treat a successful permission check as proof the access is appropriate.
This entry is about Microsoft 365 Copilot and its agents. GitHub Copilot and Microsoft Security Copilot are separate products with their own data paths.
What does Copilot oversharing look like?
Say finance is preparing an acquisition. The planning deck sits on a SharePoint site a broad employee group can read. An analyst outside the deal team asks Copilot what big changes are coming and gets back a summary of the confidential plan. Copilot broke no rule. The file was already readable.
That is Copilot oversharing. Fix the site permissions and find out who saw what. Telling staff to stop asking sensitive questions leaves the deck exactly where it was.
Then test both sides. A deal-team member should still find the deck. The excluded analyst should fail to open it directly and fail to get it through Copilot. Look for summaries already saved to OneDrive or pasted into Teams chats, since fixing the source does not pull those copies back.
Do sensitivity labels stop Copilot from surfacing sensitive data?
Sometimes. Microsoft Purview sensitivity labels classify content and can apply encryption. A label that only classifies changes nothing about who can read the file. For encrypted content, Microsoft documents that Copilot returns data only when the user holds the EXTRACT usage right as well as VIEW. The data protection guidance covers how Copilot, permissions and encryption interact.
Test retrieval, the answer, any new document Copilot creates and later sharing as separate steps. Do not assume every output carries the source label. Purview documents limits for specific scenarios. Read them, then confirm the behavior in your own tenant.
Source permissions
- What it does
- Decide who can open content
- What to verify
- Group memberships and sharing links match business need
Sensitivity labels
- What it does
- Classify content and apply configured protection
- What to verify
- Encryption and usage rights hold in the real workflow
Data loss prevention policies
- What it does
- Restrict supported handling of sensitive information
- What to verify
- The policy covers this workload and this action
Audit records
- What it does
- Support investigation
- What to verify
- The events you need are recorded, retained and searchable
How should security teams review Copilot agents?
Treat each agent as an integration with its own knowledge sources, connections and actions. Find out which identity authenticates to each service. In Copilot Studio a connection can run with the end user's credentials or with credentials the maker supplied, and that decides whose permissions apply. The user who started the chat tells you nothing about it.
Where a connection uses OAuth, review the OAuth app risk. Which permissions, who consented. Microsoft's privacy and security documentation also tells admins to read each agent's terms and privacy statement for data handling.
An agent that reads HR policy PDFs and one that emails customers are not the same risk.
- Record the owner, purpose, audience and knowledge sources.
- Document connection identities, permissions and where data goes.
- Restrict tools to the resources and operations the job needs.
- Require approval before consequential sends, deletions or access changes.
- Confirm an admin can disable the agent and remove its connections.
Can a document manipulate a Copilot agent?
It can try. Documents, emails and tool responses can carry instructions meant to redirect the assistant. That is indirect prompt injection. Being allowed to read a file does not make the instructions inside it trustworthy.
Say a shared Word document tells the agent to attach unrelated internal files to an outgoing email. Test exactly that in a sandbox with harmless data and see whether the agent attempts the extra retrieval or the send.
The fix sits outside the model. Restrict access in the connected services, narrow the actions and destinations, and put human approval on sends that matter. The approver should see the recipient, the content and the action. A generic allow button gives them nothing to judge.
What should a secure Copilot rollout include?
Start with your most sensitive SharePoint sites and the workflows that touch them. Give each of access review, Purview policy, agent approval and incident response an owner. Write acceptance criteria before the pilot so a good demo cannot stand in for a security check.
Build an AI audit trail linking user activity, agent configuration, access changes and downstream actions. Copilot interactions are recorded in Microsoft Purview Audit, but check retention, workload coverage and licensing for your tenant. Lock down the investigation records too. Prompts and responses carry sensitive data.
- Review broad sharing and stale group memberships on sensitive sites.
- Test allowed and denied retrieval with test accounts that mirror real roles.
- Run labels and DLP policies through the whole workflow, end to end.
- Exercise an agent's consequential actions against safe test resources.
- Run a mock incident and check investigators can find what they need.
- Practice fixing permissions, disabling connections and revoking grants. Retest before restoring access.
How Identra thinks about it
Identra discovers AI agents across Microsoft 365 Copilot and Foundry with their owners, alongside the connected apps and OAuth grants in your Microsoft 365 and Entra ID tenant. Analysts can revoke a risky grant, and the result of every response is recorded.
Go deeper: AI discovery across identity, SaaS and cloud
Frequently asked questions
Does Microsoft 365 Copilot bypass file permissions?
Its documented access model uses the signed-in user's existing permissions. Oversharing still happens when those permissions exceed what the user needs, so check both the permission settings and what Copilot actually retrieves.
Is Microsoft 365 Copilot security the same as Microsoft Security Copilot?
No. Microsoft 365 Copilot security is about securing the productivity assistant and its connected workflows. Microsoft Security Copilot is a separate product built for security teams.
Does a Confidential label automatically prevent Copilot access?
No. The label name decides nothing. What matters is its configured protection, the source permissions, the policies that apply and whether the specific workflow is supported.
Do all Copilot agents act with the requesting user's permissions?
Not necessarily. Check the authentication and connection settings for each data source and action. A connection set up with the maker's credentials runs with the maker's access.
What should security teams do after a sensitive Copilot response?
Preserve evidence and identify the source content, the requesting user and the access path. Fix the inappropriate access, find saved or shared copies of the output and confirm containment before restoring the workflow.
