How do I secure APIs for AI agents?

This is a genuinely different threat model from traditional API security, and current 2026 guidance treats it that way. Here's the rundown:

Why AI agents break the traditional model

• OAuth 2.0 was designed around a human clicking "allow" once, for a session, for a scope the human explicitly consented to. Agents make dozens of autonomous calls across multiple services on behalf of a user who engaged minutes ago — most authorization models weren't designed with that caller in mind.
• Agents reason dynamically rather than following deterministic code paths, so you have to assume an agent can do anything within its granted permissions — design controls around the entitlement boundary, not around expected behavior.
• The numbers are sobering: one 2026 audit found 40% of MCP servers still require no authentication at all, 43% carry command-injection vulnerabilities, and 79% handle credentials in plaintext.

Core authentication/authorization practices

• OAuth 2.1, not 2.0 — mandatory PKCE, no implicit flow, exact redirect URI matching, no password grant. MCP itself is built on OAuth, so if you're exposing an MCP server you're already required to work within this model.
• Validate the audience claim on every request — every token should specify which service it's intended for; reject any token whose aud doesn't match. This matters specifically in agentic chains where tokens pass between AI application → MCP client → MCP server → gateway → downstream API, and a token minted for one hop being reused at another is a real risk.
• Never pass a client token straight through to a downstream API unchanged. The token issued to the MCP client was scoped for that connection, not for whatever the API ultimately does — passthrough either over-scopes the downstream call or fails because it's under-scoped.
• Use OAuth token exchange (RFC 8693) between agents in a chain — each hop should exchange its token for a new, more narrowly-scoped one before calling the next service, rather than everyone inheriting the same broad token issued at the top of the chain. This is how you preserve least-privilege across a multi-agent pipeline instead of losing it after step one.
• Scope tightly and specifically — coarse scopes like transactions:history (read-only) rather than broad admin-equivalent access; the agent should get exactly what its current task requires, nothing "just in case."

Credential handling

• The agent (the LLM) should never directly hold raw API credentials. Route calls through a tool layer that injects credentials server-side — the agent calls a scoped action/tool, and the actual bearer token or key is attached behind the scenes, never exposed to the model's context.
• Centralize credential storage, log all access, and automate rotation — don't let credentials live in scattered config files or get manually rotated (or not rotated at all).
• Distinguish per-user auth (agent acts within one user's actual permissions, e.g., their calendar) from service-account auth (agent acts as itself with fixed scopes) — pick deliberately per use case rather than defaulting to broad service-account access because it's easier.

MCP-specific hardening

• MCP's built-in authorization only secures the MCP client-to-server connection — it does not automatically secure what happens between the MCP server and the actual backend API it calls. Your API still needs its own OAuth enforcement independent of MCP's layer.
• Allow-list and validate every tool input server-side — don't trust that the model will only send well-formed arguments; treat tool inputs the same as any untrusted user input (injection, path traversal, SSRF are the documented top attack classes). Block SSRF egress to private IP ranges from any server-side fetch a tool can trigger.

Require human-in-the-loop confirmation for sensitive or irreversible actions (deletions, payments, permission changes) rather than letting the agent execute them autonomously.

• Architectural pattern: the MCP/Agent gateway

Route all agent traffic through a centralized gateway (an emerging pattern, with CNCF work underway on a dedicated "Agent Gateway" concept) rather than letting each team's MCP server implement its own auth from scratch.

• The gateway becomes the single enforcement point for authentication, per-request authorization, rate limiting (to stop runaway agent loops), input validation, and audit logging — decoupling security logic from individual application code so a central platform team can enforce policy without slowing every dev team down.
• A gateway is not a silver bullet on its own — it needs to be paired with the token-exchange and scoping practices above, not treated as a replacement for them.

Practical baseline stack

• OAuth 2.1 with PKCE as the foundation — if your APIs aren't on OAuth today, treat that migration as the top priority. Audience validation on every token, every hop.

Token exchange (not passthrough) at every agent-to-agent or agent-to-API boundary in a chain.

Credentials injected server-side by a tool layer, never exposed to the agent/model directly.

Centralized MCP/agent gateway for auth enforcement, rate limiting, input validation, and audit trails.

Human confirmation gates for high-privilege or irreversible actions.

• Least-privilege, task-scoped tokens issued per-agent, per-step — not one broad token for the whole session.

• The throughline: treat the agent as a non-human identity in a zero-trust model — authenticated and authorized explicitly for every request, scoped to the narrowest task-relevant permission, never trusted just because it's "inside" your system.