- Executive Summary
As enterprise adoption of the Model Context Protocol (MCP) accelerates, organizations are increasingly deploying Envoy AI Gateway as a centralized Layer 7 control plane to govern autonomous AI agents.
Currently, Envoy AI Gateway excels at routing and securing internal LLM traffic. However, a critical gap exists when integrating with third-party SaaS MCP servers (e.g., GitHub Copilot MCP). Enterprises require the ability to securely exchange internal Identity Provider (IdP) tokens for highly-scoped, SaaS-specific downstream tokens at the network edge, ensuring per-user attribution without violating MCP security best practices.
This proposal advocates for the Envoy AI Gateway project to either formally document a WebAssembly (Wasm) pattern using EnvoyExtensionPolicy or natively support an OAuth 2.0 Token Exchange (RFC 8693) mechanism within the MCPRoute API.
- The Use Case: Enterprise SSO to SaaS MCP Servers
Our enterprise architecture routes AI agents (such as VS Code extensions) through Envoy AI Gateway (v0.5.0) to interact with the remote GitHub MCP server (https://api.githubcopilot.com/mcp/).
Ingress Authentication: Agents authenticate at the gateway using our internal corporate IdP (e.g., Okta/Entra ID) via standard OAuth 2.0/OIDC flows.
Egress Authorization: Third-party SaaS backends like GitHub do not trust our internal IdP tokens. They require a valid, GitHub-issued OAuth token in the Authorization: Bearer header to execute downstream Graph API calls and attribute actions to the specific invoking user.
- Current Limitations in Envoy AI Gateway 0.5.0
The current API surface of Envoy AI Gateway presents several friction points for this enterprise deployment pattern:
The Token Passthrough Anti-Pattern: The official MCP Security Best Practices explicitly classify raw token passthrough as an anti-pattern to prevent privilege escalation. Envoy AI Gateway correctly strips the original Authorization header by default.
claimToHeaders Falls Short: While the claimToHeaders feature inside MCPRouteSecurityPolicy (see API Docs and Issue #1815) allows extracting specific JWT claims into flat HTTP headers, it does not solve the need for a completely new OAuth token formatted as a Bearer token for the remote SaaS platform.
Static API Key Vulnerabilities: The MCPBackendSecurityPolicy currently relies on static API keys stored in Kubernetes Secrets. This forces a generic service account token for SaaS access—destroying per-user auditability—or requires writing complex external controllers to constantly refresh short-lived GitHub App installation tokens.
- Why Existing Envoy Workarounds Fall Short
Attempting to solve this using standard Envoy proxy features like external authorization (ext_authz) introduces unacceptable operational complexity and risk:
Filter Chain Friction: Injecting an ext_authz filter deep into the upstream cluster filter chain (after the route is selected and ingress headers are stripped) to swap a token is notoriously difficult.
Route Cache Clearing & Streaming Issues: Dynamically modifying headers late in the request lifecycle risks clearing the route cache. This can inadvertently bypass secondary authorization checks or cause streamable HTTP connections (critical for LLM/MCP workloads) to buffer and hang.
Note: For further context on the complexity of enterprise SSO with SaaS MCPs, see Solo.io's breakdown on Enterprise SSO and SaaS MCP Servers.
- The Proposed Architecture
We propose leveraging the Gateway API's EnvoyExtensionPolicy combined with a WebAssembly (Wasm) dynamic module to execute an RFC 8693 Token Exchange securely at the network edge.
The Flow:
Intercept: A Wasm module (running in isolated V8 environments) intercepts the request after successful ingress OIDC authentication.
Exchange: The module takes the validated internal IdP token and executes an RFC 8693 token exchange flow against the SaaS authorization server (e.g., GitHub's auth endpoint).
Inject: The module securely injects the newly minted, highly-scoped SaaS token into the Authorization header just before the payload exits the cluster.
Advantages:
Stateless Edge: The proxy remains stateless; token mapping happens dynamically per request.
Auditability: Perfectly maps internal identities to SaaS identities, maintaining strict per-user audit logs at the SaaS layer.
Ecosystem Leverage: Integrates seamlessly with existing Tetrate Built on Envoy Extensions (e.g., the token-exchange Wasm module from builtonenvoy.io).
- Call to Action for Maintainers
To support secure, enterprise-grade adoption of remote SaaS MCP backends, we kindly request the maintainers consider the following:
Documentation & Validation: Formally document and validate the Wasm + EnvoyExtensionPolicy pattern in the Envoy AI Gateway MCP Docs as the recommended approach for OAuth Token Exchange.
Future Native Support: Consider expanding the MCPBackendSecurityPolicy API to natively support an OauthTokenExchange definition, abstracting the Wasm complexity from end-users entirely.
Thank you for your time and for the continued excellent work on Envoy AI Gateway. We look forward to your thoughts on this architectural pattern.
Reference Links
Envoy AI Gateway MCP Docs: https://aigateway.envoyproxy.io/docs/0.5/capabilities/mcp/
Envoy AI Gateway API (claimToHeaders limits): https://aigateway.envoyproxy.io/docs/api/
GitHub Issue #1815 (Support JWT claim forwarding): #1815
Envoy Gateway Wasm Extension Docs: https://gateway.envoyproxy.io/v1.3/api/extension_types/
Built on Envoy Extensions: https://builtonenvoy.io/ & Tetrate Press Release
Enterprise MCP SSO Pattern (Solo.io): https://www.solo.io/blog/enterprise-sso-and-saas-mcp-servers---how-to-authorize-with-agent-gateway-enterprise/
Model Context Protocol Security Best Practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
RFC 8693 (OAuth 2.0 Token Exchange): https://datatracker.ietf.org/doc/rfc8693/
As enterprise adoption of the Model Context Protocol (MCP) accelerates, organizations are increasingly deploying Envoy AI Gateway as a centralized Layer 7 control plane to govern autonomous AI agents.
Currently, Envoy AI Gateway excels at routing and securing internal LLM traffic. However, a critical gap exists when integrating with third-party SaaS MCP servers (e.g., GitHub Copilot MCP). Enterprises require the ability to securely exchange internal Identity Provider (IdP) tokens for highly-scoped, SaaS-specific downstream tokens at the network edge, ensuring per-user attribution without violating MCP security best practices.
This proposal advocates for the Envoy AI Gateway project to either formally document a WebAssembly (Wasm) pattern using EnvoyExtensionPolicy or natively support an OAuth 2.0 Token Exchange (RFC 8693) mechanism within the MCPRoute API.
Our enterprise architecture routes AI agents (such as VS Code extensions) through Envoy AI Gateway (v0.5.0) to interact with the remote GitHub MCP server (https://api.githubcopilot.com/mcp/).
Ingress Authentication: Agents authenticate at the gateway using our internal corporate IdP (e.g., Okta/Entra ID) via standard OAuth 2.0/OIDC flows.
Egress Authorization: Third-party SaaS backends like GitHub do not trust our internal IdP tokens. They require a valid, GitHub-issued OAuth token in the Authorization: Bearer header to execute downstream Graph API calls and attribute actions to the specific invoking user.
The current API surface of Envoy AI Gateway presents several friction points for this enterprise deployment pattern:
The Token Passthrough Anti-Pattern: The official MCP Security Best Practices explicitly classify raw token passthrough as an anti-pattern to prevent privilege escalation. Envoy AI Gateway correctly strips the original Authorization header by default.
claimToHeaders Falls Short: While the claimToHeaders feature inside MCPRouteSecurityPolicy (see API Docs and Issue #1815) allows extracting specific JWT claims into flat HTTP headers, it does not solve the need for a completely new OAuth token formatted as a Bearer token for the remote SaaS platform.
Static API Key Vulnerabilities: The MCPBackendSecurityPolicy currently relies on static API keys stored in Kubernetes Secrets. This forces a generic service account token for SaaS access—destroying per-user auditability—or requires writing complex external controllers to constantly refresh short-lived GitHub App installation tokens.
Attempting to solve this using standard Envoy proxy features like external authorization (ext_authz) introduces unacceptable operational complexity and risk:
Filter Chain Friction: Injecting an ext_authz filter deep into the upstream cluster filter chain (after the route is selected and ingress headers are stripped) to swap a token is notoriously difficult.
Route Cache Clearing & Streaming Issues: Dynamically modifying headers late in the request lifecycle risks clearing the route cache. This can inadvertently bypass secondary authorization checks or cause streamable HTTP connections (critical for LLM/MCP workloads) to buffer and hang.
Note: For further context on the complexity of enterprise SSO with SaaS MCPs, see Solo.io's breakdown on Enterprise SSO and SaaS MCP Servers.
We propose leveraging the Gateway API's EnvoyExtensionPolicy combined with a WebAssembly (Wasm) dynamic module to execute an RFC 8693 Token Exchange securely at the network edge.
The Flow:
Intercept: A Wasm module (running in isolated V8 environments) intercepts the request after successful ingress OIDC authentication.
Exchange: The module takes the validated internal IdP token and executes an RFC 8693 token exchange flow against the SaaS authorization server (e.g., GitHub's auth endpoint).
Inject: The module securely injects the newly minted, highly-scoped SaaS token into the Authorization header just before the payload exits the cluster.
Advantages:
Stateless Edge: The proxy remains stateless; token mapping happens dynamically per request.
Auditability: Perfectly maps internal identities to SaaS identities, maintaining strict per-user audit logs at the SaaS layer.
Ecosystem Leverage: Integrates seamlessly with existing Tetrate Built on Envoy Extensions (e.g., the token-exchange Wasm module from builtonenvoy.io).
To support secure, enterprise-grade adoption of remote SaaS MCP backends, we kindly request the maintainers consider the following:
Documentation & Validation: Formally document and validate the Wasm + EnvoyExtensionPolicy pattern in the Envoy AI Gateway MCP Docs as the recommended approach for OAuth Token Exchange.
Future Native Support: Consider expanding the MCPBackendSecurityPolicy API to natively support an OauthTokenExchange definition, abstracting the Wasm complexity from end-users entirely.
Thank you for your time and for the continued excellent work on Envoy AI Gateway. We look forward to your thoughts on this architectural pattern.
Envoy AI Gateway MCP Docs: https://aigateway.envoyproxy.io/docs/0.5/capabilities/mcp/
Envoy AI Gateway API (claimToHeaders limits): https://aigateway.envoyproxy.io/docs/api/
GitHub Issue #1815 (Support JWT claim forwarding): #1815
Envoy Gateway Wasm Extension Docs: https://gateway.envoyproxy.io/v1.3/api/extension_types/
Built on Envoy Extensions: https://builtonenvoy.io/ & Tetrate Press Release
Enterprise MCP SSO Pattern (Solo.io): https://www.solo.io/blog/enterprise-sso-and-saas-mcp-servers---how-to-authorize-with-agent-gateway-enterprise/
Model Context Protocol Security Best Practices: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
RFC 8693 (OAuth 2.0 Token Exchange): https://datatracker.ietf.org/doc/rfc8693/