Admin-managed credential delegation for third-party MCP servers connected to Glean Agents

arf

Posting a Feature Request on behalf of a customer, which resulted from a ticket:

Quote below:

When an admin connects a third-party MCP server (e.g., Wiz) to a Glean Agent via Actions, end users should not be required to individually authenticate against that MCP server. The admin who configures the Agent should be able to provide a centrally managed credential that the Agent uses on behalf of all users.

Currently, all authentication methods available for third-party MCP servers (OAuth, DCR) require each end user to individually "Connect" to the MCP server before they can use an Agent that depends on it. This means if I build a Wiz-powered security posture Agent and publish it to 38 employees, all 38 must individually complete OAuth against Wiz before the Agent is functional for them.

This is a fundamental design issue. The value proposition of a Glean Agent is abstraction. Admins compose tools and data sources into an Agent, and end users interact with the Agent without needing to understand or access the underlying systems. Requiring end users to authenticate against every MCP backend breaks this abstraction entirely.

Consider the Wiz use case. Wiz is a cloud security platform where access is restricted to SOC/security teams and admins. End users such as developers or PMs do not have Wiz accounts, nor should they. The Agent should query Wiz with admin-scoped credentials and return curated, permission-appropriate results to the user. Asking 38 employees to OAuth into Wiz defeats the purpose of having an Agent in the first place.

This is not unique to Wiz. Any security, infrastructure, or ops tool (CrowdStrike, Netskope, Zscaler, etc.) follows the same pattern. A small team of admins has access, and the rest of the org should consume insights through an abstraction layer, which is exactly what Agents are supposed to be.

There is a related issue I also want to raise. Glean currently does not provide a functional way to connect MCP servers that require no authentication. The "None" option exists in the UI, but in practice, connecting an unauthenticated MCP server does not work properly. As a workaround, we had to deploy a custom OAuth2 proxy on AWS in front of the Microsoft MCP server just to satisfy Glean's requirement for an authentication layer. This is an unnecessary overhead. We are building and maintaining infrastructure on AWS solely to work around a limitation on the Glean side. If an MCP server does not require authentication, Glean should be able to connect to it directly without forcing us to wrap it in an OAuth2 layer.

What I'm proposing covers both issues:

1. Add a "Central" authentication option for third-party MCP servers, similar to what Jira Actions already supports. The admin provides credentials (API key, OAuth client credentials, or service account token) at the action pack level. The Agent executes MCP tool calls using these admin-managed credentials. End users interact with the Agent without any individual authentication requirement against the MCP server.

2. Fix the unauthenticated MCP server connection so that it actually works. If an MCP server exposes its endpoint without auth, Glean should connect to it as-is without requiring a proxy.

For OAuth-based MCP servers, the central credential model could be implemented as a service account OAuth flow (client_credentials grant) where the admin completes the auth once and the token is managed centrally by Glean.

Without these changes, third-party MCP servers in Agents are effectively limited to tools where every employee already has an individual account, like Jira or Confluence. This excludes the entire category of security, infrastructure, and ops tools, which is arguably where Agent-based abstraction adds the most value. On top of that, customers are forced to build unnecessary proxy infrastructure just to connect MCP servers that should work out of the box.