Glean and Permissions-Aware Enterprise Search: Knowledge Work in Production

Permissions-aware enterprise search targets that failure directly. A platform like Glean indexes across the applications where work actually happens, the document stores, the wikis, the ticketing systems, the chat history, the mail, and answers a natural-language question with content drawn from all of them. The capability that genuinely changed is unified retrieval across the full work estate with entitlements enforced at query time. That second clause is the entire enterprise story.

Why permission-awareness is the load-bearing property

Any system that reads across the whole estate inherits a problem the moment it does so. The estate contains compensation data, legal matters, board material, unreleased plans, and personal records, and every one of those documents has an access model that someone relied on. A search layer that flattens those models during indexing becomes a mechanism for surfacing content to people who were never entitled to see it.

Glean’s design answer is to carry each source system’s permissions through to the result. When you ask a question, the system retrieves only what you were already allowed to open in the originating application, and it re-checks that entitlement at query time rather than trusting a snapshot taken when the document was indexed. The distinction matters because permissions change. Someone leaves a team, a matter closes, a project wraps, and access should follow. A system that resolved entitlements once at index time will happily surface a document the user lost access to last month.

This is the difference between a productivity asset and a data exposure with a search box on the front. It sounds like an implementation detail. It is the whole thing.

The failure mode that survives the demo

The demonstration always answers the question well, because it operates against curated content on a clean tenant. Production behaves differently, and the gap shows up in two places.

The first is upstream permission debt. Permission-aware search enforces the entitlements it inherits, faithfully, which means it also inherits whatever is wrong with them. A folder shared organisation-wide four years ago for a project that ended is now discoverable by a question nobody had thought to ask. The search layer did nothing wrong. It exposed a sharing decision that was always broken and had been protected only by the fact that nobody could find the document. Obscurity was the control, and unified search removes it.

The second is content quality. The index reflects what the organisation wrote, including the outdated policy, the superseded process document, the draft that was never marked as a draft, and the confidently wrong answer someone posted in a channel in 2022. Retrieval ranks by relevance and recency signals, and it will surface an authoritative-looking answer from a document that stopped being true a year ago. The system is working correctly. The knowledge base is the problem, and no search layer repairs stale content.

What operationalising this actually requires

Deployment is a governance programme with a search product attached to the end of it, and the organisations that treat it as an install underestimate the work by a wide margin.

Permission hygiene comes first. The over-broad shares, the flattened migration permissions, the anonymous links created to unblock a deadline and never revoked, all of it needs discovery and remediation before the search layer makes it findable. This is not a one-time pass. Permission debt regenerates through normal work, so oversharing detection has to become a standing function.

Content lifecycle comes second. Someone has to own the question of what is authoritative, mark deprecated material as deprecated, and give the index signals about which sources are canonical. Without that, retrieval treats a stale wiki page and a current policy as equally valid, and users learn to distrust the system.

Sensitivity handling comes third. High-consequence content, HR, legal, M&A, regulated records, needs labelling and, in many cases, exclusion from the general index regardless of individual entitlements. This is the same entitlement-carrying discipline behind COMPASS, where the reasoning layer operates over governed internal sources with permissions preserved through to the answer, and it is why we treat permission integrity as an architectural requirement rather than a configuration option.

The trade-off is worth stating plainly. The more of your estate the system can reach, the more useful it becomes and the more your existing permission debt matters. You cannot get the value without accepting that exposure, so the calibration has to be deliberate and the remediation has to come first.

Where it fits

Strong fit for large organisations with genuine knowledge fragmentation across many systems, where the cost of not finding things is high and the content is broadly collaborative. Engineering, professional services, support, and product functions see the return quickly.

Weaker fit where the sensitive-to-general content ratio is high and labelling is immature, and in environments where information barriers are a regulatory obligation rather than a preference. Those need the governance work finished before the index goes live. Teams building governance for enterprise knowledge retrieval should treat permission integrity and content lifecycle as the two load-bearing controls, because everything else is downstream of them.

The organisations that get durable value here did the unglamorous work before switching the index on. They cleaned up sharing, decided what was authoritative, and labelled what needed protecting. If you are evaluating readiness, the most revealing question to put to your collaboration team is how many organisation-wide sharing links exist in the tenant right now, and how much anyone trusts that number.