MCP Security, Data Flow, and Permissions
This document describes how the Glean MCP server is deployed, how it handles identity and permissions, and how customer data flows when MCP-compatible hosts (for example, ChatGPT, Claude, Copilot Studio, IDEs) connect to Glean.
Use this information as a reference for security, architecture, and compliance to evaluate Glean's remote MCP deployment.
Requests made through the Glean plugins for Cursor, Claude Code, and Codex pass through the same authentication, authorization, source permissions, and policy controls described on this page. See Manage Glean plugin access and security.
1. The Glean MCP server
The Glean MCP server is a managed, remote implementation of the Model Context Protocol (MCP) that exposes Glean's permission-aware enterprise context as standard MCP tools (for example, search, chat, read_document, and selected agents).
Instead of building and operating your own MCP servers, you point MCP-compatible hosts at Glean-managed endpoints such as:
https://{your-backend-domain}/mcp/{server_name}
Find your backend domain at app.glean.com/admin/about-glean under Server instance (QE). It typically follows the pattern company-be.glean.com, but may be different if your organization uses a custom domain.
Each endpoint runs inside your Glean tenant and follows the same security, privacy, and permission model as the rest of the Glean platform.
2. Deployment and hosting model
2.1 Customer-isolated tenants
The Glean remote MCP server:
- Deploys as a dedicated tenant per customer in its own cloud project or VPC. All standard ingestion, indexing, and query processing takes place inside that tenant.
- Reuses the same infrastructure and security boundaries (networking, encryption, IAM, auditing) as Glean search and assistant
- Presents one or more per-server URLs (for example,
…/mcp/default,…/mcp/chatgpt,…/mcp/eng) that admins can create and configure using the Glean Admin console
2.2 Remote MCP: The recommended production deployment
Glean recommends the Glean remote MCP server as the supported deployment model for all production use cases, accessed over HTTPS from MCP hosts such as ChatGPT, Claude, and VS Code, and officially supported by Glean for major MCP hosts.
For information about development-only local MCP servers, see Appendix: Local MCP Servers at the end of this document.
2.3 Network access controls
Glean enforces IP greenlisting at multiple layers:
- Tenant-wide IP greenlists enforced at the network edge, such as the VPC firewall or web application firewall.
- Application-level IP greenlisting for relevant API traffic, including MCP access.
Webhook endpoints that data sources call are exempt from the tenant-wide IP greenlist. Whether the MCP and OAuth endpoints are also exempt depends on where your deployment is hosted:
- AWS: The MCP and OAuth endpoints listed below are exempt from the tenant-wide IP greenlist by default.
- Google Cloud: The MCP and OAuth endpoints stay behind the tenant-wide IP greenlist unless you opt in, as described below.
For deployments hosted on Google Cloud, the tenant-wide IP allowlist also blocks MCP hosts that run in a provider's cloud, such as ChatGPT. Those hosts connect from the provider's network, not yours. To let them connect, contact Glean support to allow public access to the paths they need. This access is off by default. When Glean turns it on, requests from any IP address can reach these paths:
/mcp, the MCP server endpoints/.well-known, for OAuth metadata discovery/oauth/register, for Dynamic Client Registration/oauth/token, for token requests
Every other path stays limited to the IP allowlist. That includes /oauth/authorize, so users must complete the Glean sign-in step from an allowed network. Opening these paths doesn't bypass authentication. Application-level IP allowlists for MCP traffic still apply, so if your deployment has one, review it with Glean support at the same time.
This layered model lets you combine network-level controls with application-level enforcement when you want tighter control over which systems can reach your MCP servers.
3. Identity, Authentication, and Authorization
The Glean MCP server never bypasses Glean's native identity or permission model. It acts as a thin protocol adapter that:
- Authenticates the end user or client via Glean OAuth or API tokens
- Maps that identity to a Glean user in the customer's tenant
- Executes MCP tool calls as that user via Glean's APIs and Knowledge Graph
3.1 Supported authentication methods
MCP servers support the following authentication methods, in order of preference:
Glean OAuth Authorization Server (Recommended)
OAuth 2.0 with Dynamic Client Registration (DCR) where supported by the host. See Glean OAuth Authorization Server and Dynamic Client Registration for more information.
MCP hosts initiate a standard OAuth authorization grant flow: Users sign in to Glean normally with your existing SSO/IdP, and Glean then issues short-lived OAuth tokens with the MCP scope, bound to the MCP server the host connects to.
Enterprise Managed Auth (IdP-managed access)
Your IdP authorizes a specific AI application to reach the Glean MCP server for the users you assign. The application presents a signed assertion from your IdP, and Glean exchanges it for a scoped access token. Users don't connect Glean themselves or see a Glean sign-in prompt. The identity check happens in your IdP. Enterprise Managed Auth (EMA) is in beta and currently supports Claude (Team and Enterprise) with Okta. See Enterprise Managed Auth and Enterprise Managed Auth and access control.
IdP-based OAuth
Customers configure MCP hosts to obtain OAuth tokens directly from their corporate identity provider (IdP), and Glean validates those tokens for MCP access.
User-scoped Glean API Tokens (Fallback)
Client API tokens tied to a specific user and tenant, with the MCP scope. No other scopes are needed for MCP access.
Intended for hosts that cannot yet support OAuth or for development and troubleshooting.
3.2 Authorization and permission enforcement
Once authenticated, the MCP server executes all tools as that specific user, with enforcement at multiple layers:
If a user cannot see or access something in Glean, then they cannot see or access it through MCP regardless of which host application they use.
4. Data flow and residency
4.1 High-level data flow
The following describes the data flow for a remote MCP request, such as Claude asking Glean to read_document:
MCP Host → Glean MCP Endpoint
The host's MCP client opens a streaming HTTP/SSE connection to https://{your-backend-domain}/mcp/{server} using TLS 1.2+.
The request includes an OAuth token or API token bound to a user in the customer tenant.
Within the Customer's Glean Tenant
The MCP server validates the token, resolves the tenant, and routes the request to the appropriate MCP handler for that server.
The handler invokes Glean's internal services such as search, chat, and read_document exactly as if the user had called Glean directly via API or UI.
Response Back to Host
The MCP handler streams structured responses back to the MCP host over the same TLS connection (search results, snippets, answers, tool outputs).
The host's LLM uses this context to answer the user; any further data handling by the host is governed by that host's privacy and security controls.
4.2 Where customer data lives
All indexed content, permissions, embeddings, and query processing occur inside the customer's Glean tenant (their cloud project or VPC). The remote MCP server runs within that same environment, so tool invocations and intermediate results also remain inside the tenant boundary.
4.3 Data sent to MCP hosts
The MCP server only sends data that the user is already allowed to see and only in response to explicit tool calls from the MCP host. Example data includes snippets, metadata, and full documents via read_document.
Once data reaches the host, it is subject to that host's own data processing and retention policies. From a data handling perspective, connecting an MCP host to Glean is equivalent to any application that consumes Glean's APIs.
5. Permissions and tool behavior
5.1 Permission-aware tools
Each MCP tool enforces permissions per the model in Section 3.2:
| Tool | Permission Behavior |
|---|---|
search | Returns only items the user can already access in Glean |
read_document | Can only fetch documents the user may open directly |
| People, org, and code tools | Respect underlying directory, HR, and repo permissions |
5.2 Scope and least privilege
Admins can choose which tools to expose on each MCP server. Access from MCP hosts is controlled via OAuth client configuration (including client IDs, secrets, and redirect URI restrictions) at the tenant level, and applies across all servers rather than being configured per server.
Admins can manage allowed scopes for static OAuth clients directly in the Admin console. For dynamically registered clients, Glean applies a configurable restricted scope set. Contact your Glean representative if you need to change that set for your tenant.
See Static OAuth clientsfor more information on how to create and manage static OAuth clients.
Typical patterns:
General-purpose Server
A server (for example, /mcp/default) with read-heavy tools like search and document retrieval.
Persona-specific Servers
Servers (for example, /mcp/eng, /mcp/sales) with tools tailored to a team's workflows.
Each server is configured with only the tools and scopes it needs, supporting a least-privilege posture for each integration.
6. Compliance, privacy, and data protection
Remote MCP servers inherit Glean's platform-level guarantees:
- Coverage under Glean's Data Processing Addendum (DPA) and standard contractual controls
- Built on top of the same infrastructure that underpins Glean's SOC-aligned security program and regional data residency posture
- Subject to the same user session management capabilities (for example, admins can sign users out of all sessions, including MCP-originated sessions, via the Glean Admin UI)
- Enterprise features such as regional data residency, multi-region HA, and OAuth / IdP integration apply uniformly to MCP endpoints
7. Client Identity Binding
To restrict which client applications can access Glean's MCP servers, Glean provides three mechanisms: redirect URI restrictions on Dynamic Client Registration (DCR), static OAuth clients, and Enterprise Managed Auth, which moves the decision about who can connect into your IdP.
7.1 Static clients vs. dynamic clients
| Static client | Dynamic client (DCR) | |
|---|---|---|
| Created by | Admin in the Admin console | Host application, at runtime via the /oauth/register endpoint |
| Client credentials | Admin controls client_id and secret, and distributes only to approved integrations | Host self-registers and receives credentials automatically |
| Best for | Binding access to a single known deployment (for example, ChatGPT Enterprise managed by your org) | Broad compatibility with many MCP hosts |
| Revocation | Admin deletes or disables the client | Admin revokes the client and optionally prevents future registrations by removing its redirect URI pattern from the allowlist |
7.2 Restricting or Disabling dynamic client registration
To restrict which applications can register dynamically, see Dynamic Client Registration for more information. If your organization requires admin-created static OAuth clients only, select Do not allow dynamic client registrations.
7.3 Confidential vs. public clients
Confidential web clients such as ChatGPT and Claude.ai run server-side and can securely store a client secret. Client identity for these applications can be cryptographically verified.
Public locally installed applications such as VS Code, Cursor, and Claude Code cannot securely store a client secret because the secret would reside on the user's local machine.
This distinction is inherent to OAuth for native and desktop applications (RFC 8252), not a Glean-specific limitation.
7.4 Restricting access to enterprise-managed deployments
For hosted enterprise applications such as ChatGPT Enterprise or Claude Enterprise, you can restrict access so users connect only through your managed deployment rather than through their personal ChatGPT or Claude accounts.
First, select Do not allow dynamic client registrations. This refuses browser sign-in for every self-registered client, both new Dynamic Client Registration (DCR) requests and Client ID Metadata Document (CIMD) client IDs. Then give your managed deployment its own way in:
- Claude (Team and Enterprise): turn on Enterprise Managed Auth. EMA uses only the token endpoint, which the DCR setting doesn't affect, and needs no static client because Claude supports CIMD.
- Applications without CIMD, such as ChatGPT Enterprise: create a static OAuth client and give its client ID and secret only to your managed deployment.
Clients that users already registered through DCR keep working until you revoke them. Revoke them from Admin console → Third-party access (OAuth) when you restrict access.
When a client registers through DCR or CIMD, the MCP host does not distinguish between enterprise-managed sessions and personal sessions. The same client ID serves both. Restricting access to the managed deployment therefore needs something only the deployment holds: an IdP assertion (EMA) or a static client secret.
7.5 Hosted services vs. local applications
If you want to limit MCP access to approved applications, the configuration depends on whether the application is a hosted service or a local application.
- Hosted services: If the service supports admin-configured client IDs and secrets, create a static OAuth client and distribute those credentials only to your approved deployment. This method keeps users on enterprise-managed hosted services rather than personal accounts. See Static OAuth clients.
- Single gateway approval: If you want to allow exactly one hosted gateway or hosted service to register dynamically, configure redirect URI restrictions with a custom allowlist that includes only that gateway's redirect URIs. See Approve only one gateway for more information.
- Local applications: Public clients such as desktop IDEs cannot securely keep a client secret. For these applications, use your existing endpoint management, device trust, and software distribution controls to ensure only approved software runs on user machines.
7.6 Enterprise Managed Auth and access control
Enterprise Managed Auth (EMA) lets you manage MCP access from your IdP rather than from each user's AI application:
- One application, configured once. An owner of your AI application (for example, Claude Enterprise) connects Glean for the whole organization. Users don't add Glean or sign in to it.
- Who can connect is an IdP assignment. Assign users or groups to the connection in your IdP. Remove them to cut off access.
- Personal accounts are excluded by design. A personal Claude or ChatGPT account has no SSO session with your organization, so your IdP never issues it an assertion for Glean.
- Shut it off in the IdP. Remove users or groups from the assignment, or disconnect the application. EMA issues no refresh tokens, so access ends when the current access token expires.
EMA is in beta and currently supports Claude (Team and Enterprise) with Okta.
EMA adds a managed path into Glean MCP. It doesn't by itself close the standard browser sign-in path for other clients. To limit Glean MCP to your managed Claude deployment, turn on EMA, then select Do not allow dynamic client registrations. With both set, a personal Claude account that adds Glean is refused at sign-in, and the managed deployment keeps working through EMA with no static client. See 7.4 Restricting access to enterprise-managed deployments.
8. Loopback redirect URI security model
This section covers loopback redirect URIs used in OAuth flows by locally installed applications (VS Code, Cursor, Claude Code).
The loopback redirect URI security model is distinct from local MCP servers (stdio transport).
8.1 How loopback redirects work
When a locally installed MCP host initiates an OAuth authorization flow, it starts a temporary HTTP listener on a loopback interface. After the user signs in and grants consent, the authorization server redirects the browser to that loopback URI to deliver the authorization code. This is standard OAuth behavior for native applications per RFC 8252.
8.2 Threat model
Redirect URI restrictions mitigate the following threats:
| Threat | Mitigated by redirect URI restrictions? | Explanation |
|---|---|---|
Remote phishing (for example, evil.com attempts to intercept the OAuth flow) | Yes | Redirect URI restrictions prevent authorization codes from being sent to redirect URIs not in the allowed list. |
| Malicious software on the user's machine | No | Any process on the same machine can bind to loopback ports. A compromised device can intercept the authorization code regardless of redirect URI restrictions. |
Redirect URI restrictions that include loopback URIs are a governance control that prevents casual misuse and blocks unauthorized remote clients. They are not a defense against a fully compromised endpoint. For compromised-device scenarios, rely on endpoint security (EDR), device trust policies in your IdP, and Conditional Access.
9. MCP Disablement and token lifecycle
You can restrict or disable MCP access through several paths. All configuration changes propagate within approximately 5–10 minutes.
9.1 Token behavior by authentication model
For Glean-issued tokens, when a user signs out, Glean invalidates that user's tokens until they sign back in. Admins can do the same from the Glean Admin console by signing users out of all sessions for a user. Revocation caches refresh every 10 minutes by default.
10. Monitoring and Audit
10.1 Admin audit logs
Administrative configuration changes to MCP servers and OAuth settings (enabling/disabling servers, modifying redirect URI restrictions, creating or revoking clients) are captured in Glean's admin audit logs. See Admin Audit Logs for details on searching, filtering, and exporting these logs.
10.2 MCP activity logs
MCP activity logs capture tool usage events for each MCP server. These logs can be filtered by MCP server, tool, user, and date range. OAuth client metadata (such as client name and registration type) is included in activity log entries, providing visibility into which applications are accessing MCP and how they are being used.
For confidential applications that use static client IDs and secrets, host attribution is reliable. For other client types, host attribution is best effort and depends on the metadata the client provides.
10.3 Insights dashboard
Glean collects analytical data regarding the usage and performance of Agents within Glean and displays it in the insights dashboard. This data includes metrics related to user engagement, agent effectiveness, and overall quality of interaction. See Overview for more information.
MCP connection and usage insights are available in the MCP insights dashboard, which reports MCP calls and active users with breakdowns by host application, tool, and server. For other tracking methods such as audit logs and activity logs, see MCP usage tracking and analytics.
11. FAQ for Security / Architecture Reviews
See also
For additional detail, see:
- About Glean MCP server: Product overview, supported hosts, authentication, and high-level security notes
- Data Flow: Full platform data flow, ingestion, and processing model
- Glean OAuth Authorization Server: Detailed review of Glean OAuth Authorization Server
- Enterprise Managed Auth: Manage MCP access through your IdP
- Admin Audit Logs: Administrative change logging
Appendix: Local MCP Servers
Development-only; not recommended for production use
This section is provided for completeness. Glean's remote MCP server is the recommended and supported deployment model for all production use cases.
What is local MCP?
Some MCP implementations use the stdio transport, which runs an MCP server locally on a user's machine. This is typically done by dynamically invoking a package using npx, which downloads, installs, and executes the MCP Node package's degit fault binary.
Security concerns with local MCP
Local MCP servers introduce security risks that do not apply to Glean's remote MCP:
| Risk | Description |
|---|---|
| Supply chain vulnerabilities | npm packages are subject to attacks such as package jacking, where a threat actor takes control of a legitimate package to distribute malicious code. |
| Full local privileges | The MCP server inherits the full privileges of the local OS, including file system access, network access, and stored credentials. |
| No centralized controls | Local servers operate outside of Glean's authentication, authorization, monitoring, and compliance controls. |
Glean's guidance
- Always prefer remote MCP for production workloads and when connecting SaaS hosts like ChatGPT or Claude
- Treat local MCP as development-only, and only when there is no remote MCP server available and additional local security controls are in place
- Note: Some SaaS hosts (for example, ChatGPT) cannot reliably use local MCP at all