The problem that gave rise to OAuth was prosaic and alarming. By the mid-2000s, if you wanted a third-party application to access your data on another service, you gave it your password. The photo-printing service that needed your pictures got your full credentials. It could read your messages, change your settings, impersonate you entirely. There was no way to say "access my photos, nothing else, for the next hour."
RFC 6749, published in 2012, lists the consequences of the old model with unusual directness: third parties store user credentials in plaintext, servers must support password authentication despite its known weaknesses, users cannot revoke access to one application without changing their password for all of them. OAuth's answer was to separate the client from the resource owner and issue a different kind of credential. An access token with a specific scope, lifetime, and set of permissions.
This was a parallel architecture built around delegation, something cookies had never needed to express. A cookie tells a server "this browser has been here before." An access token carries different cargo: which application is making the request, on whose behalf, with what permissions, and for how long.
The vocabulary kept growing more precise. RFC 8693, published in 2020, defined OAuth 2.0 Token Exchange with explicit fields for delegation chains. A subject_token identifies the person on whose behalf a request is made. An actor_token identifies who is actually doing the acting. An act claim names the current actor and can nest to represent chains of delegation. The spec also includes audience restriction and expires_in, so a token can name its intended recipient and give authority a defined shelf life. Who asked, who's acting, what they're allowed to do, for whom, and until when. This grammar has been available for over six years.
And yet the public documentation from major agent platforms doesn't describe systems routinely issuing tokens with act claims that identify an AI agent as the delegated actor. What those docs describe is interaction mechanics: screenshot-based navigation, mouse and keyboard control in sandboxed environments. None define a mechanism by which the agent's requests carry identity distinct from the browser session it operates within.
Some pieces are moving. The MCP authorization specification requires servers to validate that tokens were issued for them as the intended audience and forbids passing through received tokens to upstream services. These are audience-restriction and token-separation principles drawn from the same well as RFC 8693. But they govern the agent-to-tool channel, not the agent-to-open-web channel where most browser-based work happens.
The web ended up with two identity architectures, one ambient and one explicit. For most of the web's history, the difference between them mattered mainly to protocol designers and security engineers. Agents have made it operational. The entity driving the session may no longer be the entity whose authority it carries. The grammar for expressing that relationship already exists, defined in a six-year-old RFC that agent platforms have largely left on the shelf.