Glean vs Microsoft Copilot: The Permissions Gap That Decides the Deal

Glean and Microsoft Copilot both promise a single answer layer over everything your company knows. The demos are close to identical. The difference shows up in the permission plumbing, and Microsoft's own documentation states it plainly: connector access control changes sync only during a full crawl, which defaults to daily. This comparison is about crawl schedules and consent screens, not answer quality.

What you are actually choosing between

Microsoft 365 Copilot is an add-on licence that gives an assistant access to an index your tenant already builds. Glean is a separate product that builds its own index by crawling your systems, Microsoft's included. One extends an index you own. The other stands a second one up beside it.

That single architectural fact drives almost every real difference, including the ones that stall deployments. It is also the part the demos hide, because both demos are a chat box.

Copilot rides an index you already have

Content that lives inside Microsoft 365 is already indexed and already permissioned. Copilot queries it under the signed-in user's identity, and SharePoint and Exchange decide what comes back.

For anything outside Microsoft 365, Copilot uses connectors. Microsoft documents two kinds. Synced connectors crawl the source and write each item into the Microsoft Graph index with an access control list attached. Federated connectors use a Model Context Protocol pattern and fetch results live, storing nothing.

The distinction matters more than the connector count does. A synced connector means a copy of your Confluence permissions now lives in Microsoft's index. A federated connector means it does not.

Glean builds a second index next to yours

Glean's model is uniform across every source, including SharePoint. Its connectors, in the company's own words, fetch each source's permissions map so results only show a user what they are already allowed to see. That map is a copy, held by Glean, refreshed on a schedule.

Glean has since added real-time access for SharePoint, which supplements indexed results with content fetched live. The documentation is candid about why it exists. It lets users find recent content "without waiting for a full crawl cycle", which is an admission that indexed results wait.

The last two rows are asymmetric because the disclosure is asymmetric. Microsoft publishes list pricing and quota limits. Glean publishes neither. Every figure you will see for Glean pricing traces back to buyers, not to the vendor.

Connector counts are the headline, and the least useful number here

Glean advertises 275 or more out-of-the-box connectors. Microsoft Learn states that Microsoft offers over 100 prebuilt connectors. It names Box, Dropbox, Google Drive, Confluence, MediaWiki, network file shares, Salesforce, ServiceNow, Dynamics 365, SAP, Workday, Zendesk and Jira among them.

I would treat any 2026 comparison claiming Copilot cannot search Salesforce or Confluence as unread. Microsoft's own connector gallery lists both, and has for some time. The gap between 275 and 100 is real, and for most buyers it resolves to a handful of systems nobody in the room can name until you ask.

So ask. Write down the systems your answer layer must cover, then check each one against both galleries. That list is usually shorter than the sprawl suggests, which is a different problem from the one described in the analysis of 291-app portfolios and what rationalisation removes.

Federated connectors change the Microsoft answer

Microsoft's federated connectors are read-only, index nothing, and query the source in real time using OAuth on behalf of the signed-in user. For a sensitive system, that is a materially better security posture than copying its contents into a second index.

There is a licensing catch, and it is worth knowing before the demo. Federated connectors require a Microsoft 365 Copilot add-on licence for every user who queries the source. They are not available with a Copilot Studio licence or with pay-as-you-go. That clause turns a pilot into a full rollout decision, and it belongs beside the contract clauses worth negotiating before signing an AI deal.

Permissions handling is where the two genuinely differ

Both vendors use nearly the same sentence in marketing. Users only see what they are already allowed to see. Both sentences are true. They are true in different ways, and the difference is the whole comparison.

Native content is checked against the source

When Copilot answers from a SharePoint document, the permission decision belongs to SharePoint at query time. Revoke access and the next answer reflects it, because there is no separate copy of the rule to update.

This is the strongest single argument for Copilot on a Microsoft-heavy estate, and most comparison posts skip it because it is unglamorous. There is no synchronisation step to get wrong when there is nothing to synchronise.

Connected content is checked against a copy

Every other case in both products works on a copy. The crawler reads the source's access rules, stores them next to the indexed item, and the search engine filters against the stored copy rather than asking the source.

That copy is correct at the moment it was taken. Its accuracy after that is a function of the refresh schedule, and refresh schedules are documented in places buyers rarely read. Microsoft's Confluence connector defaults to an incremental crawl every 15 minutes and a full crawl once a day.

The refresh window neither vendor advertises

Here is the sentence that should decide a lot of these evaluations, taken verbatim from Microsoft's connector documentation: "Incremental crawls don't pick up access control list (ACL) changes or deleted items." The same page adds, in its user settings section, that "Updates to permissions sync only during full crawls."

Read those together with the defaults. A permission change made just after a full crawl waits until the next one. The default full crawl interval is daily. The 15-minute incremental crawl that keeps content fresh does nothing for permissions at all.

Microsoft: access control changes land on the full crawl

This is configurable. You can run full crawls more often, at a cost in load on both the source system and the connector agent. Most tenants do not change the default, because nothing in the setup flow suggests they should.

The failure mode is specific and easy to picture. Someone is removed from a Confluence space at 10am. Until the next full crawl completes, Copilot can still surface that space's pages to them with a citation. Nothing has been breached and nothing has been misconfigured. The index is simply telling the truth as of yesterday.

Glean: webhooks, or 24 hours

Glean's design answer is webhooks. When access is revoked, the source notifies Glean and Glean updates its records. That is genuinely faster than a scheduled crawl, and it is the right architecture.

It also has a documented dependency. Webhook subscriptions expire and must be re-authorised, and Microsoft requires the Files.ReadWrite.All scope to do it. Glean's security FAQ states that without it, permission changes "will only be reflected on completion of a manual fetch (incremental crawl) by Glean every 24 hours". A security team that trims that one scope has quietly bought a 24-hour window.

Elsewhere the interval is different again. Glean's Confluence Cloud connector documents an identity crawl, which captures user and group membership changes, running every 8 hours. There is no single number for either product. There is a number per connector, and it sits in that connector's own page.

What each vendor asks for at the security review

This is where deals stall, and it is the stage no demo covers. Both products need privileged access to your systems. They need it in opposite directions.

Glean's SharePoint connector requires, as application permissions rather than delegated ones, the following Graph scopes: User.Read.All, GroupMember.Read.All, Member.Read.Hidden, Sites.Read.All, Sites.FullControl.All, Files.Read.All, Files.ReadWrite.All and Reports.Read.All. It also requires Sites.FullControl.All on the SharePoint REST API. Glean's stated reason for the Graph full-control scope is narrow and specific: to "retrieve details regarding permission update events".

I do not read that list as carelessness, and neither should your security team. Glean's FAQ says it "had no choice but to update our setup instructions" because permission-only changes stopped being reflected under the read-only alternative. That is a constraint of Microsoft's API surface, handed to a competitor. It is worth sitting with. A platform owner setting the terms on which rivals read its data is the dynamic described in the piece on integration depth as a defensible moat.

Microsoft's ask points outward instead. Its prebuilt synced connectors require admin access to the external service, for example Google Workspace Super Admin or Confluence Admin. They also need service credentials and, for on-premises sources, an agent installed on your network. Different blast radius, same category of question.

Oversharing is a Microsoft-shaped problem in both cases

The reason enterprise search feels dangerous is rarely the search product. It is that a decade of SharePoint sharing has left files readable by more people than anyone intended, and a good search engine finds them.

Microsoft's first control for this was Restricted SharePoint Search, an allow list of up to 100 sites. Microsoft's documentation is unusually blunt about its limits. It "isn't a security boundary and doesn't change any permissions". It does not guarantee that only allow-listed sites appear, and Microsoft itself calls the 100-site cap unsustainable as an organisation scales. New enablement was blocked from 31 July 2026.

The successor, Restricted Content Discovery, is better designed and slower to act. It is site-level, it removes Copilot entry points from restricted sites, and it requires both a Copilot licence and SharePoint Advanced Management. Microsoft states that for sites with more than 500,000 items, an update "could take more than a week to fully process and reflect in search and Copilot experiences".

Here is the part that matters for the comparison. Buying Glean does not solve this. Glean reads the same access control lists, faithfully, and will surface the same overshared file to the same person. Every credible remediation path runs through permission hygiene in the source, which is why the exposure math in the breakdown of what unmanaged AI access costs lands on governance rather than on tooling.

Where this argument is weakest

Three places, and the first two are load-bearing.

The connector gap is closing faster than the framing admits

Microsoft ships connectors continuously, and the federated model means new sources no longer require an indexing pipeline at all. A coverage advantage measured in 2026 is a wasting asset when the competitor owns the productivity suite and the identity provider.

Glean's counter is that breadth plus a permissions-aware graph across all of it is the product, not any single connector. That is a real answer. It is also the argument made in the comparison of data moats against workflow moats, where the durable position was the one nobody could re-index their way into.

Permission latency may not be your binding constraint

Most permission changes are not urgent. The urgent one is offboarding, and offboarding is usually handled by disabling the identity, which blocks both products at sign-in regardless of what any index believes.

If your threat model is a departing employee, the crawl schedule is close to irrelevant. If it is an internal reorganisation, a contractor rotating off a project, or a deal team that must not see another deal, the crawl schedule is the control, and it is measured in hours.

The third weakness is the source base itself. Almost everything above comes from vendor documentation, which is written by the party with an interest. I have preferred the pages where each vendor documents its own inconvenient defaults, because a company is unlikely to overstate the staleness of its own index. Independent measurement of either product's permission propagation time does not appear to be published anywhere.

A test you can run before you sign either contract

Vendor benchmarks compare answer quality on questions the vendor chose. Run this instead. It takes a morning, and it is the same discipline that separates a working pilot from the pattern catalogued in the review of how agent pilots actually fail.

Question four is the one that tells you most. A vendor who helps you find an overshared document in your own estate is selling you a governance programme with a search engine attached, which is what you actually need. A vendor whose answer is that this cannot happen has not deployed into an estate like yours.

Frequently asked questions

Where to start this week

Do the boring half first, because it changes the shortlist. Pull a Data Access Governance report on your ten largest SharePoint sites and count how many carry organisation-wide sharing links. That number decides whether you are buying search or buying a cleanup, and it is the same number either vendor will meet on day one.

Then run the revocation test from the table above during both trials, on the same document, with a stopwatch. Two vendors, one measurement, a number you generated rather than one either of them published. It will not tell you which product answers better. It will tell you which one you can explain to an auditor, and in my experience that is the constraint that decides these deals.

Related reading