Secure Authentication for AI Agents & MCP Servers

Context

AI agents and MCP servers introduce a new authentication challenge: how do you securely delegate permissions to autonomous systems that act on behalf of users?

Traditional OAuth works for user-to-service authentication, but agents need service-to-service authentication with user context preserved. This is the agency-identity paradox.

This playbook emerged from building production AI agent systems and encountering every authentication pitfall. It codifies the patterns that work.

When to Use This Visual

Ideal for:

• Security architecture reviews for AI agent systems
• MCP server implementation planning
• Penetration testing and security audits
• Compliance documentation (SOC2, ISO 27001)

Target Audience:

• Security engineers designing AI authentication
• Backend engineers building MCP servers
• DevSecOps teams securing AI deployments
• Compliance officers evaluating AI systems

Section 1: Foundations - The Chain of Trust & Tiered Topology

The Agency-Identity Paradox

Problem: AI agents need to:

1. Act autonomously (agency)
2. Preserve user identity and permissions (identity)
3. Access multiple backend systems (distributed trust)

Tension: How do you give an agent permission to act on behalf of a user without giving it full user permissions?

Solution: Delegated permissions + tiered trust topology.

Tiered Trust Topology

Three tiers:

Tier 1: AI Host (Frontend) - Public Client

• User-facing interface (web app, IDE plugin, chatbot)
• User consents & authenticates here
• Trust level: User trusts this, delegates permissions

Tier 2: MCP Orchestrator (Client/Backend) - Confidential Client

• Coordinates agents and MCP servers
• Receives delegated permissions from Tier 1
• Trust level: Operates on behalf of user with scoped permissions

Tier 3: MCP Servers (Tools) - Confidential Client

• Access enterprise resources (e.g., SharePoint, GitHub, Jira)
• Receive tokens from Tier 2 (not directly from user)
• Trust level: Least privileged access, specific to resource

Key insight: User identity flows down the chain (Tier 1 → 2 → 3), but tokens are exchanged at each tier with reduced scope.

Visual Elements

Key:

• Blue arrows = Trust flow (user delegates to AI host, AI host delegates to orchestrator, etc.)
• Red arrows = User action (consent, authentication)
• Green arrows = Validation (token verification, permission checks)

Section 2: Core Implementation Patterns

Pattern 1: OBO Flow (Internal APIs)

Use case: AI orchestrator calling enterprise APIs on behalf of user.

How it works:

1. User → Authenticates with AI Host (Frontend)

   • Consent & Authentication
   • Token A issued

2. AI Host → Calls MCP Orchestrator (Backend)

   • Passes Token A
   • MCP Orchestrator validates Token A

3. MCP Orchestrator → Exchanges Token A for Token B

   • Token exchange (OBO - OAuth on-behalf-of)
   • Token B is scoped to specific MCP Server

4. MCP Orchestrator → Calls MCP Server (Tool)

   • Validates Token B
   • Exchanges for Token C (scoped to enterprise resource like SharePoint Graph API)

5. MCP Server → Calls Enterprise Resource (e.g., SharePoint)

   • Validates Token C
   • Returns data

Key properties:

• User identity preserved at every step (Token A → B → C all contain user claims)
• Delegated permissions (each token has reduced scope)
• Auditable (logs show user → orchestrator → server → resource)

When to use: Internal APIs where you control both client and server.

Pattern 2: STDIO Handshake (Local Agents)

Use case: AI agents running locally (e.g., IDE plugins, CLI tools) accessing MCP servers.

How it works:

Client Process (AI Host):

1. Acquire Token (via OAuth, browser flow)
2. Construct Init Payload with Token
3. Send payload via STDIO (secure stdin pipe injection)

Server Process (MCP Server):

1. Read Stdin
2. Extract Token
3. Validate Token (JWKS, aud, iss)
4. Proceed with MCP operations

Key innovation: STDIO pipe is inherently secure (process-local, not network-exposed).

Security considerations:

• Do NOT use environment variables (easily leaked, visible in process lists)
• INSECURE! Env vars are a common attack vector

When to use: Local agents (IDE plugins, CLI tools) with MCP servers running on the same machine or trusted network.

Pattern 3: Account Linking (External SaaS)

Use case: Linking user's third-party accounts (GitHub, Jira, Google) to AI agents.

How it works:

1. User initiates OAuth exchange (one-time setup)

   • Grants AI access to external service

2. MCP Tool retrieves token via OAuth ID (OID)

   • Token stored in Token Vault (encrypted, access-controlled)

3. MCP Tool makes authenticated API call to 3rd Party Service

   • Token passed in Authorization header

Token Vault requirements:

• Encrypted: Tokens at rest are encrypted
• Access-controlled: Only authorized MCP tools can retrieve
• Refresh tokens: Automatically refresh expired tokens

When to use: Integrating with external SaaS (GitHub, Jira, Salesforce, etc.)

Section 3: Advanced Scenarios & Governance

Claim Challenge Loop (MFA)

Problem: User needs to perform high-risk action (e.g., delete data, change permissions).

Solution: Step-up authentication via claim challenge.

How it works:

1. MCP Server rejects API call (401 + Challenge)

   • Response includes required claim (e.g., MFA authentication)

2. AI Host (Frontend) receives challenge

   • Initiates MFA flow (MSAL.js popup)

3. User completes MFA

   • Upgraded token issued with MFA claim

4. AI Host retries with upgraded token

   • MCP Server validates MFA claim
   • Proceeds with high-risk action

When to use:

• High-risk operations (delete, permission changes, financial transactions)
• Compliance requirements (SOC2, HIPAA, PCI-DSS)

Section 4: Security Checklist

Pre-Deployment (Design & Configuration)

✅ Multi-Tier App Registration

• Separate registrations for AI Host (public client), MCP Orchestrator (confidential client), MCP Servers (confidential clients)

✅ Delegated Permissions Default

• Use delegated permissions (scp), NOT application permissions (roles)
• Application permissions grant tenant-wide access (too broad)

✅ Stdin Handshake (No Env Vars)

• Use STDIO for local authentication
• Never store tokens in environment variables

✅ Validate Audience (aud)

• Every server validates aud claim matches expected audience
• Prevents token reuse across services

✅ Implement Claim Challenge Loop

• Support step-up authentication for high-risk actions
• Graceful MFA handling

✅ Secure Token Vault (Encrypted)

• Tokens at rest are encrypted (AES-256 or equivalent)
• Access control: only authorized services can retrieve

✅ Enable CAE & Conditional Access

• Continuous Access Evaluation (CAE) for real-time revocation
• Conditional Access Policies for context-aware authentication (location, device, risk)

Runtime (Monitoring & Operations)

✅ Structured Audit Logs

• Log every authentication event (who, what, when, where)
• Include: user ID, requested scopes, granted scopes, IP, timestamp, result (success/failure)

✅ DPoP Tokens

• Demonstrate Proof-of-Possession (DPoP) tokens for enhanced security
• Binds token to client instance, prevents token theft

✅ Resource Indicators

• Specify target resource in token requests
• Improves auditability and security (token scoped to specific resource)

Common Pitfalls

❌ Using Application Permissions Instead of Delegated

Problem: Application permissions grant tenant-wide access, not scoped to user.

Impact: Agent can access all user data, not just the authenticated user's data.

Fix: Use delegated permissions (scp claim), not application permissions (roles claim).

❌ Storing Tokens in Environment Variables

Problem: Env vars are visible in process lists, logs, crash dumps.

Impact: Token leakage risk.

Fix: Use STDIO pipes or secure vaults.

❌ Skipping Audience Validation

Problem: Tokens intended for Service A can be used for Service B.

Impact: Privilege escalation, unauthorized access.

Fix: Every service validates aud claim.

❌ No Claim Challenge Loop

Problem: Can't handle step-up authentication for high-risk actions.

Impact: Either block all high-risk actions or allow without MFA (security vs. usability trade-off).

Fix: Implement claim challenge loop with MFA support.

❌ Insufficient Audit Logging

Problem: Can't trace security incidents or compliance violations.

Impact: Fails security audits, can't investigate breaches.

Fix: Structured logs with user ID, scopes, timestamps, results.

Related Patterns

• OAuth 2.0 On-Behalf-Of Flow: Token exchange for service-to-service auth
• Continuous Access Evaluation (CAE): Real-time token revocation
• Zero Trust Architecture: Verify every request, never trust implicitly
• Least Privilege Access: Grant minimum permissions required