Skip to content
The AI-First Web Talking point

OAuth's coarse scopes were built for websites, not for agents that improvise

OAuth co-creator Dick Hardt says the web's permission layer was not designed for software that decides as it goes.

W
WebPulse Newsroom
AI-assisted · 2 min read
Share on X LinkedIn
OAuth's coarse scopes were built for websites, not for agents that improvise
In brief
  • OAuth co-creator Dick Hardt said the standard was built to let one website talk to another, so its scopes are far too coarse for agents.
  • Our reading: a broad scope widens what a looping agent can touch, so buyers should ask what narrow permissions a tool offers, though narrow permissions alone are not enough.

Dick Hardt, co-creator of OAuth, argued that the standard now used to authorize AI agents was built for a different job. OAuth lets one website get limited access to another. Hardt made his case on the AI Engineer podcast, on a panel with Keycard's Ian Livingstone and JPMorgan Chase's Michael Davis.

What was said

Hardt said that when people asked how to authorize agents, OAuth was the tool on the shelf, so they grabbed it. "But OAuth was not designed for this kind of world."

It began as a way to let one website talk to another, he said. Scopes, which are labels for what an app may do, came later in OAuth 2. It also expects apps to register in advance.

Agents differ, Hardt said. Nobody knows ahead of time what an agent will need, and different instances need different things. Reusing existing scopes is far too coarse.

Livingstone said Salesforce, for a very long time, offered one OAuth scope called API. For an agent, he called that not very helpful.

A speaker on the show used a payment to make a further point. Paying is not a scope, the speaker said. It is one action in one context. Even a correctly scoped payment needs more around it: why it is being made, what happened before, and whether the same payment just went out five seconds earlier. That speaker tied this to the wider mission the agent is meant to accomplish.

Why it matters

Our reading: the old permission model assumed a predictable caller. Livingstone described agents as systems that reason and try over and over. Hardt imagined an agent saying it will "keep trying until I win." An agent that keeps trying can reach anything the token allows, so a broad scope widens what a failed or looping attempt can touch.

Compare two tokens. One says API. The other allows one payment. The narrow token is a necessary starting point, not a complete check. As the speaker argued, the system also needs history and the overall mission to judge each decision.

Davis said successful enterprises onboard agents like developers, without full commit access on day one. He added, "When you have less things the agent can do, it makes better decisions."

Buyers can ask four questions. Does the tool offer more than one permission? Can access be limited to a single action? Can capability grow in stages? Is there a record of what the agent did?

The other side

The excerpts we reviewed describe proposals, not a settled standard. A speaker conceded that intent, the reason an agent is acting, is hard to define. A speaker also described a mission concept, meaning the big-picture goal each decision is judged against. The transcript is unclear on where that work sits, and the episode title names Hardt's AAuth, so it may be separate from OAuth.

Livingstone's Salesforce point described the past. The excerpts do not say what Salesforce offers now. A speaker later asked whether new standards will favor large players. The excerpts we reviewed do not show an answer. Banks moved long ago to authorizing each transaction, so finer control is an old idea.

Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.

The conversation this talking point comes from

Share this insight