You Don't Have to Fix Fifteen Years of SharePoint First

Every AI pilot I've watched stall in a big company stalled on the same question. Not accuracy. Not cost. Someone in security asks:

"If we turn this on, what can it see?"

For any assistant wired into your whole tenant, the honest answer is: everything the person asking can already reach.

That sounds fine. Then somebody actually checks.

Copilot isn't wrong. Its homework is.

Credit where it's due — Copilot honors your existing permissions. It retrieves through Graph, trims to what you can access, and invents no new reach. That's the right design. It's also the only design available if your pitch is "we span everything."

The catch is the precondition. That design is safe exactly as far as your permissions are correct, and in most large organizations they aren't.

Fifteen years of broadly shared sites. Inherited folder permissions. "Everyone except external users." Sharing links nobody remembers creating. None of it mattered much, because finding a file used to require knowing it existed and guessing where it lived. Obscurity was doing real security work.

Good retrieval deletes obscurity. What's left is whatever your access lists actually say.

So the rollout plan becomes: run an assessment, find the overshared sites, remediate, apply restricted discovery as a stopgap, configure data-loss policies for grounding, then deploy. There's an entire consultancy practice around that one sequence now — which tells you how common the problem is and how long it takes to clear.

It's probably worth doing. But look at what it is: a multi-quarter governance project sitting between your legal team and its first useful answer about its own matter files.

That's the part I'd question. Not the cleanup. The order.

Scope down, not out

A tenant-wide assistant scopes subtractively: start from everything you can reach, then remove what shouldn't surface. Every item in that enormous set is something you need to have gotten right.

Findable scopes additively. A chat is pointed at specific sources — a document library, some indexed folders, a database — and that's what it answers from.

Two honest caveats, because this is where vendors oversell.

You're not sealed inside one chat. A user can pull in another source mid-conversation — but only one they're already entitled to, checked on the server every time. What they can't do is widen their own reach. The ceiling is the inventory an administrator registered and granted them, not the contents of your tenant.

And permissions still matter inside the sources you pick. This is a better starting posture, not a free pass.

But that's the useful difference. An overshared site three departments away can't hurt a chat nobody ever pointed at it. You stop betting on every ACL in the building and start betting on one deliberate decision about one body of material — which a review board can actually sit down and inspect.

"A contracts chat, over the contracts library, for the contracts team." That ships in weeks. It doesn't need your tenant to be clean first.

Then it's still per-person

Curation picks the sources. It doesn't pick which documents you see inside them.

Where an index is built with permission filtering — the OneDrive workspace, or SharePoint once an administrator turns on Document-Level ACL — Azure AI Search does the trimming itself, against your delegated token. That happens inside the search service, not in application code that could get it wrong.

Elsewhere, the filter is built from your Entra object ID and your group memberships, matched against the access lists captured when each document was indexed.

Here's the part I'd actually test if I were buying: what happens when it breaks.

If your session can't produce a search token, nothing falls back to an unfiltered query. The source is dropped before the search runs, and the chat tells you which one and why — separating "ACL is off for this tenant, go find an administrator" from "your session couldn't get a token, sign in again." A workspace query with no verified identity is refused outright.

Fail-closed is boring. It's also the first thing a good security reviewer checks.

The client gets no vote

All of that would be theatre if the browser could just ask for different terms.

It can't. Ownership, access lists, data sources, model endpoint, memory scopes — none of it is taken from the request. It's read from the stored record.

And it's an allow-list, not a blocklist. The server starts from the trusted record and merges in a short, named set of client-settable fields, so a field nobody thought about is ignored by default instead of accepted by default.

Personal files stay in your own folder behind a filter the server builds. The client picks a scope from a fixed list; it never supplies a path. Two people in one shared chat get different filters.

Identity comes from the session. Never the request body, never the chat id.

If you want to test an AI vendor's access story in a single move: ask what happens when the client lies.

The question to actually ask

Not "is it secure." Everyone says yes.

Ask: can I put this in front of one curated set of documents, for one named group, this month — without fixing my whole tenant first?

If the answer needs a permissions programme, you've just learned something about your next two quarters.

Findable runs inside your own Microsoft tenant: Azure AI Search for retrieval, Azure AI Foundry or Azure OpenAI for models, your identity, your storage, and only the sources you point it at. Request a demo or review our security page.