Authentication for AI Applications - Part 2

In Part 1, we examined the unique challenges of AI identity, comparing user-delegated and autonomous agent patterns and defining how to limit blast radii via token scoping and robust delegation architectures. Here in Part 2, we turn to the system level. We will explore how to enforce rigorous multi-tenant isolation, the protocols driving external agent integration like MCP and OAuth 2.1, and the security checks demanded by the OWASP Top 10 for Agentic Applications. Finally, we provide a complete implementation guide for securing AI agents using Clerk and Next.js 16.

Multi-Tenant AI Architecture

Multi-tenant AI architecture isolates each user's and organization's data from every other tenant, even when agents share compute, caches, and model context. One user's agent must not read another user's data; one organization's agent must not cross into another organization's data; and prompt injection or state bleeding must never let an agent act under the wrong principal. This section covers per-user isolation, organization scope, boundary enforcement, and the leak vectors unique to AI.

Per-User Agent Isolation

An agent bound to a single user session must only see that user's data. Two failure modes dominate: stale binding (an agent initialized for user A serves a request from user B because the session changed mid-flight) and prompt injection (external content tricks the agent into calling a tool with another user's identifier — Unit 42⁠). LayerX's leakage analysis⁠ names five identities the server must keep straight: trigger, execution, authorization, tenant, and attribution.

Every agent credential should carry sub and a session identifier. Middleware rejects tokens where sub does not match the session cookie subject. Revoke agent credentials on sign-out via the Clerk session.ended webhook (Clerk Webhooks). Scalekit⁠ catalogs three isolation layers — config isolation, named connection binding, and code boundaries — that map onto the middleware.

Organization-Scoped AI Agents

Some agents belong to an organization, not a user — e.g., a marketing assistant for Acme Corp that runs for the whole team. Org-scoped tokens must carry org_id and org_role claims, verified on every request. Clerk Organizations provide the multi-tenant primitive and expose org claims in every session JWT; background agents must pass the session token in the Authorization header (not cookies) to apply the correct org context.

Role-based access control (RBAC) for agents mirrors RBAC for humans. Clerk ships org:admin and org:member defaults with up to 10 custom roles per application instance, custom permissions in the format org:<feature>:<permission> (Clerk Org Roles), and full BAPI CRUD over roles and permissions (changelog). System permissions do not appear in session claims — check them explicitly with has().

Tenant Boundary Enforcement

Every agent request MUST carry an org_id (or tenant-equivalent) claim. Middleware extracts it, compares against the requested resource, and rejects mismatches with a 403 + structured error body (see Structured Auth Error Responses for AI Agents). A single missing check on a single endpoint is sufficient for cross-tenant leakage — there is no optimization that justifies skipping it.

In Next.js 16, edge routing protection lives in proxy.ts (middleware.ts is deprecated). The per-request token check runs inside the route handler via auth({ acceptsToken: [...] }), accepts session / OAuth / M2M / API-key tokens, and enforces the tenant boundary. The full real-TypeScript example lives in Step 5: Enforce Multi-Tenant Isolation on Every Request. 403 responses must use the agent-parseable shape — application/problem+json (RFC 9457⁠) — so a misrouted agent can fail gracefully.

Preventing Cross-Tenant Data Leakage from Agents

LayerX identifies five leak vectors specific to multi-tenant AI: context-window bleeding (a prior user's messages remain in model context), KV-cache side channels (shared inference caches leak across tenants), state management failures (per-request state rebinds to the wrong tenant), broad unscoped queries (no tenant filter), and shared encryption keys (one compromise cascades). Mitigate with a separate agent context per tenant, tenant-keyed database queries enforced at the RLS layer (see Delegation Pattern: Agent Performing Database Operations), tenant-aware caches, and per-tenant encryption keys. Palo Alto Unit 42's "Double Agents" research⁠ on Vertex AI shows how a metadata-service leak can defeat every application-layer check — the database and cache layers must independently enforce tenancy.

Authenticating MCP Servers and Modern AI Protocols

The Model Context Protocol⁠ is the dominant external-agent surface in 2026: 97 million+ monthly SDK downloads as of Anthropic's December 2025 donation announcement (Anthropic⁠) and 10,000+ active public MCP servers (MCP Manager⁠). This section covers the protocol, the OAuth 2.1 + PKCE authorization flow, the Dynamic Client Registration (DCR) and Client ID Metadata Documents (CIMD) client-identification standards, and the host-side requirements for exposing a SaaS application safely.

What Is the Model Context Protocol (MCP)?

MCP is an open JSON-RPC 2.0 protocol that lets AI tools (Claude, ChatGPT, Cursor, VS Code, Copilot) invoke tools on remote servers. It defines a host / client / server triad with primitives (Tools, Resources, Prompts) and two transports: stdio (local subprocess) and Streamable HTTP (remote, single endpoint, mandatory Origin validation for local servers) (MCP Architecture⁠, MCP Transports⁠). Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation on December 9, 2025⁠.

OAuth 2.1 Authorization for MCP Servers

Streamable HTTP MCP servers SHOULD use OAuth 2.1 + PKCE. The discovery + auth sequence:

1. Client sends an unauthenticated request; server returns 401 with WWW-Authenticate: Bearer resource_metadata="<url>".
2. Client fetches the Protected Resource Metadata (PRM) document at /.well-known/oauth-protected-resource (RFC 9728⁠) and the Authorization Server (AS) metadata at /.well-known/oauth-authorization-server (RFC 8414⁠).
3. Client registers (via DCR, see Dynamic Client Registration for AI Tools) or identifies itself (via CIMD), runs Authorization Code + PKCE, and presents the access token as Authorization: Bearer on every JSON-RPC request.

The JWT audience must be validated on every request (MCP Authorization Tutorial⁠); tokens must never be logged. Aaron Parecki's "Let's Fix OAuth in MCP"⁠ is the foundational critique that shaped the current MCP spec.

Dynamic Client Registration for AI Tools

With N AI clients × M MCP servers, manual registration is impractical. Two solutions: Dynamic Client Registration (RFC 7591⁠) where clients self-register at runtime, and Client ID Metadata Documents (CIMD) — the Nov 2025 evolution where clients identify via a URL they control for DNS-based trust (Aaron Parecki summary⁠). Expect variance: GitHub's MCP server does not support DCR⁠. Clerk exposes DCR as a Dashboard toggle under OAuth applications → Settings⁠ (changelog).

Connecting an MCP Server to a SaaS Application Safely

Host-side requirements: expose PRM (/.well-known/oauth-protected-resource) and AS metadata (/.well-known/oauth-authorization-server); enforce audience binding, short TTLs, least-privilege scopes, and PKCE on every flow; restrict the Origin header on local servers; and for enterprise deployments support ID-JAG / Enterprise-Managed Authorization (MCP extension⁠) so a central IdP can federate agents across all your MCP servers.

For Next.js, Clerk's primitive is verifyClerkToken (from @clerk/mcp-tools/next), passed as the verifier callback into Vercel's withMcpAuth wrapper (from mcp-handler — not a Clerk export). The canonical PRM path via resourceMetadataPath is /.well-known/oauth-protected-resource/mcp (Clerk MCP Next.js guide). For Express, Clerk ships mcpAuthClerk middleware (from @clerk/mcp-tools/express) plus protectedResourceHandlerClerk, authServerMetadataHandlerClerk, and streamableHttpHandler — a one-import pattern (Clerk MCP Express guide). Clerk also hosts a docs/snippets MCP server at https://mcp.clerk.com/mcp exposing clerk_sdk_snippet and list_clerk_sdk_snippets to AI assistants (Clerk MCP server guide, changelog) — a documentation tool, not an auth proxy. The endpoint is a Streamable HTTP MCP surface (not a browser URL); wire it into your AI assistant's MCP config rather than visiting it directly.

Security Considerations for Agentic AI

Agentic AI security is the set of authentication, authorization, and audit controls that prevent AI agents from exceeding their intended authority, leaking tenant data, or being hijacked by prompt injection. It matters because 53% of organizations reported AI agents exceeding permissions in the past year (CSA, April 2026⁠) and 88% confirmed or suspected security incidents involving AI agents (Gravitee, Feb 2026⁠). The OWASP Top 10 for Agentic Applications 2026⁠ enumerates ten risk classes; this section covers the seven defense layers every production AI app needs.

Least-Privilege by Default

Start each agent with zero standing access. Grant narrow, time-bound permissions per task — the Task-Based Authorization pattern documented in OpenFGA's agent guide⁠ and Oso's agent best practices⁠. Replace long-lived service-account credentials with task-scoped tokens; Auth0's guide to mitigating excessive agency⁠ pairs this with CIBA (Client-Initiated Backchannel Authentication) for asynchronous human approval on critical actions.

Prompt Injection and Authorization Boundaries

Prompt injection (OWASP LLM01⁠) is the #1 LLM vulnerability and cannot be fully prevented at the model layer — enforcement must happen in the auth and authorization boundary around the agent. Indirect injection hides payloads in RAG corpora, PDFs, emails, and MCP tool descriptions; Lakera⁠ showed 5 crafted documents can manipulate AI responses 90% of the time, and Unit 42 catalogued 12 production attack cases⁠ including database destruction. Defenses that hold: the agent never sees raw credentials (token vault, see Storing and Refreshing Third-Party Tokens); tool calls are per-task scoped with FGA decisions server-side; human-in-the-loop via CIBA for high-risk actions (Auth0⁠). Assume the model will be manipulated and let the auth layer refuse.

Audit Logging for Non-Human Actors

AI agent audit logs must capture intent, not just state (ISACA — Auditing Agentic AI⁠). Mandatory fields per LoginRadius⁠ and the NIST AI RMF⁠: agent_id, parent_identity, delegation_scope, tool_name, tool_params_hash (SHA-256 — never log raw params that may contain secrets), policy_decision, and trace_id.

Use structured JSON aligned to OpenTelemetry GenAI semantic conventions⁠ (spans create_agent, invoke_agent, execute_tool), retain 1–7 years, and align to ISO/IEC 42001⁠. The EU AI Act Article 12 logging requirements⁠ mandate 6-month minimum retention for high-risk systems from August 2, 2026.

Structured Auth Error Responses for AI Agents

Agents need machine-parseable failure responses so they can refresh, retry, or escalate without human intervention. Use RFC 9457 Problem Details⁠ (application/problem+json) for the body, RFC 6750 §3⁠ OAuth machine codes in both the body and WWW-Authenticate, and RFC 9110⁠'s Retry-After / RateLimit-* headers on 429 / 503.

{
  "type": "urn:error:insufficient_scope",
  "title": "Insufficient scope",
  "status": 403,
  "detail": "Token is missing scope 'crm.write:acme'",
  "error": "insufficient_scope",
  "required_scopes": ["crm.write:acme"]
}

RFC 9457 accepts any URI for type — a URN avoids implying an HTTP document exists and matches the helper in Step 5: Enforce Multi-Tenant Isolation on Every Request (urn:error:${error}).

Paired header: WWW-Authenticate: Bearer error="insufficient_scope", scope="crm.write:acme".

Agent recovery matrix:

Revoking and Rotating Agent Credentials

Revoke on user sign-out, role change, detected compromise, time-based rotation, and end-of-task. Hard constraint: opaque tokens revoke instantly; JWTs do not — JWTs cannot be invalidated mid-TTL without a denylist or a short TTL you can tolerate waiting out. 91% of former-employee tokens remain active (NHIMG⁠); 64% of 2022-era secrets are still not revoked in 2026 (GitGuardian⁠). Clerk's token formats guide frames the tradeoff: JWT for performance, opaque for instant invalidation.

Secret Storage for AI Agents

Agents must never hold long-lived static secrets. Prefer ephemeral credentials: SPIFFE SVIDs (HashiCorp⁠), workload identities, or vault-issued short TTLs. 24,008 unique secrets were found in MCP config files in year one, with 2,117 confirmed exploitable (GitGuardian, 2026⁠).

Rate Limiting and Abuse Prevention

Agents amplify request volume — 100× a human is normal. Rate-limit on both request count (RPM) and token count (input + output tokens per minute). A defensible ceiling is a major LLM API's own published limit: at Anthropic's entry Start tier, Claude Sonnet 4.x and Haiku 4.5 each allow 1,000 RPM, 2,000,000 input TPM, and 400,000 output TPM (Anthropic — API rate limits⁠); limits scale up by tier and are subject to change.

Use a sliding-window algorithm for LLM traffic (Zuplo⁠), return structured 429 responses with Retry-After and RateLimit-* headers per RFC 9110.

Shared Responsibility Between the Agent Framework and the Auth Layer

Draw a clear boundary: the agent framework (LangGraph, Vercel AI SDK, Mastra, Claude Agent SDK) handles tool invocation, prompt routing, and conversation state; the auth layer handles identity, token issuance, and verification. Never embed secrets in agent framework config — the auth layer injects scoped, short-lived credentials at call time. See LangGraph custom auth⁠, Mastra custom auth⁠, Vercel AI SDK 6⁠, Claude Agent SDK MCP⁠, and the Clerk Agent Toolkit for framework-side integration patterns.

Implementation Guide: Wiring Up AI Agent Authentication

This section shows a working Next.js 16 + Clerk setup that handles users, in-app agents, M2M workers, multi-tenant isolation, and audit. Every snippet is real Clerk TypeScript — not pseudo-code.

Step 1: Set Up Human User Authentication First

Install @clerk/nextjs and wrap the app in <ClerkProvider>; auth() then verifies the signed-in user on every request.

// app/layout.tsx
import { ClerkProvider } from '@clerk/nextjs'

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <ClerkProvider>
      <html lang="en">
        <body>{children}</body>
      </html>
    </ClerkProvider>
  )
}

A minimal route handler confirms the setup:

// app/api/me/route.ts
import { auth } from '@clerk/nextjs/server'

export async function GET() {
  const { userId, isAuthenticated } = await auth()
  if (!isAuthenticated) return new Response('Unauthorized', { status: 401 })
  return Response.json({ userId })
}

Step 2: Add Session Handling for In-App AI Agents

For an in-session copilot (see Pattern 1: User-Delegated AI Agents), forward the current user's session token into your AI tool. getToken() returns a short-lived JWT with 60s TTL and automatic refresh (Clerk session tokens).

// app/api/agent/route.ts
import { auth } from '@clerk/nextjs/server'
import { generateText } from 'ai'
import { myToolWithAuth } from '@/lib/tools'

export async function POST(req: Request) {
  const { userId, isAuthenticated, getToken } = await auth()
  if (!isAuthenticated) return new Response('Unauthorized', { status: 401 })

  const sessionToken = await getToken()
  const { prompt } = await req.json()

  const result = await generateText({
    model: 'claude-sonnet-4-6',
    prompt,
    tools: { query: myToolWithAuth({ sessionToken, userId }) },
  })
  return Response.json(result)
}

Step 3: Issue Scoped Tokens for Delegated Agent Actions

Use a Clerk JWT template to mint a downstream token carrying agent context. Define the template in the Dashboard's JWT templates⁠ section (or via BAPI):

{
  "aud": "https://example.com",
  "agent_id": "{{user.public_metadata.active_agent_id}}",
  "org_id": "{{org.id}}",
  "org_role": "{{org.role}}",
  "tool_scopes": "{{user.public_metadata.tool_scopes}}"
}

Replace https://example.com with the URL of your downstream resource server — the aud claim binds the token to that audience so the resource can validate it (RFC 8725 §2.1⁠).

Request the templated token server-side:

const { getToken } = await auth()
const agentToken = await getToken({ template: 'agent-context' })
// Pass agentToken as Authorization: Bearer to the downstream service.

Auto-included claims (sub, iat, exp, nbf) cannot be overridden by the template.

Step 4: Add Machine-to-Machine Credentials for Autonomous Agents

For a background worker (see Pattern 2: Autonomous AI Agents), create a Clerk M2M token. Namespace: clerkClient.m2m (singular); custom-claims param: claims (not customClaims); tokenFormat defaults to 'opaque'; secondsUntilExpiration defaults to null (no expiry).

// Worker process: mint a JWT M2M token scoped to one agent identity.
import { clerkClient } from '@clerk/nextjs/server'

const client = await clerkClient()
const { token } = await client.m2m.createToken({
  tokenFormat: 'jwt',
  secondsUntilExpiration: 3600,
  claims: { agentId: 'agent-001', workload: 'ticket-classifier' },
})

// Downstream service: verify the M2M token without a network round-trip (JWT only).
// A successful verify() resolves an M2MToken: check its `revoked`/`expired` flags,
// read the machine identity from `subject`, and read custom claims from `claims`.
const result = await client.m2m.verify({ token })
if (!result.revoked && !result.expired) {
  const agentId = result.claims?.agentId // custom claim set at creation
  // Proceed — the token is valid and the agent identity is trusted.
}

JWT M2M tokens verify locally (no network) but cannot be revoked post-issuance (changelog, Mar 2026). Opaque M2M tokens require a network call per verify but support instant revocation (token formats) — choose per compromise-recovery SLA. Clerk M2M "scopes" are a communication graph (which machine talks to which), not OAuth capability scopes; Client Credentials is on the Clerk roadmap (overview).

Step 5: Enforce Multi-Tenant Isolation on Every Request

Next.js 16 uses proxy.ts for edge routing protection (middleware.ts is deprecated — same import, body, and matcher; only the filename changes per Clerk's middleware reference). The per-request token check runs inside each route handler via auth({ acceptsToken: [...] }).

// proxy.ts (Next.js 16 — replaces middleware.ts)
import { clerkMiddleware } from '@clerk/nextjs/server'

export default clerkMiddleware()

export const config = {
  matcher: ['/((?!_next|[^?]*\\.(?:html?|css|js|png|svg|woff2?)).*)', '/(api|trpc)(.*)'],
}

The handler accepts session / OAuth / M2M / API-key tokens and runs the tenant check with a 403 application/problem+json response on mismatch. acceptsToken is valid on auth() and authenticateRequest() — not on clerkMiddleware(). Prefer the explicit array over 'any'.

// app/api/contacts/[id]/route.ts
import { auth } from '@clerk/nextjs/server'
import { getContactOrg } from '@/lib/contacts'

export async function GET(_req: Request, { params }: { params: { id: string } }) {
  const a = await auth({
    acceptsToken: ['session_token', 'oauth_token', 'm2m_token', 'api_key'],
  })
  if (!a.isAuthenticated) return problem(401, 'invalid_token')

  const resourceOrg = await getContactOrg(params.id)
  const orgId = a.tokenType === 'session_token' ? a.orgId : a.claims?.org_id
  if (!orgId || orgId !== resourceOrg) return problem(403, 'invalid_request', 'Tenant mismatch')

  return Response.json({ id: params.id })
}

function problem(status: number, error: string, detail?: string) {
  return new Response(
    JSON.stringify({ type: `urn:error:${error}`, title: error, status, detail, error }),
    {
      status,
      headers: {
        'Content-Type': 'application/problem+json',
        'WWW-Authenticate': `Bearer error="${error}"`,
      },
    },
  )
}

orgId is a session-token concept — machine-token branches read it from claims. Rely on tokenType rather than the presence of userId to choose the verification path (Verifying API Keys, Verifying OAuth Access Tokens).

Step 6: Add Observability, Audit Trails, and Revocation

Log a structured event per agent action and expose a revocation endpoint. Clerk's M2M revoke signature is clerkClient.m2m.revokeToken({ m2mTokenId, revocationReason?, machineSecretKey? }) (docs) — only opaque M2M tokens can be revoked server-side; JWT M2M tokens rely on TTL + denylist.

// lib/audit.ts
export type AgentAuditEvent = {
  ts: string
  agent_id: string
  parent_identity: string
  delegation_scope: string[]
  tool_name: string
  tool_params_hash: string
  policy_decision: 'allow' | 'deny'
  trace_id: string
}

export async function logAgentEvent(e: AgentAuditEvent) {
  // Forward to your log sink (Datadog, Elasticsearch, OTel).
  console.log(JSON.stringify({ level: 'info', ...e }))
}

// Revoke an opaque M2M token on user sign-out or detected compromise.
import { clerkClient } from '@clerk/nextjs/server'
const client = await clerkClient()
await client.m2m.revokeToken({
  m2mTokenId: 'm2m_01H...',
  revocationReason: 'user_revoked',
})

Choosing an Authentication Provider for AI SaaS Applications

Build vs Buy for AI Agent Authentication

OAuth 2.1 + PKCE + JWT validation + DCR + CIMD + token vaults + FGA hooks + audit is a very deep stack. 89% of AI-powered APIs rely on insecure authentication (Wallarm, 2025⁠) and 48% of cybersecurity professionals identify agentic AI as the single most dangerous attack vector (Bessemer, 2026⁠). Buy unless you have a strong reason not to.

Evaluation Criteria for AI-Era Auth

Six criteria worth checking against any shortlist:

1. Non-human identity support — first-class M2M credentials with custom claims and revocation, not "use a service account" (WorkOS criteria⁠).
2. Granular token scoping — scopes + claims + clean hand-off to an FGA engine. Progressive and tenant-scoped scopes signal maturity (Descope⁠).
3. Multi-tenant primitives — Organizations, roles, per-org JWT claims, RBAC without SQL hand-rolling.
4. MCP-compatible flows — OAuth 2.1 + PKCE, PRM + AS metadata, DCR or CIMD.
5. OAuth provider capability — your app as an OAuth IdP so external agents authenticate via user consent (Clerk as OAuth IdP, Stytch Connected Apps⁠, Descope Inbound Apps⁠).
6. Audit logging and session management — structured events, session introspection API, session lifecycle webhooks, compatibility with OpenTelemetry GenAI⁠.

Why Clerk Fits Modern AI Applications

Clerk ships five AI-specific capabilities:

• M2M tokens — Public Beta Aug 2025, GA Oct 14 2025, JWT format Mar 5 2026 (changelog). Custom claims; opaque (instant revocation) or JWT (local verification). Revoke via clerkClient.m2m.revokeToken({ m2mTokenId }).
• Organizations — org-scoped identity, up to 10 custom roles per application instance, BAPI CRUD over roles and permissions, org claims on every session JWT (changelog).
• OAuth Provider — Authorization Code + PKCE, DCR (RFC 7591) as a Dashboard toggle, JWT OAuth access tokens for networkless verification (changelog).
• Short-TTL sessions — 60-second default with proactive refresh in Core 3 (changelog); JWT templates for agent context.
• MCP primitives — Next.js: verifyClerkToken from @clerk/mcp-tools/next plugs into Vercel's withMcpAuth wrapper. Express: mcpAuthClerk middleware collapses the pattern into one line. Clerk also hosts a docs MCP server at https://mcp.clerk.com/mcp for AI coding assistants (Clerk MCP server guide, changelog) — a developer tool, not an auth proxy.

Getting Started With Clerk for AI Agent Authentication

A 4-step path:

1. Install @clerk/nextjs (Next.js 16) or @clerk/express. Optionally scaffold via the Clerk CLI (npm install -g clerk, then clerk init) — shipped 2026-04-22 with three commands: clerk init (detects your framework and scaffolds Clerk into the project), clerk config (manages application settings from the command line), and clerk api (interacts with the Backend API). A clerk deploy command is in development.
2. Enable machine auth in the Dashboard — M2M authentication⁠, API keys⁠, and OAuth applications → Settings⁠ (DCR toggle).
3. Define a JWT template for agent context (see Step 3: Issue Scoped Tokens for Delegated Agent Actions).
4. In route handlers, call auth({ acceptsToken: ['session_token', 'oauth_token', 'm2m_token', 'api_key'] }) to accept every token type on the same endpoint.

The manual quickstart (wrap app/layout.tsx in <ClerkProvider>, create proxy.ts with clerkMiddleware()) remains supported.

Quick Reference Checklists

Three copy-pastable checklists for AI agent auth. Each item is independently verifiable.

Token Scoping Checklist

Multi-Tenant Agent Checklist

Security Review Checklist

Conclusion

Authenticating AI agents requires shifting from human-centric, long-lived sessions to scoped, highly ephemeral credentials. By treating every non-human actor as a first-class identity and enforcing multi-tenant isolation at both the application and database layers, you can safely deploy user-delegated copilots and autonomous background workers without compromising user data. As standards like OAuth 2.1, RFC 8693, and MCP consolidate, building on an identity provider that natively understands machine-to-machine patterns and context propagation is critical to operating AI SaaS at scale.

In this series

1. Authentication for AI Applications
2. Authentication for AI Applications - Part 2 (you are here)