Authentication, authorization, and permissions

Overview

• Authentication establishes who a client/user is; authorization determines what that identity may do.
• MCP connection authorization and downstream business authorization are separate concerns.
• A valid connection does not automatically permit every customer's data or every tool action.

Why this matters

Shared servers could otherwise expose private records or execute writes on behalf of the wrong user.

An everyday example

A building pass permits entry; it does not permit opening every employee's filing cabinet.

A technical example

Validate a token's issuer, audience, expiry, and permitted scopes, then verify ownership of the requested claim.

How it works

1. Authenticate request
2. Establish trusted principal
3. Filter capability exposure where appropriate
4. Authorize each object/action
5. Call downstream service with controlled credentials
6. Audit.

Architecture and flow

Client credential → authenticated principal → tool + object authorization → downstream service.

The insurance assistant example

Customer A may look up A's claim, even if the model supplies customer B's identifier.

When to use it

Every remote/private MCP server and all sensitive operations.

When to avoid it

Never accept tenantId, role, or isAdmin in model arguments as authority.

Interview answer

“MCP authentication identifies the caller; the tool server still performs tenant, object, and action authorization for each call.”

Benefits, trade-offs, and production considerations

• Follow the negotiated protocol version's authorization guidance.
• Do not blindly forward inbound tokens to unrelated downstream APIs; prevent confused-deputy behavior, where a powerful server acts for a caller who lacks permission.
• MCP authorization, security guidance.