Aller au contenu principal

AI Agent Authentication: 5 Patterns for Enterprise APIs

· 16 minutes de lecture
STOA Team
STOA Team
The STOA Platform Team

AI agents need programmatic API access, but traditional authentication patterns designed for human users — browser cookies, session tokens, OAuth2 authorization code flows — don't work. AI agents are autonomous services, not users. They operate without browsers, without human-in-the-loop interactions, and at machine speed. This article presents five authentication patterns that work for AI agents, from the simplest (API keys) to the most secure (mTLS certificate binding), with practical implementation examples for each.

This is part of the What is an MCP Gateway series. For the broader context on why AI agents need specialized infrastructure, see Connecting AI Agents to Enterprise APIs.

Why AI Agents Need Different Authentication​

Traditional authentication flows assume a human user interacting with a browser:

  1. User clicks "Log in"
  2. Redirected to identity provider
  3. Enters credentials, approves consent
  4. Redirected back with authorization code
  5. Application exchanges code for access token

This breaks for AI agents. They have no browser, no interactive consent screen, no redirect URI. They need machine-to-machine authentication patterns: credentials in, access token out, no human interaction.

But AI agents have unique security challenges that go beyond traditional service accounts:

Prompt Injection Risk​

An AI agent's behavior can be manipulated through user input, document content, or malicious prompts. If an agent is tricked into calling an API it shouldn't, the authentication layer must catch this before the call executes.

Token Budget Constraints​

Every authentication header, every JWT claim, every certificate chain consumes tokens from the agent's context window. Authentication mechanisms must be token-efficient without sacrificing security.

Multi-Tenant Isolation​

A single AI agent infrastructure may serve dozens or hundreds of tenants. Authentication must enforce strict tenant boundaries so Agent A (tenant X) cannot access APIs registered for Agent B (tenant Y).

Audit Requirements​

When an AI agent calls an API, compliance frameworks (GDPR, DORA, NIS2) require knowing not just which agent, but which human initiated the agent session, what data was accessed, and whether the call was authorized. Traditional API keys ("which service called this?") are insufficient.

Pattern 1: API Keys — Simplest, But Use With Care​

API keys are the most straightforward authentication method: a static secret passed in an HTTP header.

How It Works​

# AI agent calls an API with an API key
curl -X POST https://api.example.com/v1/action \
  -H "Authorization: Bearer sk_live_abc123xyz" \
  -H "Content-Type: application/json" \
  -d '{"input": "data"}'

The API server validates the key against a database of known keys, retrieves associated permissions, and processes the request.

When to Use API Keys​

  • Proof of concept or sandbox environments where compliance requirements are minimal.
  • Single-tenant deployments where one agent accesses one API.
  • Low-security use cases (reading public data, non-sensitive operations).

The Risks​

API keys are long-lived secrets. If an AI agent's prompt can be manipulated to exfiltrate its API key (via a crafted tool response, for example), an attacker can replay that key indefinitely until it is manually revoked.

See Your API Keys Are in Your Git History for the most common leak vector: developers hardcoding keys in code and committing them.

Best Practices for API Keys with AI Agents​

# Bad: API key hardcoded in agent prompt
agent_prompt = """
You are a support agent with access to the CRM.
Your API key is: sk_live_abc123xyz
"""

# Good: API key injected at runtime from environment
import os

api_key = os.environ["AGENT_API_KEY"]
# Never pass the key to the agent's context window

Defense-in-depth: Even with runtime injection, implement:

  1. IP allowlists — Only accept API calls from known gateway IPs.
  2. Rate limiting — Cap calls per key per minute to detect misuse.
  3. Key rotation — Rotate keys every 30-90 days.
  4. Scope restrictions — Tie each key to specific API endpoints, not all endpoints.

For production use cases involving sensitive data or multi-tenancy, upgrade to OAuth2 or mTLS.

Pattern 2: OAuth2 Client Credentials — Machine-to-Machine​

OAuth2 Client Credentials flow is the industry standard for service-to-service authentication. It replaces static API keys with short-lived access tokens that expire automatically.

How It Works​

  1. AI agent sends client_id and client_secret to the authorization server.
  2. Authorization server validates credentials and returns a JWT access token (typically valid for 1 hour).
  3. AI agent includes the access token in API calls.
  4. Token expires; agent requests a new one before the next API call.
# Step 1: Agent authenticates with OAuth2 server
curl -X POST https://auth.example.com/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=agent-crm-reader" \
  -d "client_secret=secret_abc123" \
  -d "scope=crm:read"

# Response:
{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "crm:read"
}

# Step 2: Agent calls API with access token
curl -X GET https://api.example.com/v1/customers \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."

When to Use OAuth2 Client Credentials​

  • Multi-tenant environments where each tenant has separate service accounts.
  • Regulated industries requiring audit trails tied to specific identities.
  • Gateway-mediated access where an MCP gateway manages tokens on behalf of agents.

Security Advantages Over API Keys​

FeatureAPI KeysOAuth2 Client Credentials
Token lifetimeIndefinite (until revoked)Short-lived (1-24 hours)
RotationManualAutomatic on expiry
Audit trail"This key was used""This service account acted at this time with these scopes"
Scope limitationNone (full API access)Fine-grained (e.g., crm:read not crm:write)
RevocationRequires manual key deletionTokens expire automatically; revoke at issuer

Implementation with Keycloak​

STOA uses Keycloak for OAuth2/OIDC. Here's how to create a service account for an AI agent:

# Create a Keycloak client for the AI agent
# (via Admin Console or API)
curl -X POST https://auth.gostoa.dev/admin/realms/stoa/clients \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "clientId": "ai-agent-crm",
    "enabled": true,
    "serviceAccountsEnabled": true,
    "standardFlowEnabled": false,
    "directAccessGrantsEnabled": false,
    "clientAuthenticatorType": "client-secret",
    "secret": "generated-secret-here"
  }'

# Assign scopes/roles to the service account
# (via role mappings in Keycloak)

The agent then authenticates using client credentials and receives a JWT. The MCP gateway validates the JWT on every tool invocation.

For implementation details, see Service Accounts Guide.

Pattern 3: OAuth2 Token Exchange (RFC 8693) — Delegated Identity​

OAuth2 Token Exchange (RFC 8693) solves a critical problem: How does an AI agent act on behalf of a human user without having the user's password?

The Use Case​

A user registers as a consumer in the STOA Portal and receives initial credentials. An AI agent (e.g., Claude with MCP tools) needs to call APIs on behalf of this user, but the agent shouldn't store the user's long-lived credentials. Token exchange allows the agent to swap a user-issued token for a short-lived agent-scoped token.

How It Works​

# Step 1: User authenticates and receives a consumer token
# (via Portal login)
USER_TOKEN="eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.user_claims..."

# Step 2: Agent exchanges the user token for an agent-scoped token
curl -X POST https://auth.gostoa.dev/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  -d "subject_token=$USER_TOKEN" \
  -d "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
  -d "requested_token_type=urn:ietf:params:oauth:token-type:access_token" \
  -d "audience=https://mcp.gostoa.dev" \
  -d "scope=mcp:invoke"

# Response:
{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.agent_claims...",
  "issued_token_type": "urn:ietf:params:oauth:token-type:access_token",
  "token_type": "Bearer",
  "expires_in": 3600
}

# Step 3: Agent uses the new token to call the MCP Gateway
curl -X POST https://mcp.gostoa.dev/tools/search-contacts/invoke \
  -H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.agent_claims..." \
  -d '{"query": "Jane Doe"}'

The Security Model​

Token exchange maintains a chain of trust:

  1. User authenticates (proves identity).
  2. Authorization server issues a user token.
  3. Agent presents the user token and requests an agent-scoped token.
  4. Authorization server validates the user token, checks delegation policies, and issues a new token with reduced scope.
  5. The new token includes claims identifying both the user (original subject) and the agent (actor).

This enables delegated access with attribution: the MCP gateway knows the agent called the API, but also knows which user authorized the agent to act on their behalf.

JWT Claims in Exchanged Tokens​

{
  "sub": "user-123",  // Original user
  "act": {
    "sub": "agent-crm-assistant"  // Acting agent
  },
  "aud": "https://mcp.gostoa.dev",
  "scope": "mcp:invoke crm:read",
  "exp": 1234567890
}

Audit logs can now record: "Agent agent-crm-assistant invoked search-contacts on behalf of user user-123 at 14:30 UTC."

For implementation details, see the OAuth2 Token Exchange Fiche.

Pattern 4: mTLS Certificate Binding (RFC 8705) — Highest Security​

Mutual TLS (mTLS) with certificate-bound tokens is the gold standard for AI agent authentication. It combines cryptographic proof of identity with defense against token theft.

How mTLS Works​

In traditional TLS, only the server proves its identity (via a certificate). In mutual TLS, the client also presents a certificate:

  1. Agent connects to the API gateway with TLS.
  2. Gateway requests the client's certificate.
  3. Agent presents a certificate signed by a trusted CA.
  4. Gateway validates the certificate and extracts the agent's identity from the subject DN.
  5. Gateway issues a token bound to the certificate's thumbprint.

If an attacker steals the token, they cannot use it without also having the agent's private key.

Certificate-Bound Tokens (RFC 8705)​

When the gateway issues an access token, it includes a cnf (confirmation) claim that binds the token to the certificate:

{
  "sub": "agent-production-01",
  "aud": "https://mcp.gostoa.dev",
  "exp": 1234567890,
  "cnf": {
    "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"
  }
}

The x5t#S256 value is the SHA-256 hash of the client certificate. When the agent uses this token, the gateway verifies that the certificate hash matches the cnf claim. A stolen token (without the corresponding private key) is useless.

Implementation Example​

# Step 1: Generate a client certificate for the AI agent
openssl req -new -x509 -days 365 -nodes \
  -subj "/CN=ai-agent-prod/O=AcmeCorp" \
  -keyout agent.key -out agent.crt

# Step 2: Agent authenticates with mTLS and receives a cert-bound token
curl -X POST https://auth.gostoa.dev/oauth/token \
  --cert agent.crt --key agent.key \
  -d "grant_type=client_credentials" \
  -d "client_id=agent-prod"

# Response: access token with cnf claim

# Step 3: Agent calls API with both token and certificate
curl -X POST https://mcp.gostoa.dev/tools/delete-user/invoke \
  --cert agent.crt --key agent.key \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"user_id": "12345"}'

The gateway validates:

  1. Certificate is valid (not expired, signed by trusted CA).
  2. Certificate matches the token's cnf claim (prevents token theft).
  3. Agent is authorized to invoke this tool (OPA policy check).

When to Use mTLS​

  • High-security environments (financial services, healthcare, defense).
  • Zero-trust architectures where every service must prove its identity.
  • Compliance requirements mandating cryptographic authentication (PCI-DSS, FedRAMP).

For configuration details, see mTLS Configuration Guide.

Pattern 5: Composite Patterns — Defense in Depth​

In production, the most secure deployments combine multiple patterns:

Example: OAuth2 + mTLS​

  1. Agent authenticates with mTLS (proves identity cryptographically).
  2. Authorization server issues a certificate-bound OAuth2 token.
  3. Agent uses the token for API calls (validated via mTLS + JWT).

This provides layered security:

  • Token theft is mitigated (useless without the private key).
  • Certificate compromise is mitigated (revoke the cert, tokens expire automatically).
  • Audit trail includes both cryptographic identity (certificate DN) and logical identity (OAuth2 claims).

Example: Token Exchange + Rate Limiting​

  1. User token exchanged for agent-scoped token (Pattern 3).
  2. MCP gateway enforces per-user quotas based on the original user's identity.

If a user's account is compromised and an attacker tries to abuse the AI agent, the gateway's rate limiter detects anomalous call patterns (100 calls/second from a user who normally makes 5 calls/day) and blocks further requests.

Example: API Keys for Development, OAuth2 for Production​

  • Development environment: Agents use API keys (fast iteration, no certificate management).
  • Staging environment: Agents use OAuth2 client credentials (test token expiry and rotation).
  • Production environment: Agents use mTLS + certificate-bound tokens (maximum security).

This progression reduces friction during development while ensuring production deployments meet security standards.

Comparison: Which Pattern to Choose?​

PatternSecurity LevelComplexityBest ForToken Theft RiskAI Agent Compatible
API KeysLowVery lowPOCs, sandbox, low-securityHigh (static secret)✅ Yes
OAuth2 Client CredentialsMediumLowMulti-tenant, service accountsMedium (short-lived tokens)✅ Yes
OAuth2 Token ExchangeMedium-HighMediumDelegated access, user attributionMedium (delegation chain)✅ Yes
mTLS Certificate BindingVery HighHighZero-trust, high-security, complianceVery low (requires private key)✅ Yes
Composite (OAuth2 + mTLS)MaximumHighFinancial services, defense, healthcareMinimal (layered defenses)✅ Yes

Decision heuristic:

  • Single tenant, low compliance → API Keys (Pattern 1)
  • Multi-tenant, standard compliance → OAuth2 Client Credentials (Pattern 2)
  • User-agent delegation, audit trails → Token Exchange (Pattern 3)
  • Zero-trust, critical infrastructure → mTLS (Pattern 4)
  • Maximum security, regulated industry → Composite (Pattern 5)

How STOA Implements AI Agent Authentication​

STOA's MCP Gateway supports all five patterns through a middleware chain that applies authentication, authorization, and policy enforcement before any tool invocation reaches backend systems.

Authentication Middleware​

The gateway detects the authentication method from the request headers and validates accordingly:

// Simplified pseudo-code (STOA is implemented in Rust)
match request.headers.get("Authorization") {
    Some("Bearer <token>") => {
        // OAuth2 token validation
        validate_jwt(token)?;
        extract_claims(token)
    },
    Some("ApiKey <key>") => {
        // API key lookup
        lookup_api_key(key)?
    },
    None => {
        // Check for mTLS certificate
        extract_client_cert_dn(tls_connection)?
    }
}

Authorization with OPA​

Once the agent's identity is established, the gateway queries the Open Policy Agent:

package stoa.mcp.authz

import future.keywords.if

# Allow tool invocation if agent has required scope
allow if {
    input.agent.scopes[_] == "mcp:invoke"
    input.tool.namespace == input.agent.tenant
}

# Require mTLS for destructive operations
deny if {
    input.tool.name == "delete-user"
    not input.request.cert_verified
}

This decouples authentication (who are you?) from authorization (what can you do?), enabling fine-grained policies without hardcoding rules in the gateway code.

Certificate-Bound Token Validation​

For mTLS requests, the gateway validates the certificate binding:

// Extract cert thumbprint from TLS connection
let cert_hash = sha256(client_cert.as_der());

// Extract cnf claim from JWT
let token_cnf = jwt_claims.get("cnf")?.get("x5t#S256")?;

// Validate binding
if cert_hash != token_cnf {
    return Err("Certificate binding mismatch");
}

This prevents token replay attacks even if the token is intercepted.

Audit Logging​

Every authenticated request generates an audit event:

{
  "timestamp": "2026-02-19T10:30:00Z",
  "agent_id": "agent-prod-01",
  "auth_method": "mtls",
  "cert_subject": "CN=agent-prod-01,O=AcmeCorp",
  "user_id": "user-123",  // From token exchange
  "tenant": "acme",
  "tool": "delete-user",
  "input": {"user_id": "12345"},
  "result": "success",
  "policy_decision": "allow"
}

These events flow to OpenSearch for compliance reporting and anomaly detection.

For the complete architecture, see the MCP Gateway Concepts documentation.

Best Practices for AI Agent Authentication​

Based on production deployments, here are the practices that matter:

1. Never Put Credentials in the Agent's Context​

# Bad: API key in system prompt
system_prompt = """
You are a customer service agent.
API Key: sk_live_abc123
"""

# Good: Credentials injected by the runtime
# Agent never sees the key, gateway handles authentication

2. Use Short-Lived Tokens​

OAuth2 tokens should expire within 1-24 hours. This limits the window of opportunity if a token is compromised.

3. Rotate Secrets Automatically​

For API keys and client secrets, implement automated rotation every 30-90 days. STOA integrates with Vault for this. See Secrets Management Guide.

4. Monitor Authentication Anomalies​

Track failed authentication attempts per agent. If an agent that normally authenticates once per hour suddenly attempts authentication 100 times in a minute, investigate immediately.

5. Implement Progressive Security​

Start with API keys in development, graduate to OAuth2 in staging, enforce mTLS in production. This reduces friction during development while ensuring production deployments meet security standards.

FAQ​

What is the difference between API keys and OAuth2 tokens for AI agents?​

API keys are static secrets with indefinite lifetimes, like passwords. OAuth2 tokens are short-lived (typically 1 hour), automatically expire, and include metadata (scopes, issuer, subject) that enable fine-grained authorization. For production AI agents, OAuth2 provides better security through automatic rotation, scope limitations, and audit trails. API keys are acceptable for development or low-security use cases.

How does mTLS prevent token theft?​

mTLS binds the access token to the client's certificate via the cnf (confirmation) claim in the JWT. Even if an attacker intercepts the token, they cannot use it without the client's private key. The gateway validates that the certificate presented during the API call matches the certificate hash in the token's cnf claim. This is specified in RFC 8705 (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens).

Can I use OAuth2 token exchange with Claude or GPT?​

Yes, but you need an MCP gateway to mediate the exchange. Claude and GPT do not natively support OAuth2 token exchange. The flow is: (1) User authenticates and receives a token, (2) MCP gateway exchanges the user token for an agent-scoped token on behalf of Claude/GPT, (3) Agent uses the new token to invoke MCP tools. STOA's gateway implements this pattern. See Consumer Onboarding Guide for implementation details.

Which authentication pattern should I use for AI agents in a regulated industry?​

For regulated industries (financial services, healthcare, defense) requiring compliance with standards like PCI-DSS, HIPAA, or FedRAMP, use mTLS with certificate-bound tokens (Pattern 4) or a composite pattern combining OAuth2 + mTLS (Pattern 5). These provide cryptographic proof of identity, defense against token theft, and audit trails that meet regulatory requirements. See DORA and NIS2 Compliance for EU-specific requirements.

Further Reading​

Ready to secure your AI agents? Try STOA's MCP Gateway or explore the security documentation.