MCP securityGuide6 min

Add authentication to an MCP server flow

How to keep MCP access aligned with the same user and organization boundaries as the rest of your product.

Real example

Example: organization-scoped customer lookup

A customer success manager asks ChatGPT for customer context. The MCP server must not return data from another organization.

Resolve the authenticated user and organization on the MCP server, then use those trusted values in every query. Ignore organization id if it appears in model-generated arguments.

The same access rules that protect the web app also protect the AI-connected tool surface.

Tutorial path

How to implement it

Step 01

Put MCP tools behind the same identity provider or session layer used by your product.

Step 02

Resolve the current user and organization on the server for every tool call.

Step 03

Check resource ownership before returning records or executing actions.

Step 04

Redact fields that the user would not see in the normal product UI.

Step 05

Record safe access logs without storing tokens or sensitive payloads.

Checklist

Ready when these are true

Trusted identity resolution

Resource ownership checks

Role claims not model-controlled

Sensitive fields redacted

Safe audit logs

Field notes

What matters in practice

Authentication answers who is calling; authorization answers what they can access.

MCP tools should never trust user, organization, or role values sent by the model.

The server should derive identity and permissions from trusted session state.

Avoid these mistakes

Common failure modes

Do not trust role, userId, or organizationId from the model.

Do not rely on client-side filtering after fetching private records.

Do not log tokens or raw sensitive payloads.

Practical tip

Write MCP authorization like API authorization. The model is a caller, not a source of truth.

Apply this to a build