Enterprise MCP Gateway – Secretless Agent Identity, Token Exchange and Downstream Authorization

[RelliFirst]

Hi,

We're evaluating LiteLLM as a central enterprise MCP gateway and comparing it with AWS AgentCore Gateway.

Our agents run in AWS, across multiple accounts, and need access to tools such as ServiceNow, Elastic, and Azure DevOps.

The goal is to centralize authentication and authorization without giving agents direct credentials or permissions to downstream tools.

The flow we're aiming for:

1. An AWS-hosted agent authenticates to the gateway using its workload identity, without stored secrets.
2. The gateway identifies the specific agent and enforces which tools it can access.
3. When calling a tool, the gateway obtains a downstream access token representing that agent, ideally using Microsoft Entra Agent Identity.
4. For user-delegated scenarios, the gateway should also support OBO, preserving both the user and agent context.
5. Agents should only be authorized to access the gateway, not downstream services directly.

We're looking for a solution that can scale to many agents, with centralized policies, auditing, and minimal custom authentication code.

A few questions:

• Does LiteLLM's current MCP OAuth/token exchange support this architecture, particularly for headless AWS agents?
• Can LiteLLM obtain downstream tokens for distinct Entra Agent Identities without storing per-agent client secrets?
• How is agent identity preserved and enforced across the gateway and downstream services, including OBO scenarios?
• Can the gateway dynamically map an authenticated agent to its downstream identity and permissions?
• Would another identity approach or provider be better suited for this architecture than Entra Agent Identity?
• Which parts are supported natively today, and which require a custom identity broker or additional integration?

I'd also be interested in hearing from anyone running a similar architecture in production, particularly if you've evaluated LiteLLM against AgentCore Gateway.

Thanks!

[koentv]

I can't speak to AgentCore or to running this in production, but I went through LiteLLM main (527d882) to see which of your pieces exist natively today. Short version: agent → gateway identity, per-agent tool policy, and user OBO are there. Minting downstream tokens as a distinct Entra Agent Identity is not, as far as I can find.

1. Agent → gateway (Q1, first half of Q2)

Callers can authenticate with OIDC JWTs (enable_jwt_auth, which needs an Enterprise license per the JWT auth docs). litellm_jwtauth.agent_id_jwt_field (e.g. azp) maps a claim to a registered agent, and a token whose claim matches no registered agent gets a 403 (litellm/proxy/auth/handle_jwt.py, resolve_agent_id). There's also a beta Entra binding on /v1/agents (tenant_id, client_id, service_principal_id, execution_mode: autonomous | delegated, see litellm/types/proxy/agent_identity.py).

So the agent never holds a LiteLLM key, but it still needs a JWT from an issuer LiteLLM trusts. For headless AWS agents that probably means an Entra token obtained through workload identity federation, or an AWS STS GetWebIdentityToken JWT. I haven't tested LiteLLM against the STS issuer, so check that one before you rely on it.

2. Which tools an agent may use (Q2, Q4)

An agent carries its own object_permission (MCP servers, access groups, toolsets), and that's intersected with the key/team/org/user levels (MCP permission docs). In delegated mode the agent's servers are also intersected with what the human user is allowed (litellm/proxy/mcp_server/auth/managed_agent_access.py L36-44). That's the "agent AND user" check you describe.

3. Downstream tokens (Q2, Q3)

• User-delegated: auth_type: oauth2_token_exchange with token_exchange_profile: entra_obo does Entra OBO (jwt-bearer + requested_token_use=on_behalf_of). The caller's token is the assertion, the result is cached per subject token + server, and only the exchanged token is forwarded (OBO docs). The caller's token has to be audienced to LiteLLM's app registration, and the exchange runs as that one app registration with a client secret. The OBO path only takes client_secret; private-key-JWT client auth exists in the code, but only for the ID-JAG flow (outbound_credentials/adapter.py L172 vs L275).
• Autonomous: auth_type: oauth2 + oauth2_flow: client_credentials gives you a gateway-managed M2M token. It's configured per MCP server, though, so every agent calling that server gets the same downstream identity.
• Entra Agent ID's own flow (blueprint credential + fmi_path → agent identity token, Microsoft docs) doesn't show up anywhere in the LiteLLM source I searched. Getting a downstream token that represents agent X, without per-agent secrets, would need your own broker today.

One question that decides which path fits: for ServiceNow/Elastic/ADO, does the downstream token need to be issued to each agent's own Entra identity (so the tool's own audit log shows the agent)? Or is "LiteLLM's app registration acting on behalf of the user, with the agent recorded on the LiteLLM side" acceptable?

[haliloncen]

@koentv's breakdown lines up with the LiteLLM OBO docs. Drawn as a picture, the design hinges on the question koentv ended with:

• Green is native today: agent → gateway auth via an OIDC JWT mapped to a registered agent, per-agent tool policy, and two downstream options: Entra OBO (user-delegated, runs as LiteLLM's own app registration with a client secret) or client_credentials per MCP server (autonomous, but every agent shares that identity).
• Amber is what you'd build: if ServiceNow/Elastic/ADO must see agent X itself in their own audit logs, you need a component that holds the Agent Identity Blueprint credential (federated credential or managed identity, so still no stored secret) and does the fmi_path exchange for that specific Agent Identity. LiteLLM doesn't do that step today. The Agent Identity APIs are also still under Graph /beta, worth weighing for production.

If "LiteLLM's app identity acting for the user, with the agent recorded in LiteLLM's logs" satisfies your auditors, the green path needs config only. If not, the broker is the one custom piece, and it's narrow: everything before it stays native.

One thing to test early either way: whether LiteLLM's JWT auth accepts tokens from the AWS STS issuer. That decides whether your AWS agents need Entra workload identity federation first.

(Disclosure: I build Archboard and drew this with it.)

[RelliFirst]

Thanks for the diagram, LiteLLM's JWT auth accepts tokens from the AWS STS issuer, but what would be the best way to pass together with it the user token for obo?

[redbotster]

for the headless AWS workload identity piece, the standard pattern is IRSA or EKS pod identity to get an OIDC token, then exchange that at your gateway via OAuth token exchange (RFC 8693) for a short-lived scoped token that the gateway uses to fetch downstream credentials on behalf of that specific agent. the key insight is the gateway never hands the raw credential to the agent, it performs the downstream call itself or issues a short-lived proxy token. for Entra OBO, your gateway service principal calls the OBO flow with the agent's inbound token to get a delegated token that carries both user and agent context downstream.

on LiteLLM specifically, the MCP OAuth support is still maturing and i'd test the headless OIDC exchange path carefully before committing. if you want something purpose-built for the "agent never sees the raw secret" constraint, we built 1Claw around exactly this: credentials live in an HSM vault, agents reference a path and get a scoped short-lived token, the raw key never touches model context or logs. disclosure: i work on 1Claw. docs at docs.1claw.co?utm_source=github&utm_medium=comment&utm_campaign=growth if it's worth a look.

[apovalov]

@RelliFirst, I would try sending the two tokens in separate headers on the direct MCP endpoint:

x-litellm-api-key: Bearer <AWS-workload-JWT>
Authorization: Bearer <Entra-user-access-token>

Despite the header name, the MCP auth code passes the explicit x-litellm-api-key value to user_api_key_auth, which handles JWTs when JWT auth is enabled. OBO subject extraction reads Authorization. Since you already have AWS JWT authentication working, this is the split I would check first.

Configure the target MCP server with auth_type: oauth2_token_exchange and token_exchange_profile: entra_obo. The user access token must target the Entra app registration used for the exchange. The AWS workload JWT authenticates the caller to LiteLLM; it is not the user's Entra OBO assertion. The OBO guide documents this two-header layout with a LiteLLM key.

You still need to verify which users each agent is allowed to act for. Sending both tokens alone does not enforce that policy. Test a denied agent/user pair as well as an invalid workload JWT and an expired user token.

This is based on an AI-assisted review of 709b27e; I have not run the full AWS-to-Entra exchange. Which LiteLLM version are you deploying? We can check whether its auth path matches this snapshot.

[Sadrak2017]

Alongside the denied-pair case, I’d test revocation on a cache hit: obtain an OBO token for an allowed agent/user pair, revoke the agent’s tool access, then repeat the same request. Our work on Sinaps Studio at SinapsData checks current per-agent permissions at dispatch. A cached downstream token should supply credentials, while the gateway still makes a fresh authorization decision; token lifetime and permission lifetime need not coincide.