Prefer per-user sign-in for any connector that returns security findings. A shared credential gives every user the same access and blurs who did what. Use a shared key only for a short pilot with read permissions and a named owner, because Claude's help center says shared credentials give everyone that credential's access.
The two models
With per-user sign-in, each person authorizes the connector with their own account. The server issues a token for that person, with the scopes they approved. With a shared credential, an admin sets one key or header, and every member who uses the connector acts through it.
Claude's help center describes the choice for Team and Enterprise: after an admin adds a connector, each member connects individually, but a connector with a shared credential, such as an API key, gives everyone that credential's access.
Comparison
| Factor | Per-user OAuth | Shared credential |
|---|---|---|
| Who the server sees | The actual person | One shared identity |
| Audit trail | Per person | Per key |
| Revocation | Remove one user | Rotate for everyone |
| Least privilege | Scopes per user | One permission level for all |
| Setup effort | Higher | Lower |
| Leak impact | One person's access | Everyone's access |
What the MCP security guidance adds
The best practices page says token passthrough is an anti-pattern, because it breaks accountability. It notes that the server cannot tell clients apart and the downstream logs show a different identity than the real source. A shared key has a similar effect: the logs show the key, not the person.
It also covers scope minimization. A token with broad scopes enlarges the blast radius, makes revocation disruptive, and adds audit noise. One omnibus key for a whole team is the extreme version of that.
When shared is acceptable
- A time boxed pilot with a small group.
- A read only key that cannot return customer data.
- A named owner who can rotate it.
- A plan to move to per-user sign-in before wider rollout.
Questions for the vendor
- Can access be tied to a user identity and a role?
- Can the key be restricted to read operations?
- Do tool calls record which user made them?
- How fast can we revoke a single person?
If the answer to the third question is no, you cannot reconstruct events later.
Moving from shared to per-user
Run both for a short overlap, move users in groups, then rotate the shared key and confirm nothing still depends on it. Update your register of connectors afterward.
A worked example: moving a pilot from shared to per-user
This is a made up scenario.
A team of eight starts with a shared read only key, because the vendor's connector supports that first. The key is stored in connector settings, and an owner is named. After three weeks, two things happen. A new contractor needs access for one project, and the security lead is asked who looked at a particular finding last Tuesday. With a shared key, neither question has a clean answer: the contractor would get the same access as everyone, and the logs show only the key.
The team switches to per-user sign in. The steps: ask the vendor to enable OAuth for the workspace, invite users in two groups, have each person connect and review scopes, confirm in the vendor's access list that each user appears, then rotate the shared key and confirm nothing breaks. The contractor gets a role limited to one project.
Step by step: audit a shared credential
- Find where the key is stored and who can read it.
- Find who created it and when. If nobody knows, rotate it.
- Check the permissions attached to it. Reduce them to read only if possible.
- List who uses the connector.
- Check whether the vendor logs show which person made each call. If not, note the gap.
- Set a rotation date.
- Schedule the move to per-user sign in.
Table: what each model can answer after an incident
| Question | Shared key | Per-user OAuth |
|---|---|---|
| Which person asked for this data | Probably not | Yes, if the vendor logs users |
| Which tool was called | Yes, if logged | Yes |
| Can we cut off one person | Not without rotating | Yes |
| Can we limit one person to one project | No | Yes, with roles and scopes |
| How fast is cleanup after a leak | Rotate and update everywhere | Revoke the user |
Why the guidance cares
The MCP best practices page describes how accountability suffers when a server cannot tell clients apart, and when downstream logs show a different identity from the real source. It names this under token passthrough, but the lesson is general: if identity is blurred, investigation is harder.
The same page also stresses that tokens should be scoped narrowly, since a broad token that leaks affects every workflow that uses it.
A realistic compromise
Sometimes the vendor only offers a shared key for now. In that case reduce harm: read only permissions, a short expiry, a named owner, no use in research runs, and a dated commitment from the vendor to support per-user sign in. Put the gap in your risk register so it does not fade from view.
Conversation starter for the vendor
Ask: if one of our engineers leaves today, what exactly do we do at your side, and how long does it take? Their answer shows which model they built for.
Where Safeguard fits
Safeguard offers agent identity and an MCP Guardrail for teams that want agents and tools tied to accountable identities. A free scan at gold.safeguard.sh/scan shows what a connector would be exposing.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at where access is configured, and ask whether that step is per person or shared by everyone.
Quick check
Is a shared key ever fine?
For a short read only pilot with an owner, yes. Plan to move to per-user sign in.
Does per-user sign in remove the need for scopes review?
No. Users still approve scopes, so read what is requested and decline extras.
Does per-user sign in need more admin work?
Some, at the start. It saves time later because revoking and auditing are per person.
Sources
- MCP specification, authorization
- MCP security best practices
- Claude Help Center, custom connectors using remote MCP
Last reviewed: 19 October 2026.
