Agents that Pass Identities to MCP Manager

Documentation Index

Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt

Use this file to discover all available pages before exploring further.

This is an advanced pattern for teams building their own agent that calls an MCP Manager gateway on behalf of many end users. A typical case: an agent running in your cloud (say, GCP Cloud Run) that has extra skills and business context on top of a downstream MCP server — for example a BigQuery server — and is called from Claude. You want to whitelist that agent for use with Claude and have every downstream call use the calling user’s own credentials, with their own permissions, and no impersonation. MCP Manager supports exactly this. The key idea is that identity is carried by a per-user access token, not asserted in a side header. Each end user enrolls once, brings their own identity to the downstream system, and MCP Manager mints them a token. Your agent then presents the right user’s token on each call, and MCP Manager brokers that user’s own downstream credential.

​

The shape of the solution: two maps

Two lookup tables make per-user proxying work, one on each side of the gateway:

• Map 1 — in your agent: end user → MCP Manager token. Your agent already knows who the end user is (it authenticates them, e.g. from their Claude connection). It keeps a table mapping each known user to the MCP Manager access token that user generated.
• Map 2 — in MCP Manager: token → that user’s downstream identity. When the agent calls the gateway with a user’s token, MCP Manager resolves the user and uses the downstream identity that user brought (their BigQuery credential, their Atlassian login, and so on).

The result: each user’s downstream actions run with their own permissions — reads and writes are attributed to them, never to a shared agent account. Building Map 1 is the work on your side; Map 2 is what MCP Manager handles for you.

​

Step 1 — Create one token-based host for the agent

In Apps & Agents, create a single token-based host that represents the agent — the catch-all for any headless agent (one with no human signing in to it directly). Name it for the agent, for example “BigQuery via GCP agent,” and save. You only do this once, as an administrator, at Apps & Agents.

​

Step 2 — Each user enrolls and brings their identity

Each end user then enrolls themselves so MCP Manager can mint their own access token. Share the connection link (over Slack or email); each user opens it, adds a connection, picks the gateway that contains the target server, and brings their identity to that server — either through a standard OAuth handshake or by selecting an identity they’ve already added. MCP Manager stores that identity encrypted and mints the user a token scoped to the gateway.

​

Step 3 — Your agent maps each user to their token

Your agent maintains Map 1: as each user enrolls, record their MCP Manager token against the identity the agent knows them by. When a request arrives from Claude, the agent identifies the user, looks up their token, and uses it for the call. This mapping table is the piece your team builds and maintains.

​

How a call is made at runtime

At request time, the agent presents the calling user’s token to the gateway. MCP Manager resolves the user (Map 2), applies policy, calls the downstream server as that user’s own credential, logs the exchange, and returns the result. Everything between the agent and the downstream server happens inside MCP Manager’s governed zone.

​

Why this preserves identity and stays governed

Because each user brought their own identity and got their own token, the downstream server sees the real user and enforces their permissions — a data analyst reads and writes only what they’re allowed to, with no shared-account impersonation. And because every call passes through the gateway, MCP Manager applies your rules and writes an audit log entry for each one, attributed to that user. You get the full benefit of a gateway around an otherwise opaque, headless agent.

​

Controlling which agents are allowed

The token-based host is also the control point for whitelisting: an administrator can disable the host to block the agent entirely, or re-enable it, without deleting any tokens. This is how you allow a vetted agent for use with Claude and keep others out. Disabling and enabling hosts is gated by the Disable and enable hosts capability.

​

Identities behind the tokens

Each token resolves to an identity — a set of credentials scoped to one server, created by bearer token or OAuth, and stored encrypted with AES-256-GCM. For per-user attribution like the flow above, pair the agent’s servers with the gateway’s per-user identity scheme; for a single shared service account, use a shared identity. See the identities model and the gateway’s identity scheme.

​

Further reading