For years, the standard way to give software access to an external service was OAuth — the protocol that lets you click “Sign in with Google” without handing your password to a third-party app. It solved a real problem, and it held up well for the deterministic, browser-based world it was designed for. Agents are neither of those things.
The problem with coarse-grained access
OAuth scopes — the list of permissions an app requests — were built around the idea that you know, ahead of time, what an app needs. A calendar app needs `read:calendar`. A file editor needs `write:drive`. Those needs are known, stable, and narrow.
An AI agent’s needs are none of those things. It reasons, explores, retries, and improvises. At the moment it is granted access, neither the user nor the developer necessarily knows which actions it will take. Worse, the scopes that most services expose today are dangerously coarse. Salesforce’s API once had a single `api` scope — full access to everything, or nothing. Notion’s MCP server lets an agent call `get_page` but offers no way to restrict it to a specific database. The granularity that would make limited delegation safe simply does not exist in most systems yet.
The result is that agents today either get handed a master key, or they get hobbled into uselessness.
What the Resy incident shows
A personal AI agent was trying to book a restaurant reservation on behalf of its user. It made roughly 200 API calls per hour to Resy — well-intentioned, methodical, persistent. Resy’s rate-limiting system saw bot-like traffic and did the only thing it knew how to do: it banned the user’s account.
The agent had no signal that the resource was scarce or that its behaviour looked hostile from the outside. Standard rate limiting delivers one piece of feedback — a hard cutoff — and that comes too late, after the damage is done.
This is not a story about a bad agent. It is a story about a missing layer of infrastructure.
Intent as the missing primitive
What changes when authorization is built around intent — the reason behind a tool call, not just the action itself?
Consider two AI sessions running in the same product at the same time: one where a developer is debugging a production incident, one where a different user is browsing for a subscription upgrade. Both sessions might technically have access to the same APIs. But the authorization profile appropriate for each is completely different — different human-in-the-loop thresholds, different resource budgets, different blast radii.
Intent-based authorization (the model behind a specification called AAuth) formalizes this by threading two layers of context through every agent action:
– Operator intent: why the organization deployed this agent — what business outcome it is meant to serve.
– Session intent (a “mission”): what the user is trying to accomplish right now.
The authorization that applies at runtime is the intersection of both. The agent does not inherit a static blanket permission — it inherits a dynamic bounding box that reflects what it is actually for, at this moment.
Missions also carry another benefit: a mission identifier propagates through every downstream call, producing a clean audit trail. Security teams get a full forensic record of which agent did what, in the context of which task — something that today’s logs almost never provide.
Brains, hands, and the egress boundary
A second structural idea that holds up in practice is the separation of worker agents from supervising agents.
Worker agents execute — they call tools, write files, make API requests. Supervising agents set policy — they decide what the worker is allowed to do given the current mission and context. The critical constraint is that these two roles should be architecturally separate: the worker cannot set its own permissions, and the supervisor cannot do the work.
This separation makes policy externalized and auditable rather than baked into the model’s behavior in ways that are hard to inspect or override. Deterministic rules handle the clear cases (“never read another user’s email”). The supervisor handles ambiguous ones.
A related pattern is the egress proxy: the agent operates inside a sandbox with no direct API keys. All external calls go through a proxy sitting outside the sandbox — that is where authorization is actually enforced. Beyond the obvious security benefit (agents cannot find stray credentials on disk), this enables dynamic tool management: web-egress tools can be disabled while a sensitive write is in progress, reducing both risk and context noise.
Why constraints make agents better
There is an empirical observation worth sitting with: tighter agent constraints do not just reduce risk — they improve decision quality. When an agent has fewer available actions, it spends less of its budget exploring wrong paths. The authorization layer and the quality layer turn out to be the same layer.
The longer-term question is whether intent-based identity protocols will be standardized in the open or locked down by large platform players. The web got where it is because identity and access protocols (TLS, OIDC) were federated and open. Agents navigating the web are about to put the same question on the table again — and the answer will shape whether the next generation of AI systems is a few walled gardens or something genuinely distributed.
Text summarized and optimized using Anthropic’s models and reviewed by a human.