Why Copilot does not leak, and what it does instead

Is the assistant leaking data?

Not in the sense the word implies. An enterprise assistant grounded in an organisation’s own content answers using material the person asking is already entitled to open. It does not read across a permission boundary, and where it cites a document, that person could have opened the document directly.

What it removes is friction. Finding a badly-shared file used to require knowing it existed, guessing where it was, and searching patiently. Asking a question in ordinary language does the same work in one step, for anyone, without needing to know the file exists.

So the finding is real and the diagnosis is usually wrong. The exposure was created by permission decisions taken over years. The assistant made it visible in an afternoon.

Why the wrong diagnosis is expensive

If the assistant is the problem, the remediation is to restrict the assistant: turn it off, limit it to a pilot group, or block it from whole content stores. Each is available, and each leaves the underlying exposure exactly where it was — reachable by every employee, by search, as it has been all along.

It also stalls the deployment indefinitely, because the condition for resuming is never stated. The organisation ends up with neither the productivity nor the fix.

What does the real remediation look like?

Containment first, because the underlying work takes months and the exposure should not stay open for all of them. A data risk assessment to find where sensitive content sits and who can reach it. Restricted access on the worst sites. Bulk remediation of overshared links.

Then the slower work: sensitivity labels on content that matters, data-loss policies wired to those labels, and the permissions themselves reviewed site by site. Microsoft ships the tooling for this inside the assistant licence, which is worth knowing before anyone buys a third-party product to do it.

And then the part that determines whether any of it lasts: defaults that start narrow, links that expire, and a named owner per site who attests to access on a cadence.

Diagnosis	Remediation it implies	What it actually achieves
The assistant leaked data	Restrict or disable the assistant	The exposure remains, reachable by search
The index is too broad	Exclude content stores from indexing	Useful as containment; not a fix
Permissions are wrong	Contain, then correct, then govern	Removes the exposure and keeps it removed

Where the assistant genuinely is the risk

Two cases, and they are worth separating from the oversharing conversation because they need different work.

The first is untrusted content. An assistant that reads documents, email or tickets from outside the organisation can receive instructions inside them, which is prompt injection rather than a permission problem.

The second is agency. An assistant that can only read has a bounded worst case. One that can send mail, write records or call tools has a worse one, and the control there is what it is permitted to do rather than what it is permitted to see.

What to tell the board

That the assistant found a pre-existing condition, that the condition is fixable and the fix takes months, that containment is available in days, and that turning the assistant off does not address any of it. That version of the conversation is harder to have and considerably cheaper than the alternative.