Copilot governance starts with the permissions you already have
A manager asks Microsoft 365 Copilot to find documents relating to workforce planning.
Among the results are an old restructuring proposal, salary planning information and notes from an HR working group.
The manager has permission to access these files. Some were shared years ago, others inherited access from a SharePoint site. Nobody has reviewed whether those permissions are still appropriate.
Copilot has worked within Microsoft’s existing security controls.
For the organisation, the discovery raises an uncomfortable question: how much sensitive information is accessible to employees who have no current business need to see it?
This is an illustrative scenario. The underlying issue is one Microsoft explicitly addresses in its Copilot deployment guidance.
As organisations expand Copilot adoption, existing access permissions deserve renewed attention. The information Copilot processes, and the agents it can use, introduce additional risks that need different controls.
What Microsoft 365 Copilot can access
Microsoft offers different Copilot experiences, and the distinction matters when assessing information security.
Copilot Chat is available at no additional charge with eligible Microsoft 365 subscriptions. Its included web-grounded chat can answer questions, draft content and analyse information users provide. Work-grounded capabilities and some agent scenarios depend on the licence and, in certain cases, consumption-based billing.
Microsoft 365 Copilot, the separately licensed add-on, provides work-grounded experiences using information a user is authorised to access. Depending on the experience and configuration, it can draw on emails, documents, meetings, conversations and other Microsoft 365 content. It also provides deeper capabilities in applications including Word, Excel, PowerPoint, Outlook and Teams.
A person using basic Copilot Chat may need to provide a relevant file. A licensed Microsoft 365 Copilot user can ask questions across information they already have permission to access.
Microsoft’s enterprise data protection commitments apply to eligible work and school experiences. Microsoft states that prompts, responses and Microsoft Graph data aren’t used to train foundation models.
Those protections matter. The organisation still needs to decide whether employees have appropriate access to its information and how they should use it.
Why existing permissions create exposure
SharePoint, OneDrive and Teams allow information to be shared across departments, projects and external organisations.
Over time, access changes. Employees move roles, project teams disband and documents remain accessible through groups or sharing links created for an earlier purpose.
Common examples include:
A confidential document stored in a site accessible to everyone in the organisation.
A former project member retaining access to commercial information.
Sensitive files inheriting permissions from a wider SharePoint library.
An external sharing link remaining active after a project finishes.
A SharePoint site without an accountable owner to review access.
Copilot respects the access controls that Microsoft 365 applies. When a user can access a document, Copilot may be able to use that document in a response, subject to the experience and applicable protection policies.
Natural-language questions and summarisation can make permitted information easier to discover and combine.
For security and IT teams, the important distinction is between access that Microsoft 365 permits and access that the business currently intends. A permissions review needs to establish whether those two things agree.
The information Copilot reads can be manipulated
Permissions are one part of Copilot security. Organisations also need to consider whether retrieved content can be trusted.
An established attack technique is indirect prompt injection. An attacker places instructions inside material an AI assistant may encounter, such as an email, document or web page. Those instructions attempt to influence how the assistant behaves when it reads the material.
For example, an external email could contain text designed to distort a summary, produce a misleading recommendation or trigger an unintended action. The assistant may have legitimate permission to read the email. The risk lies in treating instructions found inside untrusted content as instructions to follow.
Microsoft has developed safeguards against prompt injection, and provides controls through Microsoft Defender and Purview. Its Purview guidance for Copilot describes a policy condition that can exclude externally received email from Copilot grounding. Organisations need to check the feature’s current release status, licensing and operational effect before using it.
Security researchers have also demonstrated more complex attacks. In June 2026, Varonis disclosed SearchLeak, a vulnerability chain involving Microsoft 365 Copilot Enterprise Search that could lead to disclosure of accessible information after a user clicked a malicious link. Microsoft remediated the reported vulnerability, tracked as CVE-2026-42824. The example demonstrates why AI-specific attacks need attention alongside established web and identity security controls.
Agents need their own permissions review
Copilot can be extended through agents connected to business information and systems. Some retrieve and summarise information. Others can take actions through tools and connectors.
Consider an agent that assists an operations team with supplier enquiries. It might retrieve correspondence and records, prepare a response, or update a system when authorised to do so.
The organisation needs to know who owns the agent, which systems it can reach, which actions it may perform and whose identity is used to authorise those actions.
In Copilot Studio, a connector can use an end user’s credentials or credentials provided by the maker, subject to configuration. Microsoft warns that maker-provided credentials can expose data or actions the end user would not ordinarily have permission to access.
The same questions apply to externally connected sources. The connector must preserve the permissions and restrictions that the business intends to enforce.
As organisations build more agents, ownership, access, approval and monitoring need to remain visible.
Microsoft’s recommended approach to securing Copilot
Microsoft’s current Secure and Governed Data Foundation guidance recommends identifying oversharing, applying interim protections, correcting permissions and establishing controls that continue after rollout.
The sensible starting point is the information that presents the greatest business risk.
1. Identify sensitive information with excessive access
Start with areas such as HR, finance, legal, customer information and commercially sensitive projects. Identify the relevant SharePoint sites and other sources, then review how access has been granted.
SharePoint Advanced Management can report on broad sharing, excessive audiences, ownerless or inactive sites and other indicators. Microsoft Purview provides additional information-protection and data-security capabilities, depending on licensing.
The output should be a prioritised set of findings for business and technical owners to review.
2. Apply temporary restrictions where necessary
Microsoft offers different controls for different purposes.
Restricted Access Control can limit access to specified SharePoint sites to approved groups.
Restricted Content Discovery can reduce the appearance of selected sites in Microsoft 365 search and Copilot discovery. It does not change the underlying access permissions and has documented limitations.
Temporary controls can reduce exposure while a review takes place. They need to be tested, and their impact on legitimate collaboration understood.
3. Correct access and protect sensitive content
Remove unnecessary users, review group membership, correct inappropriate inheritance, restrict broad sharing links and establish clear site ownership.
Microsoft Purview sensitivity labels can classify and protect information. Relevant Data Loss Prevention policies can restrict how Copilot uses selected sensitive information, where supported by the configuration and licence.
The controls have different boundaries. For example, Microsoft’s current Copilot DLP documentation says that its prompt-related inspection does not scan the contents of files uploaded directly with a prompt. Administrators should check the specific policy behaviour rather than assume every route is covered.
4. Review untrusted content and connected agents
Check the controls applicable to external emails and web content, agent authentication, connector access and the actions agents are authorised to perform.
Apply least-privileged access and approval controls appropriate to the business process. Confirm who can create, share and administer agents and who investigates unexpected activity.
5. Monitor after deployment
New sites are created, people change roles, documents are shared and agents are added.
Access reviews, ownership checks, audit records and security monitoring need to continue after the initial rollout. Findings also need someone responsible for deciding and carrying out the response.
Four questions before expanding Copilot
A CIO or IT Director preparing wider adoption should be able to answer four questions.
1. Do we know where our most sensitive information is stored?
Identify the content that would have the greatest consequence if encountered by an unintended internal or external audience.
2. Can we demonstrate that access is appropriate?
Check site permissions, group membership, sharing links and ownership. Review the findings with the people accountable for the information.
3. Do our controls cover the ways people are using AI?
Consider Copilot licences, data-protection policies, external content, connected agents and any use of unapproved AI services. Record where controls or reporting are unavailable.
4. What evidence do we need before expanding deployment?
Agree which issues must be resolved, how changes will be tested and who can approve the next stage of adoption.
The findings may support a phased rollout, targeted remediation or wider work on AI governance. The scope should follow the risks and the evidence.
Know your exposure before expanding AI
Microsoft provides many of the controls organisations need to manage Copilot securely. The challenge is establishing what’s already happening across the environment, where information could be exposed and which issues deserve attention first.
That requires evidence of existing permissions, sensitivity labels, AI tool usage, agent ownership, data quality and the controls already in place.
Servent’s AI Governance and Data Readiness Review is designed to provide that evidence and a practical basis for decisions about wider AI adoption.
The review considers current AI usage and governance across Microsoft 365 Copilot, agents, Power Platform, SharePoint, OneDrive and Microsoft Purview. It uses available administration and security reporting, agreed samples and stakeholder input to identify potential data exposure, control gaps and areas of uncertainty.
Customers receive a prioritised findings register, an executive view of the risks and a sequenced improvement plan with indicative effort. Where the evidence supports it, the review can also recommend a suitable area for controlled Copilot adoption, or identify what must be addressed first.
It is a scoped assessment and recommendations engagement. Implementation, remediation and any detailed assurance work are agreed separately.
For organisations preparing to expand Copilot, or concerned about AI tools already being used across the business, it provides a defined starting point.
Talk to Servent about an AI Governance and Data Readiness Review. Establish what your current environment tells you, where the gaps are and what should happen next.
Discuss an AI Governance and Data Readiness Review.
Gateway to AI is an eight-part Servent series examining what organisations need to develop, deploy and operate enterprise AI.
Previous in the series: AI-ready data: what models and agents need from your data estate.
More from the blog:
