Gateway allows further fine-grained authorization and authentication regarding which agents /developers can call which MCP servers. It provides a three layer authentication and authorization system:
  1. Authentication access to Gateway using Truefoundry Token or your IDP token: Any user/application requires a token to talk to the gateway - so that the gateway can identify the user and subsequently impose authorization rules on the user. This can either be a Truefoundry API key or your own IdP token. Truefoundry AI Gateway can verify your own IdP token and extract the user’s email from the token based on the SSO settings.
  2. Access Control at Gateway layer: You can define at the gateway layer which users have access to which MCP servers and tools. This allows fine grained access control at an enterprise level. This is done via the MCP Server Group wherein you can define the users/teams that have access to the MCP server group.
MCP Server Group Access Control
Coming Soon: We are introducing a Virtual MCP Server wherein you can define the subset of tools from different MCP servers and give access to the users/teams to this virtual MCP server. This will help provide fine-grained access to tools within MCP servers.
  1. External service authorization (MCP Server auth): This is the authorization implemented by the MCP Server for accessing the external service. Truefoundry allows MCP servers to be integrated with the following auth mechanisms:
A key thing to note here is that the AI gateway stores and manages tokens for different MCP servers for a user. It keeps the map of the user token to Oauth tokens for different MCP servers and refreshes them when they are expired. This allows user to talk to the Gateway with a single token without having to manage multiple tokens.
The flow of authn/authz through the AI Gateway is as follows:
MCP Gateway Authentication and Authorization Flow

MCP Gateway Authentication and Authorization Flow

Key Usecases

1. Truefoundry Users accessing Oauth Based MCP servers

In this case, the users/developers have an account on Truefoundry. This allows them to use the Truefoundry token to access the MCP servers. Sequence Diagram for Truefoundry User accessing Oauth Based MCP Servers

2. End customers accessing Oauth Based MCP Servers

This can be useful if you want to enable your end customers to access the MCP servers (in case of CIAM). The end customers will not have an account on Truefoundry, but they will have an account on your IdP or any other authentication provider. So you can use the IdP token to access the MCP servers. Sequence Diagram for End customers accessing Oauth Based MCP Servers
You can use this method for your internal developers also in case you don’t want to rely on Truefoundry tokens.

3. Developers / End Customers accessing Bearer Token Based MCP servers

Sequence Diagram for Developers / End Customers accessing Bearer Token Based MCP servers