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 workflow example

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.

Implementation approach

This guide is anchored in OpenAI MCP guide. Use the official API behavior as the boundary, then design the surrounding product state so the feature can be reviewed, retried, and improved.

Put MCP tools behind the same identity provider or session layer used by your product.
Resolve the current user and organization on the server for every tool call.
Check resource ownership before returning records or executing actions.
Redact fields that the user would not see in the normal product UI.
Record safe access logs without storing tokens or sensitive payloads.

Code or config snippet when useful

type authentication_for_mcp_server_flow_workflow_state = {
  sourceId: string;
  status: "draft" | "needs_review" | "approved" | "blocked";
  evidence: Array<{ source: string; summary: string }>;
  nextAction: string;
};

Field notes

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.

Mistakes to avoid

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.

Ready checklist

Trusted identity resolution
Resource ownership checks
Role claims not model-controlled
Sensitive fields redacted
Safe audit logs

Practical tip

Practical note

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

Use this as an implementation constraint, not just advice. The interface, server code, and validation path should make the same behavior true.

Apply this to a build