Skip to content
EkLine
Book a demo

Blog

OAuth for AI Agents: Why General-Purpose Agents Strain the Integration Model

General-purpose AI agents turn OAuth into a multi-identity, multi-provider state problem. Here is what integration platforms should change.

Cover Image for OAuth for AI Agents: Why General-Purpose Agents Strain the Integration Model
Published on
Read time
12 min

OAuth still provides the practical base for delegated API access. General-purpose agents make it harder to operate because a single task can involve several identities, client instances, providers, resources, grants, and token lifecycles.

A user might ask one agent to read a GitHub pull request, check a Jira issue, and post a summary to Slack. The agent may run in a desktop app today and a hosted workspace tomorrow. Each provider has its own registration rules, scopes, consent model, token behavior, and administrative limits.

The OAuth Working Group discussed these problems on September 28, 2026 through a joint Anthropic and OpenAI problem statement. The session covered runtime client registration, refresh-token feedback, user and agent identity, high-cardinality client instances, just-in-time provisioning, and permissions across providers. It presented a problem statement rather than an adopted standards solution.

Integration platforms do not need to wait for a new standard before improving their architecture. They should separate user, agent, client, issuer, resource, grant, and token state; make registration capability-driven; bind credentials to issuers; elevate permissions progressively; and make reauthorization a recoverable workflow state.

TL;DR

OAuth still works. The operating model expanded

A familiar OAuth diagram has a client, a user, an authorization server, and a protected resource. General-purpose agents multiply every part of that picture.

One software product can have many local and hosted installations. One installation can expose desktop, browser, IDE, terminal, and chat surfaces. One user can create several agents. An agent can act for a user during one task and as a workload during another. A single assignment can cross several authorization servers and protected resources.

The joint interoperability deck separates client registration, principal identity, refresh behavior, agent provisioning, and cross-provider scopes into different problem areas. That separation is useful because no single token field can carry all of them safely.

A practical application model needs at least this context:

TypeScript
type AuthorizationContext = {
  tenantId: string;
  userPrincipalId?: string;
  agentPrincipalId?: string;
  clientClassId: string;
  clientInstanceId: string;
  issuer: string;
  resource: string;
  grantId: string;
};

This is an application data model, not an OAuth proposal. Its job is to stop client_id, sub, or a token record from becoming a catch-all identifier for the product, installation, user, agent, and target service.

Runtime registration creates lifecycle work

A general-purpose agent often discovers a service only after the user asks it to connect. The platform may not have a pre-registered client at that provider.

OAuth Dynamic Client Registration lets software submit metadata and receive a client identifier. OAuth Dynamic Client Registration Management defines operations for reading, updating, and deleting that registration.

The protocols solve a registration exchange. They do not remove the operational cost of high cardinality. If every local installation, hosted workspace, or product surface registers independently, the provider accumulates many client records. Cleanup depends on management support, retained registration credentials, and reliable lifecycle events. A client that loses its management credential may be unable to update or delete its record.

Client ID Metadata Documents, or CIMD, use an HTTPS URL as the client identifier. The authorization server retrieves the metadata from that URL instead of requiring a stored registration for every server-client pair. CIMD is an OAuth Working Group Internet-Draft, so its behavior and adoption can still change.

MCP's July 2026 authorization specification uses a decision order: pre-registration first, CIMD when the authorization server advertises support, and Dynamic Client Registration as a fallback. MCP deprecates DCR for new MCP implementations. That is an MCP-specific direction, not a general OAuth deprecation.

An integration platform should record how every client was created, who owns the registration, whether it can be updated or deleted, and what cleanup follows when an installation or tenant disappears.

A useful decision path is:

  1. Use a provider-specific registration when one already exists.
  2. Use CIMD when the authorization server advertises support and the client can host stable HTTPS metadata.
  3. Use DCR when the provider supports it and the platform can retain registration-management state.
  4. Route unsupported cases to administrator or provider onboarding.

Keep the user, agent, and client separate

When a JWT access token or token-introspection response carries delegation semantics, its top-level claims can identify the user as the subject; OAuth access tokens do not universally expose a sub claim. OAuth Token Exchange defines act for JWT claims sets and introspection responses. For access-control policy, consumers must consider the token's top-level claims and current actor; nested prior actors are informational only.

That gives implementations useful vocabulary. It does not define a complete identity model for agents, installations, tenants, and product surfaces. The September 28 deck explicitly asks whether sub and act are sufficient and how an authorization server should recognize an agent created just in time.

Keep four concepts separate:

  • The user principal is the person or account whose data and authority are involved.
  • The agent principal is the durable agent or workload performing the action.
  • The client class is the software product requesting authorization.
  • The client instance is one installation or runtime of that product.

Store those records together in audit events even when an upstream token exposes only part of the context. A useful evidence chain links the user grant, agent execution, client instance, issuer, target resource, and resulting API call.

Refresh tokens are part of workflow design

An agent may begin work while the user is present and continue after the browser closes. That makes refresh capability part of the product behavior, not a storage detail.

OAuth permits an authorization server to issue a refresh token, but issuance is optional. The server can narrow the granted scope and reject later refresh requests. Current OAuth security guidance calls for refresh-token rotation or sender-constrained refresh tokens for public clients, and it allows revocation after events such as logout or password change.

The interoperability deck describes the product failure this creates: an agent can ask for offline access and complete interactive authorization without knowing whether it received a grant that can support the planned background task.

Treat refreshability as observed state. Store whether a refresh token was issued, its issuer, resource, grant, rotation state, last successful use, and the provider error that ended the lease.

Return a recoverable result to the task engine:

JSON
{
  "authorization_state": "reauthorization_required",
  "reason": "refresh_token_expired",
  "resume_token": "task_7f3...",
  "required_resource": "https://api.example.com/"
}

The runtime can pause at an idempotent checkpoint, ask the user to return, and resume after consent. Repeated blind refresh attempts create poor incident evidence and can trigger provider lockouts.

Provider scopes do not compose into one permission model

OAuth scope values are defined by each authorization server. Their order has no meaning, and the server can grant a different set from the one requested.

Resource Indicators add a resource parameter so the client can identify the intended protected resource, enabling the authorization server to audience-restrict the token. RFC 8707 recommends that restriction but does not guarantee every returned token will be audience-restricted. That improves the token boundary. It does not make a GitHub permission equivalent to a Slack, Notion, or Jira permission.

Compile each assignment into separate provider grants:

Text
Task: prepare a release update
  Git provider: read repository and pull request
  Issue tracker: read issue and add comment
  Chat provider: post to one channel

Each line should map to one issuer, one protected resource, one provider-specific scope set, and one consent event.

Progressive authorization is safer than requesting every permission the agent may need later. Start with the current operation. If the protected resource returns an insufficient-scope challenge, merge the new requirement with the scopes already granted before asking for authorization again. MCP documents this approach and warns clients to preserve previous scopes during elevation.

Bind persisted credentials to the issuer

Authorization-server discovery can change which server handles a protected resource. A credential store becomes dangerous when it retrieves tokens or client data by resource URL alone and later sends them to a different issuer.

The MCP specification requires persisted pre-registered or DCR client credentials to be associated with and keyed by the authorization-server issuer.

On September 28, 2026, the MCP TypeScript SDK v1.31.0 shipped related, broader storage changes that also issuer-bind token records.

Stored token and client records accept an issuer, constructors without expectedIssuer are deprecated, and token retrieval rejects mismatched issuer context before credentials are transmitted.

Credential flow that resolves an authorization-server issuer, retrieves only issuer-bound credentials, and stops before sending on a mismatch. (opens the full-size image in a new tab)
Resolve the issuer first, then retrieve credentials from that issuer's partition.

A credential key may look like this:

Text
(tenant, issuer, resource, user principal, agent principal, client instance)

The exact schema will vary. The invariant matters more: discovery identifies the issuer, and the store refuses to return credentials outside that issuer boundary.

Issuer binding closes one credential-confusion path. Resource audience validation, sender constraints, secure storage, and authorization checks remain separate controls.

Just-in-time agents need a policy boundary

Registering every ephemeral agent as an OAuth client creates a large registration population. Using one platform identity for every hosted agent removes attribution and makes suspension too coarse.

The Workload Authorization Grant draft proposes a model for agents acting on their own behalf. An administrator establishes trust in a platform issuer. The platform signs a grant for a specific agent identifier. The authorization server verifies the issuer and applies local policy before issuing a token.

The draft is an individual Internet-Draft with no formal IETF standing. Access on behalf of a user is out of scope, although the grant is intended to compose with delegation mechanisms in which the workload is the actor. It also says authorization servers must not issue refresh tokens for this grant, assertions should be short-lived, and access tokens should not significantly outlive them. Treat it as architecture input, not a production interoperability baseline.

Agent platforms can prepare by placing workload verification behind a replaceable interface:

TypeScript
interface WorkloadGrantVerifier {
  verify(assertion: string): Promise<{
    platformIssuer: string;
    agentId: string;
    properties: Record<string, unknown>;
  }>;
}

The policy layer should decide which platform issuers are trusted, how tenant boundaries work, whether an unseen agent may be provisioned, which permissions its properties imply, and how the agent is suspended or deleted. The grant format can change without forcing a rewrite of the local identity and policy model.

What integration platforms should change now

The September 28 session did not publish a selected grant or agent identity model. Teams can still remove much of the operational risk now.

  1. Store user, agent, client class, and client instance as separate identities.
  2. Validate issuer and protected resource independently.
  3. Make client registration capability-driven and retain its management lifecycle.
  4. Partition credential storage by issuer and resource.
  5. Track refresh issuance, rotation, failure, and reauthorization as explicit states.
  6. Compile tasks into provider-specific permissions and elevate scopes only when required.
  7. Preserve full authorization context in every audit event.
  8. Make workflows resumable after consent, credential rotation, or token expiry.
  9. Keep emerging workload grants behind a policy interface.

For every agent API call, the platform should be able to answer seven questions: who authorized it, which agent performed it, which client instance obtained the grant, which issuer created the credential, which resource accepted it, which permissions applied, and what event will end or renew that authority.

If those answers live in one overloaded token record, the integration model will keep getting harder as the agent surface grows.

Frequently asked questions

General-purpose agents combine many client instances, users, agent identities, authorization servers, protected resources, scope systems, and token lifecycles. OAuth supplies useful primitives, but the integration platform must model and operate those layers separately.

No. OAuth remains the practical base for delegated API access. Agent platforms should improve their identity, registration, credential, scope, refresh, and audit models around it.

Credential records should remain bound to the validated authorization-server issuer and target resource, along with the tenant, user or workload, agent, client instance, grant, and scope context needed for authorization and audit.

No common scope vocabulary makes permissions equivalent across providers. Platforms should compile each task into provider-specific grants and request the smallest scope set required for the next operation.

No. The September 28, 2026 interim session documented practical interoperability problems and discussed possible directions. It did not publish or adopt a standards solution.

No. OAuth remains useful for delegated API access. General-purpose agents expose operational gaps around identity cardinality, runtime registration, provider-specific scopes, background refresh, and audit context.

Usually not. Client registration identifies software, while an agent may need its own workload identity and policy record. Per-agent registration can create cleanup, quota, and administration problems. Keep those identity layers separate.

A Client ID Metadata Document lets a client use an HTTPS URL as its client identifier. The authorization server retrieves the client's metadata from that URL. CIMD remains an OAuth Working Group Internet-Draft.

Issuer binding prevents credentials learned or stored for one authorization server from being returned and sent under another authorization-server context. The control should run before any credential is transmitted.

Pause the workflow at an idempotent checkpoint, record why reauthorization is required, return the user to consent, and resume with a new grant. Do not hide the failure inside an endless refresh loop.

Sources

Read more about
Blog

Cover Image for Gemini 4 Argon: What It Does and Where It Falls Short
Blog

Gemini 4 Argon: What It Does and Where It Falls Short

·15 min read

Google's Gemini 4 Argon leads its own benchmark table but trails on terminal agents and independent scoring, and you cannot call it yet. What it does, where it falls short, and which workloads to queue.

Cover Image for A2A Production Readiness: What It Takes Beyond Protocol Support
Blog

A2A Production Readiness: What It Takes Beyond Protocol Support

·12 min read

A2A standardizes agent communication. Production systems still need durable tasks, retry safety, authorization, recovery, and real interoperability tests.

Cover Image for What Is WebMCP? When to Expose Browser Tools to AI Agents
Blog

What Is WebMCP? When to Expose Browser Tools to AI Agents

·12 min read

WebMCP lets a web app expose structured actions to browser agents. This guide compares it with browser automation and MCP servers.

Cover Image for When to Hire a Technical Writer, When to Automate, and How They Work Together
Blog

When to Hire a Technical Writer, When to Automate, and How They Work Together

·11 min read

Decide whether your documentation problem needs a technical writer, automation around an existing owner, or both.

Cover Image for Material for MkDocs Is in Maintenance Mode: What It Means for Your Docs
Blog

Material for MkDocs Is in Maintenance Mode: What It Means for Your Docs

·12 min read

A practical decision guide for staying on Material for MkDocs, testing Zensical, or moving to another documentation stack after maintenance mode.

Cover Image for AI Knowledge Base Software for Customer-Facing Docs
Blog

AI Knowledge Base Software for Customer-Facing Docs

·14 min read

Learn how to evaluate AI knowledge base software that finds missing answers, fixes stale customer-facing docs, preserves review control, and serves current product knowledge to AI tools.

See what EkLine finds in your docs.

Book a demo

15 minutes to set up. 15 insights of what agents read about you, and 15 days to improve. If you do not see the value, you walk away with 15 better pages.