That distinction matters when assessing a new vendor-sponsored survey from Microsoft 365 governance specialist Syskit. Its results are concerning, but they should not be read as a measured breach rate across all enterprises or as proof that Copilot itself causes permission failures. They are best treated as a warning from a specific group of IT and cybersecurity decision-makers: organizations may be entering AI deployments with an incomplete picture of who can reach their data and why.
What the survey does—and does not—show
Syskit said its research covered 327 IT and cybersecurity decision-makers at organizations with at least 500 employees in the US and UK, surveyed from May through July 2026. That is a meaningful professional audience, but it is not a scan of Microsoft 365 tenants, a forensic review of incidents, or a representative census of every large organization. It is also sponsored by a company that sells governance technology, an interest that does not invalidate the findings but does raise the bar for careful interpretation.
The headline statistic needs especially close handling. Syskit reports that 90% of respondents experienced a confirmed or suspected security incident related to Microsoft 365 misconfiguration or over-permissioned access in the preceding two years. Reported coverage of the survey further says 39% described an incident as confirmed.
Those are not interchangeable claims. “Confirmed or suspected” can capture a broad set of events: an investigation, a near miss, an anomalous access pattern, a policy violation or a verified exposure. Without the full questionnaire, incident definitions, response rate, sampling method and methodology, readers cannot determine how comparable those answers are across companies. Nor can they infer how many incidents involved actual data loss, external compromise, disclosure obligations or financial damage.
Still, even a perception survey can identify an operational problem worth testing locally. If security leaders repeatedly report uncertainty around permissions and believe that access control contributed to incidents, the prudent response is not to accept a headline as universal fact. It is to validate the organization’s own access posture.
The AI readiness gap is more concrete
The survey’s most useful signal may be the relationship between AI adoption and preparation. Syskit says 76% of respondents had deployed or piloted an enterprise AI tool using Microsoft 365 data. Independent coverage reported that only 43% had completed a thorough permissions and oversharing review before doing so; the others undertook a partial review or no review.
That gap is credible as a governance concern because AI systems change the practical discoverability of information. A collection of loosely shared files can be difficult to navigate manually. A user may need to know that a document exists, where it is stored, and how to search for it. Conversational AI can reduce that friction by turning a broad question into a summary that brings relevant authorized material together.
For employees, that can be the point of the product: faster retrieval of project history, decisions, documents and communications. For an organization with stale access rights, it can also expose the consequences of permissions that had been technically valid but rarely noticed. A former project member still in a group, a site shared too broadly, or a document library open to a wider internal audience than intended can become more consequential when its contents are easier to surface.
The correct conclusion is not that teams must stop using AI until every piece of historical content is perfect. Large tenants are rarely pristine. It is that AI rollout should be paired with an explicit, risk-based process for finding and reducing excessive exposure, particularly around high-value data and broad collaboration spaces.
Copilot does not automatically bypass authorization
The technical boundary here is important. Microsoft’s documentation says Copilot can summarize or reference content a user is authorized to access. It does not independently change SharePoint or OneDrive permissions or grant a person entitlement to a file they could not otherwise reach.
So it would be inaccurate to say Copilot inherently creates access to every old file, every ownerless workspace or every restricted Teams channel. Whether content can be found or referenced depends on the existing authorization model and on relevant SharePoint, OneDrive, sensitivity, discovery and policy controls. Different AI products, agent configurations and third-party applications may have different permission models, so broad assertions about “AI tools” need comparable care.
However, “Copilot respects permissions” should not become a reason to dismiss the governance issue. It means access remediation remains the central task. AI can amplify pre-existing oversharing by making authorized-but-unintended content easier for an authorized user to locate. In a practical security review, the question is often not merely, “Can this employee open the file?” It is, “Should this employee still be able to discover this information, and are we confident we can explain the path that grants access?”
Microsoft itself recognizes that Copilot and agents can introduce or amplify security, privacy, compliance and governance risks. Its published mitigation direction includes identifying overshared data, restricting Copilot and agent discovery or access while remediation is underway, using sensitivity labels and data loss prevention controls, and archiving or deleting material no longer needed.
That is a more useful model than either extreme: neither “AI is an unavoidable data leak” nor “permissions solve everything automatically.”
Agent governance may be the next weak point
The risk becomes more complicated once organizations move beyond a general AI assistant to purpose-built agents. Agents can be designed to query knowledge bases, automate business tasks, act on prompts or connect to specific business data. Their scope, identity, delegated authority and lifecycle need governance of their own.
Independent reporting on Syskit’s findings said just 22% of respondents had a formal policy defining what AI agents may access. The same reporting said 91% felt confident they could identify active agents and their reach, while 9% allowed an agent to inherit the full permissions of the person deploying it.
These are survey-reported figures, not independently audited implementation data, and the complete methodology was not available in the material reviewed. Yet the underlying design concern is clear. Full inheritance from a deployer may be expedient for a prototype, but it can be difficult to justify as a durable production model. An employee’s access can be broad, change over time, and include material unrelated to the agent’s intended job.
A stronger approach is to define the agent’s purpose first and then give it a narrowly scoped identity and data boundary. An agent that answers benefits questions should not need broad access to legal workspaces; one that helps a sales team should not silently inherit access to all executive communications because its creator had those rights. The organization should also be able to answer basic questions quickly: which agents are active, who owns them, which data they can retrieve, which actions they can take, how their permissions are reviewed, and what happens when the owner changes roles or leaves.
Labels and policies are vital, but not infallible
Sensitivity labels, encryption, DLP and access policies remain important layers of defense. They can classify sensitive material, control sharing, restrict handling and support compliance obligations. But policy intent and real-world behavior are not always identical.
A reported Copilot Chat issue in 2026 illustrates the point. Protected emails from Outlook desktop Drafts and Sent Items could be processed despite sensitivity labels and policies intended to exclude them. Microsoft said it identified and addressed the issue through a global configuration update. It also said the flaw did not grant users access to information they were not already authorized to see.
This does not show that labels are ineffective or that every protected email was exposed. It does show why organizations should not treat any individual control as an absolute guarantee. Security architecture depends on defense in depth: correct permissions, well-maintained classifications, tested policy behavior, monitoring, prompt remediation and a workable process for reporting unexpected results.
For regulated or highly sensitive workloads, teams should validate behavior in their actual environment. Test relevant scenarios involving labeled content, drafts, sent mail, SharePoint libraries, OneDrive, Teams and the precise AI features enabled for users. Testing should be authorized, controlled and documented, with findings translated into configuration changes or temporary restrictions where needed.
The problem extends beyond native sharing
Traditional Microsoft 365 permissions are only one part of the access picture. Third-party applications can request scopes through the Microsoft 365 ecosystem, and those requests can create another route to valuable tenant data.
A separate 2026 research preprint examined more than 8,000 Microsoft 365 applications. Its authors found that only 1,069 exposed both descriptions and permission sets, and they identified potentially overly broad tenant-wide scopes. As a preprint, the work should not be treated as final consensus research. It nevertheless reinforces a sensible operational lesson: organizations need an inventory not only of users and groups, but also of connected applications, consented permissions, service principals and automation accounts.
An app review should ask whether the requested permissions are proportionate to its purpose, whether the app is still in use, whether administrative consent remains necessary, and whether a less privileged integration model is available. A trustworthy vendor name is not a substitute for a least-privilege review.
A practical Windows and Microsoft 365 checklist
For administrators, the most productive response to the survey is a measurable governance program rather than an all-or-nothing Copilot decision.
1. Map high-risk exposure first
Start with sites, Teams, OneDrive locations and groups holding financial data, HR records, legal material, customer information, product plans and executive communications. Identify broad internal access, anonymous or external sharing where applicable, stale memberships and content that no longer has a valid business purpose.
2. Review ownership and lifecycle
Ownerless or poorly maintained workspaces deserve attention, but they should not automatically be portrayed as universally accessible. Assign accountable owners, establish recertification dates, and archive or delete content that is no longer required. A workspace without a clear owner is harder to review, defend and remediate.
3. Reassess group membership and inherited access
Look for large groups that have accumulated exceptions over time, former project members, nested access paths and permissions granted directly to individuals. Prefer manageable, purposeful groups over one-off permanent grants, while recognizing that the right model varies by organization.
4. Govern AI and apps as identities
Maintain an inventory of approved AI tools, agents and third-party apps. Document their owners, purposes, permissions, data sources and review dates. Avoid treating pilot configurations as permanent production architecture. Restrict discovery or access where remediation is still in progress.
5. Test safeguards instead of assuming them
Validate labels, DLP rules, retention settings and AI behavior against the sensitive workflows that matter to the business. When product behavior changes or a security issue is disclosed, repeat relevant tests and confirm that the remediation works in the tenant.
6. Give employees a clear escalation path
Users are likely to notice surprising AI answers before a formal review does. They need a simple way to report content that appears improperly surfaced, along with guidance not to redistribute it. Rapid triage should determine whether the cause is legitimate authorization, oversharing, an agent configuration, an application permission or a product defect.
The durable lesson
Syskit’s survey cannot establish that 90% of enterprises suffered confirmed Microsoft 365 security incidents, nor can it prove that Copilot caused the problems respondents described. The combined confirmed-or-suspected figure, vendor sponsorship and unavailable full methodology all limit that interpretation.
But the narrower warning is sound: AI adoption raises the stakes of permissions that organizations have allowed to drift. The remedy is not panic or a claim that AI overrides Microsoft 365 authorization. It is disciplined access governance, agent-specific least privilege, application-consent review, policy testing and data lifecycle management.
Organizations that treat Copilot as a prompt to clean up longstanding access debt may gain both safer AI use and a healthier Microsoft 365 environment. Those that treat AI as merely another interface to existing content may discover that their old sharing decisions were more consequential than they realized.