Adnan KhanAdnanProduct & AI
San Francisco Bay Area
Get in touch

Source note2 min read

A Gateway Architecture for Enterprise MCP Authentication: Unifying Heterogeneous Auth, Identity Delegation, and the User / Non-User Persona Problem

Source

arXiv

arxiv.org/abs/2608.10760v1

Read the source

Source

  • Source name: arXiv
  • Source kind: paper
  • Authors / organization: Suraj Kumar, Amy Wang, Srinivasan Manoharan
  • Venue: arXiv: cs.CR
  • Published: 2026-08-11
  • Collected: 2026-08-12
  • URL: http://arxiv.org/abs/2608.10760v1
  • PDF: https://arxiv.org/pdf/2608.10760v1
  • DOI: UNKNOWN
  • Registry group: academic_apis_and_preprints
  • Evidence role: canonical_academic_index
  • Language: en
  • Country / region: UNKNOWN

Plain-Language Brief

The paper discusses a solution to a governance crisis caused by the rapid adoption of Model Context Protocol (MCP) for connecting LLM agents with enterprise tools. The solution is a centralized MCP gateway that provides a unified authentication layer for various authentication methods and person types (user or non-user).

What the Document Says

  • The paper discusses an industry deployment of a centralized Model Context Protocol (MCP) gateway.
  • The MCP gateway serves as a single aggregation, governance, and authentication layer for all downstream MCP servers.
  • The authors propose a two-axis authentication model that combines persona (user or non-user) with credential type (no-auth, API key, PKCE, client credentials, platform app-context).
  • The gateway supports three enterprise Single Sign-On (SSO) grants and three token-provisioning models: BYOT, GYOT, and delegated OAuth via RFC 8693 token exchange.
  • Three end-to-end identity flows are described: User-to-OAuth2, Non-user-to-Service-Account, and User-to-Service-Account.
  • The architecture is in production and serves dozens of MCP servers across various clients.

Key Concepts Mentioned

  • Model Context Protocol (MCP)
  • centralized gateway
  • authentication
  • persona
  • credential type
  • SSO grants
  • token-provisioning models

Claims Made by the Document

  • The MCP has become the de-facto interface for connecting LLM agents to enterprise tools and its adoption has been rapid.
  • The fragmented authentication landscape caused a governance crisis due to independent implementation by each team.

Evidence Used

  • Within a year, large organizations went from zero to dozens of internally built MCP servers.

Methods / Approach

UNKNOWN

Limitations Stated by the Authors

UNKNOWN

Limitations Noted by the Agent

Agent interpretation — not from the source.

UNKNOWN

Open Questions

UNKNOWN

Notes for Future Q&A

May include interpretation. Labeled where it does.

UNKNOWN

Raw Abstract / Excerpt

The Model Context Protocol (MCP) has become the de-facto interface for connecting LLM agents to enterprise tools, and adoption has been explosive: within a year, large organizations went from zero to dozens of internally built MCP servers. That speed created a governance crisis. Each team implemented authentication independently -- some with no auth, some with API keys, some with full OAuth -- producing a fragmented landscape with no consistent way to authorize callers, track who did what, or offboard a departing employee across the fleet. This paper reports an industry deployment that resolves the crisis with a centralized MCP gateway: a single aggregation, governance, and authentication layer that fronts every downstream MCP server. We make four contributions grounded in production experience. First, a two-axis authentication model crossing persona (interactive user vs. automated non-user) with credential type (no-auth, static/dynamic API key, PKCE, client credentials, platform app-context). Second, a gateway authentication layer supporting three enterprise SSO grants and three token-provisioning models: Bring-Your-Own-Token, Generate-Your-Own-Token, and delegated OAuth via RFC 8693 token exchange. Third, three end-to-end identity flows -- User-to-OAuth2, Non-user-to-Service-Account, and User-to-Service-Account -- composing client, gateway, and server. Fourth, the deployment evolution from CDN/WAF/edge perimeter to private MCP tunnels and enterprise-wide connectors. The architecture is in production, fronting dozens of MCP servers across web, desktop, custom-SDK, and low-code clients.