Summary
Request to enhance the Glean OAuth Authorization Server to support OAuth access token scoping at the data source level, and/or provide a mechanism to block issuance of tokens that have access to specific data sources. This capability is required for us to safely adopt Glean MCP server for our environment, where certain data sources are classified as more sensitive and must not be exposed to broad-scoped tokens.
Problem
We are in the process of trialing Glean MCP server as the recommended authentication path for MCP host applications, using the Glean OAuth Authorization Server as described in the Glean documentation.
The current OAuth model:
- Allows Glean to act as an OAuth 2.1 Authorization Server and Resource Server, delegating user authentication to our existing SSO IdP (OIDC/SAML).
- Uses Glean-defined scopes (e.g.
SEARCH, CHAT, AGENTS, MCP, DOCUMENTS, TOOLS, ENTITIES) that govern API capabilities at a functional level, not at a data source level. - For MCP remote servers, relevant scopes are automatically managed during the OAuth flow, without an admin-level way to constrain them per data source.
In our environment, we have different sensitivity tiers across data sources (e.g., some contain highly confidential or regulated information). Our security and compliance requirements mandate that:
- Tokens presented to MCP hosts must not have blanket access across all configured data sources.
- We must be able to confidently ensure that certain high‑sensitivity data sources are never accessible via particular MCP integrations, even if the user is otherwise entitled to see them within Glean.
- Where appropriate, we should be able to limit tokens to a subset of data sources aligned with the intended use case of a specific MCP host.
Because the current OAuth implementation does not provide data‑source‑level scoping or explicit blocking, any token that allows MCP access effectively inherits the full set of data sources available to the user through Glean search/agents. This is a blocker for:
- Rolling out Glean MCP server to production for some of our critical teams.
- Integrating certain high‑risk applications and workflows with Glean until we can guarantee that tokens cannot be used to access high‑sensitivity data sources.
Solution
We are requesting enhancements to the Glean OAuth Authorization Server to allow data‑source‑aware authorization for MCP and future Client API integrations. Specifically, we propose one or more of the following capabilities:
- Data source–scoped OAuth tokens
- Extend the existing Glean-defined scopes model with data source–level constraints, for example:
- Ability to request and issue tokens that are restricted to:
- A whitelist of data sources (e.g.,
datasources:ds1,ds2) - Or that explicitly exclude certain data sources (e.g.,
datasources:all_except_sensitive_groupX).
- Administrative controls to block token issuance for specific data sources
- In the Admin Console, provide configuration that allows admins to:
- Mark some data sources as “OAuth‑restricted for MCP/Client API”, meaning:
- OAuth tokens issued for MCP flows can never include access to these data sources, regardless of user entitlement.
- Optionally define policy sets per client/host (e.g., per MCP host application) that:
- Allow or deny access to specific data sources or data‑source groups when that client is the OAuth audience.
Impact
Implementing data source–level token scoping or explicit blocking would:
- Remove our current blocker for adopting Glean MCP server across the organization.
- Allow us to safely integrate MCP hosts with Glean while respecting our internal data classification and segregation policies.
- Align with the documented goal of offering fine‑grained scopes for future Client API integrations, extending that fine‑grained model from “capability‑based” to include “data‑source‑based” granularity as well.
We would be happy to collaborate on design feedback or early access if this capability is considered for an upcoming release.
Sources
