Secure Agent Access
An agent's toolset grows one upstream at a time: an internal API today, a partner MCP server next month, a SaaS integration after that. Without a gateway, every one of those upstreams is a separate auth integration the agent has to hold: its own credential, its own token refresh logic, its own failure mode when a token expires mid-call.
The Problem
An agent talking directly to N upstream tool providers needs N sets of credentials and N auth flows implemented in its own code or SDK. Adding an upstream means shipping a new auth integration in the agent, not just a new tool call. Losing or rotating one of those N credentials is an agent-side incident, not a gateway config change.
How Zilla Solves It
Zilla presents exactly one authenticated endpoint, the mcp · server Streamable HTTP endpoint, to every agent. The agent authenticates once, with one credential, regardless of how many mcp · client or mcp-http · proxy exits the gateway routes to behind the scenes.
This is the flip side of Centralized Auth: that use case is about the gateway operator enforcing one policy for every inbound call. This one is about what changes for the agent itself, it authenticates against a single surface instead of negotiating auth with every upstream individually.
Architecture
From the agent's point of view, the fan-out to three different upstreams behind mcp · proxy doesn't exist. It sees one endpoint, one tool list, and one connection to authenticate.
One Credential, Many Upstreams
The mechanism that makes this work is the oauth guard's token exchange grant: Zilla can swap the agent's inbound token for whatever downstream credential each upstream expects, per upstream, without the agent ever seeing or managing those downstream credentials. Each mcp · client exit attaches its own downstream credential to the outbound request through its own options.authorization field, the same field an mcp · client uses to authorize any outbound request to its upstream MCP server, with the swapped token filled into a credentials template. The agent doesn't need to know that payments and internal route to services with entirely different identity providers behind them, it only needs the one token it already has. See Token Exchange for the guard configuration.
Practically, that means:
- Adding an eleventh upstream tool provider is a routing change at the gateway, not a new credential the agent has to acquire and store.
- A credential leak or rotation on the agent side touches exactly one integration, the connection to the gateway, instead of N.
- The agent's auth code doesn't grow as its toolset grows.
The Simpler Case: Forwarding the Same Credential
Not every upstream needs a swapped, downstream-scoped credential. When an upstream MCP server trusts the same identity provider the agent already authenticated against, an mcp · client exit can reuse the open-source jwt guard, the same guard validating the inbound session, on its own options.authorization field. With the default credentials template (Bearer {credentials}), the guard resolves the original bearer token the caller presented, and Zilla attaches it to the outbound request unchanged, no token exchange, no separate service credential:
south_mcp_client:
type: mcp
kind: client
options:
server: http://internal-mcp:3003/mcp
authorization:
authn_jwt:
credentials: "Bearer {credentials}"This is a narrower, single-header version of the same idea: the agent still holds one credential, and the gateway still decides per upstream what happens to it, forward it unchanged here, exchange it for something else elsewhere, without the agent ever knowing the difference.
Try It
Full guard configuration, including the token exchange flow that maps one inbound credential to per-upstream downstream tokens, is covered in OAuth Guard and Token Exchange.
Try the example
Walk through Secure Agent Access for the runnable steps: one endpoint fanning out to three toolkits, one tools/list surfacing all three.