.svg){kind=icon}
Newsletter
Stay up to date with our monthly newsletter.
Covering the latest thought leadership, events, and news about identity security
.svg)
What We Do
Partners
© MajorKey 2026
.svg)
I've been involved in enough Copilot adoption efforts to know that the AI is rarely to blame if the project stalls. Every deployment I've seen struggle has eventually led back to identity, access, and data hygiene issues that were already there long before AI agents were relevant. Copilot typically works beautifully on top of an unscrutinized, imperfectly protected environment.
Five challenges show up repeatedly:
None of these are AI problems. They’re identity, access, and governance problems that AI exposes faster than any previous technology. The challenges are often the result of years of accumulated identity and data debt, and Copilot is simply the first tool persistent enough to shine a light on them.
I watched one Copilot pilot unravel in its second week after someone asked about a planned reorganization that had not yet been announced. Copilot promptly surfaced the planning deck from a SharePoint site that had been left open to the broader organization during a migration years earlier. There was no breach and no exploit. The document was accessible, the permissions were in place, and Copilot simply connected the dots. The mood in the room changed immediately.
In my experience, most Copilot rollout challenges fall into five predictable categories. Here’s what they are and how to address them.
Access has always had two dimensions: what you're allowed to open, and what you're likely to find. Organizations accumulate broad access rights without worrying much because most people never stumbled across what they could technically reach. In practice, obscurity became part of the control.
Copilot removes that obscurity and makes discovery effortless. Ask a reasonable question and Copilot can surface information from anywhere your account already has permission to access. Suddenly the group named "Everyone," the SharePoint site left open after a migration, or the salary spreadsheet parked somewhere convenient becomes easy to find.
I've run a single query during a discovery workshop and watched the mood in the room shift instantly. Teams assume they've uncovered a Copilot problem when what they've found is years of accumulated permission debt. Unfortunately, there isn't a quick switch to fix it. Cleaning it up usually means weeks of permissions analysis, ownership reviews, and remediation. More than any other issue, this is where I've seen Copilot rollouts lose momentum.
The Fix: Before go-live, use SharePoint Advanced Management's Data Access Governance reports to identify sites shared with "Everyone" or "Everyone Except External Users" and remediate the sensitive ones first. If you need breathing room, enable Restricted SharePoint Search while you work through the cleanup, then remove it once permissions are under control. SharePoint Advanced Management is included with Microsoft 365 Copilot.
Copilot honors the security labels applied to data. Unfortunately, most organizations haven't applied many and have half-finished data classification programs. While DLP policies exist, they’re mostly for compliance. If you ask five people what "confidential" means, you’re likely to get five different answers.
For years, an incomplete data classification program wasn't an issue because most documents were rarely read. The gaps in the classification strategy remained largely invisible because very few people actively searched for the information. Copilot changes that equation, as it reads everything it can access and doesn't infer undefined boundaries. If content isn't labeled or protected, how could Copilot treat it as sensitive?
The Fix: Start with a small set of high-value sensitivity labels and use auto-labeling to cover the content users didn’t classify themselves. Pair that with Purview DLP policies for Microsoft 365 Copilot to prevent sensitive information from being used for grounding. Don't try to build the entire taxonomy at once. Focus on the most sensitive content and expand from there.
Copilot runs with the user's permissions, and people often cite that as a safeguard. I've never found it particularly reassuring.
Time and lack of interest keep most over-permissioned employees out of trouble – not policy. A user may technically have access to payroll data or HR records, but they have neither the need nor the inclination to go looking. Copilot doesn't share those limitations. It can instantly retrieve information from anywhere a user already has access. Every admin role that was never removed and every entitlement that outlived its project becomes accessible again through a well-phrased prompt.
What catches many teams off guard is that there is no separate "Copilot session" to govern. Copilot operates through the same Microsoft 365 applications and Graph permissions the user already relies on. That means your existing device, risk, and session controls must already be working as intended, because Copilot inherits them exactly as they are.
The Fix: Reduce standing privilege before deployment. Move administrative roles to just-in-time access with PIM, run regular access reviews to remove unnecessary privileges, and ensure device compliance and risk-based Conditional Access policies protect the underlying Microsoft 365 and Graph access that Copilot uses.
“If there's one hill I'm willing to die on, it's this one: clean up standing access before you turn Copilot on.”
So far, the challenges I’ve discussed involve Copilot finding, retrieving, and presenting information. While that introduces important governance concerns, it is still fundamentally a read-oriented problem. Agents introduce something entirely different: action. They can open tickets, update records, trigger workflows, and make changes across systems. That shift is what completely changes the risk model and, frankly, is the issue that keeps me up at night.
A service principal used to feel like plumbing: necessary, predictable, and easy to overlook. An agent is different in that it has a goal, a way to pursue that goal, and often more access than teams realize. In many environments, non-human identities already outnumber people, yet they receive far less scrutiny. Humans must prove who they are, while agents often get a client secret, broad permissions, and informal approval.
Copilot demos are impressive, but they usually show the perfect scenario with an agent that only touches the systems it is meant to touch and completes the assigned task. Demos rarely show what that agent could reach if the prompt went sideways, the workflow was misconfigured, or the identity behind it had more access than anyone intended.
The Fix: Govern agents like the workloads they are. Give each one a scoped, least-privilege identity, prefer Sites.Selected over Sites.Read.All, replace long-lived secrets with workload identity federation or short-lived certificates, apply Conditional Access to workload identities, and assign every agent an owner, purpose, and expiration date.
I'd be oversimplifying if I blamed every stalled rollout on identity. Plenty fail for ordinary human reasons. For example, the pilot that goes well but never ends, or Copilot launches without training and gets adopted by almost no one. Those failures are less dramatic than a permissions issue, but they can be just as fatal.
The Fix: Define the success metric and adoption plan before the rollout begins. Fund training and change management as part of the project, not as an afterthought, and set a clear date to prove the value or shut the pilot down.
None of these challenges are a good reason to avoid Copilot or AI in general. They are reasons to prepare for it properly. Copilot and agentic AI will surface the permissions, labels, access paths, and adoption gaps that already exist in your environment, so the real work is making those risks visible and manageable before the rollout reaches production.
Organizations don’t need perfect permissions, perfect labels, or perfect governance to begin deploying Copilot. They do need visibility into their biggest risks and a plan to address them.
Start with oversharing, then use that momentum to tighten classification, reduce standing access, govern agents, and define what success should look like.
If you’re unsure where those risks exist in your environment, MajorKey’s AI Readiness Advisory Assessment can help identify oversharing, permission debt, governance gaps, and agent risks before they become rollout blockers.
Active Directory Domain Services relies heavily on LDAP, but not every LDAP connection is automatically protected against interception, modification, or authentication-relay attacks.
Learn why modern PAM strategies must extend beyond administrator accounts to include machine identities, cloud entitlements, Just-in-Time access, and Zero Standing Privilege. Dan Ross shares practical guidance for building a scalable privileged access program.
What C-suite leaders need to know about the upcoming Microsoft Entra ID SSPR changes, its operational risks, and how to mitigate them.
Auditors don’t just ask who has access today. Identity governance needs to be reframed as a continuous regulatory defense, not a periodic compliance exercise.
When effective change management is integrated with IGA implementations from the start, organizations reduce resistance, increase alignment, and ensure new identity processes take root in a sustainable, scalable way.
Learn about the challenges created by identity silos, the trade-offs between consolidation and governance, and how organizations can determine the most effective path forward.
Covering the latest thought leadership, events, and news about identity security