copilot just read your ghost accounts

Here is a story that happened, in some version, at hundreds of companies during 2024.

A mid-market company rolls out Microsoft 365 Copilot. Licenses go to 150 users across finance, marketing, sales, and engineering. The rollout is celebrated internally. There’s an all-hands. Somebody makes a deck about productivity.

On day six, a marketing coordinator, two years at the company, junior title, scope limited to the brand team, asks Copilot to summarize “everything being discussed about the strategic projects for Q3.” She meant the brand campaigns. She gets a bulleted list that includes the acquisition target memo prepared for the board, the termination timeline for the VP of sales, the compensation bands for the next round of promotions, and a summary of last month’s legal correspondence about a data subject access request.

None of this was hacked. None of it was exfiltrated. The marketing coordinator did not escalate privileges, did not compromise a credential, did not bypass a control. She asked a question in English. Copilot traversed every SharePoint site, every OneDrive, every Teams channel, every email her user identity had permission to read, which, because of how Microsoft 365 permissions had drifted over three years of reorgs, team sprawl, and “share with everyone in the company” defaults, was considerably more than anyone thought.

The security team’s postmortem report had one finding and one fix. The finding was that a large volume of sensitive internal data had been set to “everyone in the company” permissions, inheritance chains had pulled private documents into overshared sites, and a decade of SharePoint sprawl had produced an access graph nobody could read. The fix was that the company disabled Copilot for the rest of the quarter while they rebuilt the permissions model.

The Copilot deployment worked exactly as designed. What broke was the permissions model that Copilot was designed to respect.

This essay is about the thing that story illustrates, at a much broader scale. AI assistants, Copilot, Glean, Gemini, internal RAG systems, every agentic tool that reads corporate data to answer questions, are the highest-fidelity access audit anyone has ever deployed in an enterprise. They are testing the access graph at machine speed, against real user queries, across the full data surface of the company, in a way that no audit tool ever has.

And what they are finding is that the access graph was broken the whole time.

“technically accessible” was fine when nobody read it

Most corporate permission systems have a long tail of data that is, strictly speaking, accessible to more people than the data owner intends. A SharePoint site shared with “all employees” because the finance team couldn’t figure out who the specific audience should be. A Google Drive folder shared via a link that got forwarded once in 2022. An email distribution list that includes twenty-three people who left the team three reorgs ago. A Confluence space that was set to “anyone at the company can edit” when it was created as a draft and never got locked down after it went live.

None of this was supposed to be read. The permissions were wide open, in a dozen small ways, and the only thing protecting the content was the fact that nobody was going to click into a random finance SharePoint site looking for interesting reading, and even if they did, they wouldn’t know what to look for, and even if they did know, they would be one person browsing at human speed.

“Technically accessible” was a different category from “actually read.” Security teams implicitly relied on the gap between them. The gap was where all the operational slack in the access model lived, the permission mistakes, the inheritance quirks, the “share with everyone” defaults, the orphaned sites that nobody closed.

Copilot collapses the gap. Or Glean does, or the internal RAG system does, or the agentic tool that indexes every document a user is authorized to see and then answers questions by retrieval over that corpus. The moment an AI assistant exists in the environment, “technically accessible” becomes “regularly read,” because every user query spawns a retrieval pass across every document the querying user has permission to see.

The security model that depended on nobody bothering to look stops working when something is always looking.

the threat model changes from traversal to aggregation

Human access to data has a natural rate limit. A person can read a document. A person can read ten documents in an hour. A person cannot, in any practical sense, read every document they have access to. This is why overly broad permissions have historically been a latent risk, real in theory, small in practice, because the consumption bandwidth was human.

An AI retrieval system does not have this rate limit. A Copilot query fans out across potentially thousands of documents in seconds, ranks them by relevance to the query, composes the highest-ranked content into a single response, and presents it as a synthesized answer. The action a user couldn’t do, read every document in the company they happen to have permission to see, find the most sensitive content in that corpus, and summarize it, becomes the default action of a single query.

This is a different threat model. Call the old model traversal risk: how deep can an attacker go with the permissions they have? Call the new model aggregation risk: how much can a legitimate user synthesize across everything they’re authorized to see?

Traversal risk is well-understood. Blast radius, lateral movement, privilege escalation, these are the concepts security teams have built their worldview around. Controls map to traversal: least privilege, network segmentation, zero trust, microperimeters.

Aggregation risk is new and most organizations have no mental model for it. The threat is a legitimate user synthesizing across everything they’re technically authorized to see, at speeds and scales the underlying permissions were never designed to withstand, producing outputs that reveal what the permission boundary was supposed to hide through obscurity.

You can have a perfectly configured least-privilege environment at the application level and still have a massive aggregation problem at the data level, because the two layers have different permission semantics and the AI operates at the second one.

what changes when an AI assistant arrives

before

traversal

• Overshared data existed, but finding it took effort
• Nobody browsed the old SharePoint sites
• "Technically accessible" was safe in practice

after

aggregation

• The assistant searches everything the user can reach
• Old, forgotten content surfaces in answers
• Every overshare becomes findable in seconds

hallucinations are downstream of the permission problem

A large share of the “AI is unsafe” conversation in 2024 and 2025 focused on hallucinations. The model makes things up. The model confidently states wrong information. The model can be manipulated via prompt injection.

These are real problems. They are also, often, framed in a way that obscures a more important underlying problem. A meaningful fraction of the incidents labeled as “Copilot gave wrong information” or “Copilot leaked data” are accurate retrievals from documents the user had permission to see but shouldn’t have. The model is reading, correctly, from documents that an access audit would have flagged five years ago, if anyone had ever run one at the level of detail Copilot operates at.

When a junior analyst asks Copilot about “the team restructure timeline” and gets an accurate summary of the executive memo about the upcoming reorg, the AI performed correctly against an overshared document. The failure sits one layer down: the document was accessible in the first place.

This matters for how the problem gets fixed. A company that treats AI data leakage as a prompt injection problem will invest in input filtering, output moderation, and content policies on the AI system. A company that treats it as an aggregation risk downstream of a permissions problem will invest in sensitivity labeling, inheritance cleanup, SharePoint permissions remediation, and least-privilege at the data layer. Both companies will appear to be addressing the problem. Only the second one will actually reduce it.

deploying copilot is an accidental audit

The operational pattern inside companies that rolled out Copilot or similar tools in 2024 was almost always the same. Deployment proceeds. Within two to six weeks, users discover that the tool can surface documents nobody intended for them. The security team gets a request to investigate. The investigation reveals a permissions model in worse shape than anyone thought. The tool gets partially or fully rolled back. A remediation project gets funded.

This is the accidental audit. The company paid for a productivity tool and discovered, as a side effect of deploying it, that the access graph they’d been running for the last decade was several orders of magnitude more permissive than their policies implied. The tool revealed a vulnerability that had existed for years.

The companies that handled this well treated it as a gift. They had been trying, and failing, to justify a large SharePoint remediation project for years. The Copilot deployment generated a business case that the access problem, on its own, had never been able to generate. Every executive now had a concrete memory of an embarrassing Copilot query. The remediation budget appeared.

The companies that handled it badly treated it as a Copilot problem. They rolled back the tool. They blamed the AI. They moved on. Six months later, someone else deployed Glean, or ChatGPT Enterprise, or an internal RAG system, and discovered the same thing, because the underlying permissions problem had never been fixed.

The latent access mess doesn’t go away because you turn off the tool that revealed it. The mess goes away only if you fix it.

data access creep is not app access creep

The identity industry spent a decade getting better at application-level access. Who has a login to which tool. Which groups have admin versus read. Which accounts should have been deprovisioned. This is app access creep, and it’s the problem my previous essays have focused on.

Data access creep is a different and more consequential problem. It’s about what each user can read within the applications they have legitimate access to. A marketing user can legitimately log into SharePoint. The question is which of the 3,847 sites in that SharePoint tenant they can actually read, and which sites inherited permissions from a parent they should have been detached from, and which documents were shared via a link that’s been in someone’s email for four years, and which Teams channels have “everyone” permissions on their files.

App access creep is resolved at the identity layer, with group membership, role assignment, SSO deprovisioning. Data access creep is resolved at the content layer, with sensitivity labels, inheritance management, permission remediation, and a data classification model that nobody in mid-market has actually done.

AI assistants operate at the content layer. Which means that for the first time in the history of enterprise computing, fixing data access creep has a concrete business driver. The driver is that if you don’t fix it, your AI tool will embarrass you. Every quarter. Repeatedly. In front of executives.

the specific fixes are boring

The fix for this problem is not glamorous. It’s the same kind of data hygiene work that Microsoft’s enterprise customers have been supposed to do for fifteen years and mostly haven’t.

Sensitivity labels applied consistently across the tenant. Inheritance chains audited and broken where a document inherited permissions from a parent it shouldn’t have. “Shared with everyone” permissions reviewed and scoped down to explicit groups. Orphaned sites identified and either owned or archived. External sharing locked down to approved partners only. Data classification taxonomy defined and enforced.

Every one of these is known. None of them is hard to describe. All of them are operationally expensive because they require owners to make decisions about documents they may not remember creating. Mid-market companies have known how to do this work for years. They haven’t done it because nothing has ever forced them to.

AI is the forcing function. The right frame for a security team in 2026 is that every AI deployment in the company is a free audit, paid for by the productivity team, and the findings need to be acted on or the audit gets repeated every quarter with new embarrassment.

This is also why the companies that rush to deploy AI without touching the permissions model reliably end up worse off than the companies that delay the deployment by a quarter to fix the underlying data hygiene. The quarter of remediation work is a one-time cost. The recurring embarrassment of a broken permissions model is a forever cost.

AI readiness is identity readiness

The framing that has taken hold in security discussions, “AI data governance” as a distinct discipline, obscures the actual problem. “AI data governance” is just data governance, which has always mattered, which most companies have underinvested in, and which AI deployments make undeniable.

If the question a board asks in 2026 is “are we AI-ready?”, the honest answer for most companies is “we are not identity-ready, and our AI readiness is bounded by that.” An AI deployment will expose exactly the identity and data access problems that the company has been tolerating for years. The answer is uncomfortable for the board to hear and correct anyway.

Here is the test.

Pick one senior leader at your company, a VP or above, somebody with broad but not unlimited access. Imagine they ask the company’s deployed AI assistant: “Summarize everything you can find about executive compensation, M&A, and personnel changes from the last twelve months.” Don’t actually run the query. Just imagine the output.

If the imagined output includes things that leader shouldn’t see, your permissions model is broken. If you’re not sure what the output would include, your permissions model is broken and you also can’t see it. If you’re confident the output would be appropriately bounded, you’ve either done the data access hygiene work or you’re being optimistic about a system you haven’t tested.

The AI deployment is the test. The access graph is the subject of the test. Most companies would fail. The passing condition has nothing to do with better AI; it’s an access graph that can withstand being read at machine speed.

Start with the graph.