Identity and access guide
How to control who can access an MCP connection
An MCP connection lets AI use tools and information. Check who is calling, which customer or workspace they belong to, and what they may do. OAuth lets someone authorize access to their account; it does not replace checks on each action. Protect credentials, separate reads from writes, and log decisions without exposing private data.
- Good fit
- Use delegated OAuth when a person or customer must authorize access to their own third-party account and the runtime needs revocable, scoped credentials tied to that identity.
- Pause when
- Do not force user OAuth onto a service-owned batch process with no user delegation, and do not use a shared static bearer token as a substitute for tenant-aware authorization.
When this approach helps
- The same MCP endpoint serves more than one user, client, workspace, or data boundary.
- A provider connection can be valid while still belonging to the wrong entity inside the broker.
- Operators need to revoke access or explain which scopes and identity authorized a tool call.
Follow these steps
- 01
Link the correct accounts
Document the person, application, provider account, customer, and internal workspace identifiers. Reject connections that sign in successfully but cannot be linked to the requested account.
- 02
Request only the permissions needed
Match each tool to its required provider permissions, starting read-only where possible. Explain the access in plain language. Obtain new consent before adding permissions.
- 03
Check every action
Validate token audience, issuer, expiry, connection status, account mapping, role, tool rules, and approval. Check close to the action. A successful login or AI instruction is not sufficient.
- 04
Protect credentials and test disconnect
Store credentials securely, redact logs, rotate service secrets, and support disconnect. Test that removing provider access works. Keep audit identifiers and outcomes without unnecessary private content.
Documents and records to keep
Identity binding record
The record connects internal user and tenant identifiers to the provider account and authorization grant, with status, timestamps, and revocation state.
Scope-to-tool matrix
Each exposed operation lists its provider scopes, internal role, approval need, data sensitivity, and response redaction rules.
Access audit receipt
A safe receipt captures caller, tenant, policy version, connection identifier, tool, decision, and result status while excluding bearer credentials and private bodies.
Common questions
Does OAuth make an MCP server secure by itself?
No. OAuth can establish delegated access, but the server must still validate tokens, bind the right tenant, enforce tool-specific policy, protect secrets, limit data, handle revocation, and preserve evidence for each action.
Why can an MCP connection succeed for the wrong user?
Authentication may prove control of a provider account while the broker or application maps that grant to the wrong internal user or workspace. Verify the full identity chain and entity identifiers before changing scopes or tool code.
When is a static bearer token acceptable for MCP access?
It can be appropriate for a tightly bounded service-to-service control with secure storage, rotation, narrow policy, and no need for user delegation. It should not impersonate multiple customers or replace revocable per-user authorization.