Authentication & Authorization

An MCP-first system requires a precise security architecture. Not every client is allowed to see every tool. Not every agent is allowed to call every tool. Not every action is allowed to be executed autonomously. Not every piece of information is allowed to enter the AI context.

For this it is necessary to clearly separate different identity types and to define the appropriate authentication mechanism for each.

The five identities

Human User

A real user of the system, with a personal identity and role-bound permissions. Typical forms: admin, employee, customer, project manager, support agent, executive.

The human user is the base identity. All delegated contexts ultimately refer back to them.

MCP Client

The application connected to the MCP server. The MCP client is not a user, but a technical actor with its own trust level.

Examples: Claude Desktop, internal AI app, own mobile app, own agent worker, external integration client.

The client only sees the tools that match its trust level and the configured scopes.

Agent Identity

The concrete agent or workflow that is acting. An agent is not identical with the client that executes it, it has its own, described identity with restricted capabilities.

Examples: Sales Assistant, Payroll Assistant, Support Agent, DevOps Agent, Reporting Agent, Personal Assistant.

Delegated User Context

The delegated user context ensures that an agent has exactly the permissions, and only as many, as the user on whose behalf it is acting. The executive may see salary data, a Sales Assistant Agent still must not have that data in its context.

Service Identity

For backend-to-backend processes without a direct user context. Service identities are technical actors with fixed, narrow scopes.

Examples: Import Worker, Scheduled Job, Sync Worker, Monitoring Agent, Billing Worker.

Authentication for humans

Human users authenticate via established methods. The choice of method depends on the security requirement and context:

• Email + Password, basic access, always combine with 2FA
• Passkeys, phishing-resistant alternative to passwords, preferred
• TOTP / 2FA, second factor for all sensitive areas
• SSO, for enterprise environments with centralized identity management
• OAuth / OpenID Connect, for third-party logins and delegated access

Authentication for MCP clients

MCP clients are authenticated via OAuth 2.1 with authorization code flow and PKCE. This prevents code injection attacks and is suitable for public clients (without a secure client secret).

Additional requirements:

• Short access token lifetimes, minimizes damage potential from token leaks
• Refresh token rotation, each refresh token redemption generates a new one; the old one is immediately invalidated
• Client allowlist, for sensitive systems only explicitly registered clients are permitted; dynamic client registration is restricted or disabled
• Redirect URI validation, only pre-registered URIs are accepted; open redirects are a common attack vector
• Token binding, where technically possible, the token is bound to the client

Authentication for internal services

Backend-to-backend communication follows different requirements than user or client authentication. Technical mechanisms without an interactive authentication step are used here:

• mTLS, mutual TLS authentication; both sides authenticate with certificates
• Signed service tokens, short-lived, cryptographically signed tokens with narrowly defined scopes; no long-lived shared secrets
• Secret manager, credentials, certificates, and keys are never stored in configuration files, but managed and rotated via a central secret manager
• Private network zones, internal services communicate in shielded network segments; no direct reachability from the public network
• IP allowlist, for critical systems, access is additionally restricted to known IP ranges
• Token rotation, service tokens also expire quickly and are regularly renewed