Skip to main content

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.

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://tenant_id-be.glean.com/mcp/{server_name}

Copy your full backend URL from app.glean.com/admin/about-glean under Server instance (QE), and replace https://tenant_id-be.glean.com with it.

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

Glean recommends the Glean remote MCP server as the supported deployment model for all production use cases, accessed over HTTPS from MCP hosts (ChatGPT, Claude, VS Code, etc.) and officially supported by Glean for major MCP hosts.

info

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 VPC firewall.
  • Some endpoints, such as webhook delivery and OAuth metadata discovery, may be exempt from those tenant-wide VPC firewall rules. MCP endpoints enforce IP greenlisting at the application layer.
  • Glean also applies additional application-level IP greenlisting for relevant API traffic, including MCP access.

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:

  1. Authenticates the end user or client via Glean OAuth or API tokens
  2. Maps that identity to a Glean user in the customer's tenant
  3. 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:

1

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 scoped to Glean APIs (SEARCH, CHAT, DOCUMENTS, TOOLS, etc.).

2

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.

3

User-scoped Glean API Tokens (Fallback)

Client API tokens tied to a specific user and tenant, with explicit scopes: MCP, AGENT, SEARCH, CHAT, DOCUMENTS, TOOLS, ENTITIES.

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:

warning

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:

1

MCP Host → Glean MCP Endpoint

The host's MCP client opens a streaming HTTP/SSE connection to https://tenant_id-be.glean.com/mcp/{server} using TLS 1.2+.

The request includes an OAuth token or API token bound to a user in the customer tenant.

2

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 (search, chat, read_document, etc.) exactly as if the user had called Glean directly via API or UI.

3

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:

ToolPermission Behavior
searchReturns only items the user can already access in Glean
read_documentCan only fetch documents the user may open directly
People, org, and code toolsRespect 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 clients more information 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 two mechanisms: redirect URI restrictions on Dynamic Client Registration (DCR) and static OAuth clients.

7.1 Static clients vs. dynamic clients​

Static clientDynamic client (DCR)
Created byAdmin in the Admin ConsoleHost application, at runtime via the /oauth/register endpoint
Client credentialsAdmin controls client_id and secret, and distributes only to approved integrationsHost self-registers and receives credentials automatically
Best forBinding access to a single known deployment (for example, ChatGPT Enterprise managed by your org)Broad compatibility with many MCP hosts
RevocationAdmin deletes or disables the clientAdmin 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​

info

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.

To restrict access to enterprise-managed sessions, see Do not allow dynamic client registrations to learn how to disable dynamic client registration. Instead, see Static OAuth clients to configure a static OAuth Client ID and secret.

info

When these clients use Dynamic Client Registration, the MCP host does not distinguish between enterprise-managed sessions and personal sessions. This is why restricting access to managed deployments requires statically configured OAuth clients.

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.

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).

note

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:

ThreatMitigated by redirect URI restrictions?Explanation
Remote phishing (for example, evil.com attempts to intercept the OAuth flow)YesRedirect URI restrictions prevent authorization codes from being sent to redirect URIs not in the allowed list.
Malicious software on the user's machineNoAny process on the same machine can bind to loopback ports. A compromised device can intercept the authorization code regardless of redirect URI restrictions.
info

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 tab on Insights for more information.

note

MCP connection and usage insights are not yet available in the admin Insights dashboard. Contact your Glean account team for the latest availability.

11. FAQ for Security / Architecture Reviews​

See also​

For additional detail, see:

Appendix: Local MCP Servers​

warning

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:

RiskDescription
Supply chain vulnerabilitiesnpm 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 privilegesThe MCP server inherits the full privileges of the local OS, including file system access, network access, and stored credentials.
No centralized controlsLocal 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 (e.g., ChatGPT) cannot reliably use local MCP at all
© 2026, Glean Technologies, Inc.
Last updated on