Identity Controls

The per-server identity choice in MCP Manager: for each server on a gateway, an administrator decides whether every user connects with their own identity (bring your own identity) or everyone shares one service account — and what each choice looks like for the end user connecting the gateway, including the connection-time prompt to bring an identity, reusing identities, Private versus shared availability, and how a departing admin’s own access ends while a shared service account they set up keeps serving everyone else.

For every server on a gateway, MCP Manager asks one question that shapes the whole experience: should each person connect with their own identity, or should everyone share one service account? This is the identity scheme, and an administrator sets it per server when assigning it to a gateway. This page explains the choice and — more importantly — what it looks like for the people who connect.

Choosing a server’s identity scheme is part of the Basic gateway management capability; creating server identities by authenticating is part of Basic server management. Managing your own identities is always available to every user and is never gated. Managing other people’s identities requires the Identity management capability. Access depends on the capability granted to your role, not on any fixed role name. See the capabilities reference.

The choice on each server assignment

When an administrator adds a server to a gateway, they pick one of two schemes for that server:

• Per-user identity (“bring your own identity”). Every person who uses the gateway authenticates to that server as themselves. The downstream system enforces their own permissions, and every action is attributed to the real person in your logs.
• Shared identity (service account). A single credential the administrator selected — typically a bot or service account — is used by everyone on the gateway. No individual sign-in is involved.

The choice is made per server, not per gateway, so one gateway can mix the two: a Notion server that each user connects as themselves, alongside a GitHub server that everyone reaches through one shared bot account. (You can even add the same server twice with different schemes — shared for read-only tools, per-user for writes. See Adding the same server more than once.)

What the end user experiences

The scheme an administrator picked determines what a person sees the moment they connect the gateway in their AI client.

When a server uses a shared identity

There is nothing for the user to do. The administrator already attached the service-account credential to that server, so it works the instant the user connects — they never see a prompt, never handle a token, and never know which credential is in use. This is the lightest possible experience, ideal for tools where individual attribution doesn’t matter or the downstream system has no per-user concept.

When a server uses per-user identity

The user is asked to bring their own identity for that server as part of connecting. MCP Manager steps them through each per-user server in turn, and for each one they either:

• Authorize a new identity — a provider consent screen opens (the standard OAuth pop-up), they approve access, and the resulting credential is stored for them; or
• Pick an identity they already added — if they’ve connected that server before, they simply select the existing identity instead of authorizing again.

Once they’ve satisfied each per-user server, the connection completes and the gateway’s tools become available — with every call to those servers running as that person. If a gateway has several per-user servers, the user is prompted once per server; servers using a shared identity are skipped entirely. A user only ever brings identities for the per-user servers on gateways their team grants them.

Reusing identities across connections

An identity is a set of credentials scoped to one server, and once a user has created one they can reuse it — there’s no need to re-authorize the same server every time they connect a new gateway or client. Behind the scenes, MCP Manager refreshes OAuth tokens automatically, so a brought identity keeps working without the user re-authenticating each session. The credential itself is encrypted with AES-256-GCM in MCP Manager’s key vault and is never exposed to the user or in logs.

Private and shared availability

When a user brings an identity, it is Private by default — only they can use it. They can instead make an identity shared (Global) so others in the organization can select it, which is exactly how an administrator stands up the service account behind a shared-identity server. A Private identity is never selectable by anyone else, even an administrator — see the full model in How identities control access across all three server types.

A shared service account belongs to the organization, not its creator

When someone leaves and is deactivated, their own access ends — their connections stop working and they can’t establish new ones. What does not break is everyone else’s. A shared (Global) service account that person happened to set up belongs to the organization, not to them: the credential in the downstream system still exists, so other users’ and agents’ connections through it keep working exactly as before. Their departure removes the person, not the shared service account they stood up — so offboarding one admin doesn’t silently sever a connection the rest of the team and your agents depend on. To retire a shared identity deliberately, disable or delete the identity itself (below) or rotate its credential.

Turning access off

Because the brought or shared credential lives in MCP Manager, access can be cut instantly. An administrator can disable an individual identity, a single connection, or an entire app or agent, and the change takes effect on the next request with nothing deleted — re-enabling restores access at once. This is the break-glass control for offboarding or an incident.

Further reading

Authentication & Identity

The security model behind identities — schemes, credential storage, token lifecycle, and attribution.

The identities model

Private and Global availability and per-user versus shared schemes, across all server types.

Agents passing identities

How a headless agent carries each end user’s own identity through to downstream servers.

Viewing logs

See each action attributed to the real user behind it.