Upstream authentication
Which credential Xokepoint uses to call each MCP server, and why the agent token is never forwarded.
The token that the agent presented to Xokepoint is issued for the Xokepoint ingress of its environment. Forwarding it to the MCP server would be token passthrough, which the MCP specification forbids: a server must not accept a token that was not issued for it. If it did, any service that received the token could use it against every other service that trusts the same issuer.
So Xokepoint calls the server with another credential, and which one depends on who the server is.
Vendor servers
A vendor server does not know Xokepoint. It accepts the vendor's own credential, obtained through OAuth when the server is registered and stored encrypted. The executor decrypts the credential only for the call.
Customer servers
A server written by the customer can trust Xokepoint instead of holding a secret of its own. Each request Xokepoint sends to it carries a token issued for that request only, by the AS of the environment, signed with ES256 (typ at+jwt):
| Claim | Value |
|---|---|
iss | The AS of the environment |
aud | The canonical URL of the server endpoint (RFC 8707): lower-case scheme and host, no default port, no query or fragment, path as registered |
sub | The subject |
act.sub | The agent |
chokepoint_tool | {"server_id", "name"} of the called tool, on tools/call only |
exp | 60 seconds, never after the end of the incoming token |
Not every message is a tool call, and the token says which kind it is:
| Message | sub | act.sub | chokepoint_tool |
|---|---|---|---|
tools/call from an agent | the subject | the agent | the tool |
Other agent messages (initialize, server/discover) | the subject | the agent | absent |
| Discovery by the registry, when the administrator connects or rediscovers the server | chokepoint:registry | absent | absent |
An agent tools/list never reaches the server: Xokepoint answers it from the reviewed tools (Transports and profiles). A server that sees a token without act should allow discovery and nothing else. Over HTTP+SSE the stream opens with a discovery token, and each message POST then carries its own token as above.
The server validates the token with the AS JWKS, which it can cache, and checks iss, aud and exp. With that it knows who the user is and which agent is acting, which a RAG server, for example, needs to filter documents. The Admin shows the issuer, the JWKS URL and the audience in the connection dialog, before the server is saved, because the first discovery already sends a token (Validate the Xokepoint token).
This token is the only authentication method of a customer server. A server that only accepts a fixed API key is not a customer server for Xokepoint: it needs a vendor connection or is not supported. The audience bound to the server URL is what prevents reuse: a token issued for one server is refused by any other.