Foundations
The intent–execution gap
Most authorization decisions assume that the software holding a token is carrying out what its user requested. That assumption generally holds for a web application with fixed code paths, but autonomous agents determine their execution at runtime, so intent and execution must be evaluated separately. Auth51 addresses that gap.
The assumption, stated plainly
OAuth 2.0 (RFC 6749) is a delegation framework. A resource owner approves a client, and the authorization server issues that client a token. Requests made with the token are then treated as actions the user authorized. The specification presumes that the client acts on the resource owner’s behalf, so the token represents the user’s intent.
This model worked well when “the client” was a program with fixed code paths. A billing application with the charge:card scope follows predefined logic for charging cards. Its intent and execution are linked by the code deployed with the application.
Why an agent breaks it
An LLM-driven agent changes that relationship. The user approves a goal such as “patch this dependency” or “reconcile these invoices,” while the agent determines which tools to call, in what order, whether to spawn sub-agents, and when to escalate. Its plan is generated at runtime from a prompt that can be edited, injected into, or replaced. The token still identifies the client acting for the user, but the client’s execution is no longer fixed in advance.
This introduces three structural problems:
There is no per-agent identity. An orchestrator, its sub-agents, and a prompt-injected impostor may all share one client_id. They are indistinguishable at the token layer, so the authorization system cannot tell which agent is calling or whether that agent was approved.
Intent and execution are separated. The granted scope covers the goal, but the token carries no evidence of the specific action occurring at a given moment. A hijacked plan can therefore use the same scope for an action the user did not anticipate.
Bearer tokens can be replayed. A standard OAuth bearer token (RFC 6750) can be used by whoever possesses it. If an agent leaks a token into a log, an attacker can exercise that token’s permissions until it expires or is revoked.
▶“Intent–execution separation,” precisely
The protocol work behind Auth51 calls this the intent–execution separation problem. In the non-agentic world, deterministic code naturally enforced a fixed workflow. The user’s intent and the client’s execution were therefore closely connected and did not need to be represented separately.
Autonomous agents allow the two to diverge at runtime. Intent therefore becomes a first-class, verifiable value in the token rather than an assumption about the client. The remaining Foundations pages explain the standards and mechanisms used to make that intent explicit. arXiv 2509.13597
Closing the gap
Closing the gap requires three capabilities that the base standards do not provide on their own: identifying which agent is acting and verifying that it has not changed; binding a token to one concrete action rather than a broad scope; and preventing a stolen token from being used by the party that copied it. The remaining Foundations pages cover the underlying standards, including token exchange, DPoP, and Zero-Trust. The Concepts section explains how Auth51 combines them.