There's some active discussions on task level authz and multi-hop delegation in the OAuth WG right now. WorkOS wrote a good overview of the open drafts [1]. (Disclosure: one of them is mine.) [1] https://workos.com/blog/oauth-multi-hop-delegation-ai-agents

I skimmed that. It seems to me:

(a) A major problem where one agent can give dangerous instructions to another.

(b) A desire for an “agent” to cleanly delegate permissions to another “agent”. I am extremely unclear as to what an “agent” is in this context. Is one’s OpenAI or Anthropic account an “agent”? How is (b) related to (a)?

(c) An observation that existing OAuth + JWT can’t really do (b) and that a new spec could allow delegation.

ISTM:

- (a)’s root cause is a complete lack of control on the portions of a repository that are interpreted by various tools in a trusted/privileged manner.

- (b) could be addressed by a capability or proxy system.

- Most services that offer OAuth or other types of API keys have absurdly coarse-grained permissions. GitHub’s OAuth cannot obviously even restrict to a particular organization, let alone a repository, and good luck blocking commits to .github. Cloudflare can’t restrict DNS operations to a particular host. A shocking number of major services have no concept of non-human accounts. The list goes on. Delegation is of dubious value in this setting.

- Why would one ever want to give a bearer token to an “agent”?

- Wouldn’t a proxy serve this purpose more flexibly and more universally?

I agree with the coarse permissions point, and I wouldn't bank on those services adding finer-grained scopes.

The idea in my draft is to do the attenuation and verification before the call reaches the service, enforced at the boundary, like the proxy setup you're describing. And the token wouldn't be a bearer token per se; there's proof of possession, and the constraints narrow at each hop and travel with the token, so the boundary can verify the chain itself rather than rely on a central authority. The design is inspired by macaroons and other capability-based access control work.

Full draft's here if you want to pick it apart: https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenu...