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 (e.g., ChatGPT, Claude, Copilot Studio, IDEs) connect to Glean.

It is intended for security, architecture, and compliance reviewers evaluating Glean's remote MCP deployment.

---

1. What the Glean MCP Server Is

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 (e.g., search, chat, read_document, and selected agents).

Instead of building and operating their own MCP servers, customers point MCP-compatible hosts at Glean-managed endpoints such as:

https://{customer-instance}-be.glean.com/mcp/{server_name}

Each endpoint runs inside the customer's Glean tenant, enforcing the same security, privacy, and permission model as the rest of the Glean platform.

---

2. Deployment and Hosting Model

2.1 Customer-isolated tenants

Glean is deployed as a dedicated tenant per customer, in its own cloud project/VPC. All standard ingestion, indexing, and query processing takes place inside that tenant.

The remote MCP server:

• Is deployed within the customer's existing Glean tenant (customer VPC / project)
• Reuses the same infrastructure and security boundaries (networking, encryption, IAM, auditing) as Glean search and assistant
• Presents one or more per-server URLs (e.g., …/mcp/default, …/mcp/chatgpt, …/mcp/eng) that admins can create and configure via the Glean Admin Console

2.2 Remote MCP: The production deployment model

Glean's remote MCP server is the recommended and 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 local MCP servers (development-only, not recommended for production), see Appendix: Local MCP Servers at the end of this document.

---

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. More details here.

MCP hosts initiate a standard OAuth authorization grant flow; users sign in to Glean normally with your existing SSO/IdP. 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:

Every search, chat, and document retrieval call enforces per-document and per-object permissions based on Glean's Knowledge Graph (connector-sourced ACLs, groups, roles, sharing settings).

Tokens are constrained to the minimal set of scopes required (e.g., read-only tools vs. write tools), and the MCP server validates scopes before accessing any data or performing any action.

Tokens are bound to a single customer tenant; routing and backend services reject cross-instance access.

warning

If a user cannot see or access something in Glean, 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

For a remote MCP request (e.g., 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://{customer-instance}-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/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 (snippets, metadata, full documents via read_document), and only in response to explicit tool calls from the MCP host.

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.

Typical patterns:

General-purpose Server

A server (e.g., /mcp/default) with read-heavy tools like search and document retrieval.

Persona-specific Servers

Servers (e.g., /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:

• Covered 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 (e.g., 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. FAQ for Security / Architecture Reviews

The Glean remote MCP server runs inside your Glean tenant (your dedicated cloud project/VPC). All indexing, query processing, and MCP tool execution occur within that environment. Tool responses are returned to the MCP host over TLS — the same data flow as any application consuming Glean's APIs. Once data reaches the host, it is subject to that host's data handling policies.

No. The MCP server is built on top of Glean's existing APIs and Knowledge Graph. All access is user-scoped and permission-aware, enforcing the same ACLs, group memberships, and sharing rules as the Glean UI and APIs.

The host uses either:

• OAuth, often with Dynamic Client Registration (preferred), or
• User-scoped Client API tokens (fallback where OAuth is not yet supported)

Tokens are scoped to MCP-specific APIs and are validated by the Glean MCP gateway before each tool invocation.

No. The MCP server cannot elevate privileges beyond the underlying Glean user identity. Every search, chat, or document access call is permission-checked by Glean's Knowledge Graph, the same as if the user had performed the action directly in Glean.

Glean strongly recommends remote MCP for all production workloads. Local MCP servers carry additional security risks and should only be used for development. See Appendix: Local MCP Servers for details.

---

Additional Resources

For additional detail, see:

• About Glean MCP Servers – 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

---

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 default 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 (e.g., ChatGPT) cannot reliably use local MCP at all