> ## 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.
# 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-gateway-concepts/mcp-gateways), **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](/deployment/rbac-and-roles/capabilities).
## 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](/features/viewing-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](/mcp-gateway-concepts/mcp-gateways#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.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart TB
Connect["👤
User connects the gateway"] --> Check{"For each server,
which scheme?"}
Check -->|"Shared identity"| Auto["Nothing to do —
the service account is already attached"]
Check -->|"Per-user identity"| Bring["Prompted to bring an identity
for that server"]
Bring --> How{"How?"}
How -->|"New"| OAuth["🔑
Authorize via the provider's
consent screen (OAuth)"]
How -->|"Existing"| Pick["🔑
Pick an identity
you already added"]
Auto --> Done["✅
Connected — tools available"]
OAuth --> Done
Pick --> Done
classDef user fill:#c3c9d4,color:#12141d,stroke:#2c2c37,stroke-width:1.5px;
classDef trust fill:#2fedb4,color:#062b4c,stroke:#059669,stroke-width:1.5px;
class Connect user;
class OAuth,Pick,Done trust;
```
### 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](/deployment/teams) 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 — and only its creator can view or edit its **header tokens** (the secret credentials behind a token-authenticated identity); for everyone else that edit control is disabled. See the full model in [How identities control access across all three server types](/mcp-gateway-concepts/mcp-servers/overview#how-identities-control-access-across-all-three-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
The security model behind identities — schemes, credential storage, token lifecycle, and attribution.
Private and Global availability and per-user versus shared schemes, across all server types.
How a headless agent carries each end user's own identity through to downstream servers.
See each action attributed to the real user behind it.