AI agents act for people, choose their own actions at runtime, and read content that may be hostile. This post sets out the problem, the three layers needed to handle it, and a reference architecture built on standards that exist today.

An agent needs an identity of its own, separate from the user it works for. Without one, every call it makes looks like the user made it, and you cannot revoke, rate-limit or audit the agent without doing the same to the person. This part covers how an agent gets that identity, as an OAuth client …

Part 2 gave the agent an identity. This part is about what happens when that agent acts for someone, and when the work passes through more services than the one the user consented to. The core tool is OAuth 2.0 Token Exchange (RFC 8693). Two OAuth working-group drafts extend it: one inside a trust …

This part walks through the MCP authorization specification, revision 2026-07-28, as an implementer would meet it: what to discover, how to register, how to get a token, and what the server must check. Every requirement here comes from the spec or from the RFCs it cites.

Part 4 ended where the MCP spec ends: the token is valid for this server. This part covers the question that comes next on every request. May this agent, for this user, call this tool with these arguments, right now? The standard for asking it is the OpenID AuthZEN Authorization API 1.0, Final since …

Agents act while the user is somewhere else. Sooner or later a decision needs a person: to grant access in the first place, to prove it is really them, to approve something they cannot approve alone, or to confirm one specific action. This part maps each of those moments to the standard that handles …