Answers · MCP security

How do I share one MCP server across a company without everyone using one shared credential?

Short answer: Run one shared MCP server, but make every call act as the person who asked. Users sign in to the server through your identity provider (the MCP authorization spec uses OAuth 2.1 for remote servers), the server validates that the token was issued for it, and when it calls a downstream API (GitHub, Jira, a database) it swaps the user's token for a downstream token in that user's name: an on-behalf-of (OBO) flow or OAuth 2.0 Token Exchange (RFC 8693). That keeps each user's own permissions in force and puts the real person in every audit log, which a single shared service credential cannot do: with one shared key, every user can do whatever the key can, and the logs show only the key. Two rules go with it: never pass the user's token through to downstream APIs unchanged, and treat everything tools return as untrusted data, not instructions.

Checklist

1. Put the server behind your identity provider: remote MCP clients authenticate with OAuth, so users sign in with their company account and the server receives a token per user, not a shared API key in a config file.
2. Validate every token: issuer, expiry, signature and audience. The MCP spec requires servers to accept only tokens issued for them; clients name the server with the resource parameter (RFC 8707) so a token for one server can't be replayed at another.
3. For each downstream API, exchange the user's token for one scoped to that API and that user: OBO in Microsoft Entra ID, or RFC 8693 token exchange where your identity provider supports it. Where a downstream system has no token exchange, have each user connect their own account once and store that grant per user.
4. Don't pass the incoming token through to downstream APIs. The MCP security best practices forbid token passthrough, because it skips the downstream service's own audience checks and breaks the audit trail.
5. Request the narrowest scopes each tool needs, and keep write, delete and send tools behind an explicit user confirmation in the client.
6. If something must run as a service account (a scheduled job, a system with no per-user auth), give it its own narrowly scoped identity, and record the requesting user alongside it in the log.
7. Log every tool call with the user, the client, the tool, the downstream identity used, the target resource, the result and a request ID, and keep tokens and secrets out of the logs.

Why one shared credential fails

• Permissions collapse to the key: an intern and an admin get the same access, so the shared server becomes a way around your normal access rules.
• Attribution disappears: the downstream log shows the service account for every call, so you can't tell who asked for a change or a data export.
• Revocation is all or nothing: when one person leaves or one laptop is compromised, the only fix is rotating the key for everyone.
• A shared server also becomes a confused deputy: if an attacker can steer the model, through a poisoned tool result or document, it acts with the shared key's full reach.

Tool results are untrusted

• Per-user auth limits what a hijacked call can reach; it doesn't stop the hijack. Text that comes back from a tool (an issue body, an email, a web page, a file) can carry instructions aimed at the model.
• Treat tool output as data: don't let it trigger further write or send calls without the user's confirmation, and keep the tools exposed in a session limited to what the task needs.
• Record a hash of each tool's definition at approval and re-check it, so a changed tool description doesn't slip in unnoticed.

Ask Rightshold (free, no key)

Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code, then ask: “Before we roll this MCP server out company-wide, is it a listed server, what tools does it expose, and have its tool definitions changed?”

One-click setup

{
  "tool": "precall_check",
  "arguments": {
    "url": "<the MCP server's https URL>"
  }
}

• The answer combines the external registry entry, a live integrity probe against the recorded tool fingerprint, an invisible-text scan of the definitions and any security flags. It is evidence to decide from, never a finding that a server is safe.
• scan_text checks a tool result or document for content a reader cannot see (zero-width characters, hidden markup, instruction-like text) before an agent acts on it.
• Delegated and intent keys on Rightshold follow the same rule: an agent gets only the scopes its task needs, never the owner's full key.

Rightshold does not sit in your identity provider, issue tokens for your servers or enforce permissions in your MCP client; per-user auth and audit logging live in your identity provider, MCP server and downstream systems.

Sources

• MCP specification: Authorization (2025-06-18)
• MCP specification: Security Best Practices (token passthrough, confused deputy)
• RFC 8693: OAuth 2.0 Token Exchange
• RFC 8707: Resource Indicators for OAuth 2.0
• Microsoft identity platform: OAuth 2.0 On-Behalf-Of flow
• OWASP Logging Cheat Sheet

Related

• MCP OAuth wrong-audience tokens
• How to detect MCP tool description changes (rug pulls)
• How to stop Log-To-Leak style prompt injection through MCP tools
• How to vet an MCP server before installing it

Not legal advice. Updated 2026-10-29. JSON · Markdown · All answers

curl -s -X POST https://www.rightshold.com/v1/accounts/signup -H "Content-Type: application/json" -d '{"accept_terms":true}'
export RIGHTSHOLD_API_KEY=rs_...   # the api_key from the reply (shown once)
curl -s https://www.rightshold.com/v1/licenses/check -H "Authorization: Bearer $RIGHTSHOLD_API_KEY" \
  -H "Content-Type: application/json" -d '{"license":"MIT","intended_use":{"commercial_use":true}}'