Anthropic and OpenAI put six agent authorization problems before the OAuth Working Group

A standard OAuth diagram has four parties: a client, a user, an authorization server and a protected resource ^[18]. According to the dev.to post, general-purpose agents multiply every one of them ^[18]. A single product can run as many local and hosted installations ^[16]. Each installation can expose desktop, browser, IDE, terminal and chat surfaces, and one user can create several agents ^[16]. The same agent can act for a user during one task and as a workload during the next ^[16].

The post's data model is built to stop one column from being asked to mean five things. Its AuthorizationContext type exists to stop client_id, sub or a token record from becoming the catch-all identifier for product, installation, user, agent and target service ^[7]. The type has eight fields: tenantId, userPrincipalId, agentPrincipalId, clientClassId, clientInstanceId, issuer, resource and grantId ^[2]. Both principal fields are optional ^[7]. One shape can therefore describe a user-delegated grant, an agent running as a workload, or an agent acting for a user. None of the eight fields holds a token ^[2]. The author calls it an application data model and says it is not an OAuth proposal ^[7].

I think this is the piece to build now, and the joint deck gives the reason. It splits client registration, principal identity, refresh behavior, agent provisioning and cross-provider scopes into separate problem areas ^[15]. If the working group settles those one at a time, a schema that already stores issuer, client instance and grant apart can take each answer as a local change. A table keyed on client_id would need migrating first. The post puts it more bluntly: no single token field can carry all of those areas safely ^[15].

Registration is where the record count turns into operating cost. Dynamic Client Registration lets software submit metadata and receive a client identifier, and DCR Management defines read, update and delete ^[9]. If every local installation, hosted workspace or product surface registers on its own, the provider accumulates many client records ^[10]. Cleanup depends on management support, retained registration credentials and reliable lifecycle events ^[10]. A client that loses its management credential may be unable to update or delete its record ^[10]. The post's order is an existing registration first, Client ID Metadata Documents where supported, and DCR as a managed fallback ^[8]. CIMD uses an HTTPS URL as the client identifier ^[19].

Two smaller rules in the post apply today. Persisted credentials are bound to the authorization-server issuer, and a mismatch is rejected before any credential is transmitted ^[13]. OAuth scope strings do not form a shared permission vocabulary, so each agent task is compiled into provider-specific permission requests ^[12]. Permissions are elevated progressively ^[17].

The evidence does not show OAuth failing agents. The post says OAuth "still provides the practical base for delegated API access" and places the strain in operating burden from more identities, client instances, providers and token lifecycles ^[4]. Its case for acting now is the author's argument that integration platforms do not need to wait for a new standard ^[20]. It treats proposed workload grants as replaceable inputs to a policy layer ^[14]. Those grants are still evolving and do not replace user-delegated authorization, according to the post ^[14].