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

This research presents a solution to the governance crisis caused by the rapid adoption of Model Context Protocol (MCP) in large organizations. The proposed solution is a centralized MCP gateway that unifies heterogeneous authentication methods, resolving issues related to authorization, tracking, and offboarding across the fleet of MCP servers.

What the Document Says

  • The Model Context Protocol (MCP) has become the standard for connecting LLM agents to enterprise tools. Within a year, large organizations went from zero to dozens of internally built MCP servers, leading to a governance crisis due to independent authentication implementations.
  • A centralized MCP gateway is proposed as a solution. This gateway aggregates, governs, and authenticates all downstream MCP servers.
  • The research makes four contributions: 1) A two-axis authentication model for persona (interactive user vs automated non-user) and credential type (no-auth, API keys, PKCE, client credentials, platform app-context). 2) Support for three enterprise SSO grants and three token-provisioning models. 3) Three end-to-end identity flows: User-to-OAuth2, Non-user-to-Service-Account, and User-to-Service-Account. 4) The architecture evolution from CDN/WAF/edge perimeter to private MCP tunnels and enterprise-wide connectors.
  • The architecture is in production, serving dozens of MCP servers across various clients.

Key Concepts Mentioned

  • Model Context Protocol (MCP)
  • LLM agents
  • enterprise tools
  • governance crisis
  • authentication
  • SSO grants
  • token-provisioning models
  • persona
  • credential type
  • endpoint identity flows
  • CDN
  • WAF
  • private MCP tunnels

Claims Made by the Document

  • The adoption of MCP in large organizations led to a governance crisis due to independent authentication implementations.

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.