OAuth Scopes vs Business Authority for AI Agents

8 minute read · Identity and security expert review required before publication

OAuth scopes control access to protected resources. Business authority controls the action an AI agent may take inside that access. An agent may hold orders:write and still lack authority to cancel this customer's fulfilled order, change this supplier's destination, or issue this refund without approval.

OAuth remains part of the architecture. The mistake is asking one scope string to carry identity, delegation, transaction policy and current business state. The broader design appears in the AI agent authorization guide.

Keep the boundary explicit

RFC 8707 lets clients identify the protected resource for which they request a token. RFC 9700 recommends audience-restricted and sender-constrained tokens where feasible. Apply those controls first. Then evaluate the domain request.

Translate a scope into a policy input

function authorizeRefund(ctx: RefundContext): Decision {
  denyUnless(ctx.token.audience === 'https://refunds.example', 'BAD_AUDIENCE');
  denyUnless(ctx.token.scopes.has('refunds:write'), 'SCOPE_MISSING');
  denyUnless(ctx.agent.status === 'active', 'AGENT_INACTIVE');
  denyUnless(ctx.grant.actions.has('refund.create'), 'ACTION_DENIED');
  denyUnless(ctx.grant.merchants.has(ctx.order.merchantId), 'MERCHANT_DENIED');
  denyUnless(ctx.refund.amountMinor <= ctx.grant.maxAmountMinor, 'AMOUNT_DENIED');
  denyUnless(ctx.order.refundableMinor >= ctx.refund.amountMinor, 'ORDER_STATE_DENIED');

  return ctx.approval.matches(ctx.refundDigest)
    ? { effect: 'allow' }
    : { effect: 'approval_required' };
}

Avoid encoding every domain attribute as a scope. A token with hundreds of values becomes hard to review and slow to revoke. Keep stable service access in the token and resolve fast-changing grants, policy and business state at the enforced boundary.

Handle token exchange carefully

Gateways often exchange an external token for an upstream token. Never forward the original token to an unintended server. Preserve the represented principal and actor as distinct claims, narrow the audience and scopes, and set a short expiry. A downstream service must validate its own audience rather than trusting that the gateway already did so.

For higher-risk environments, DPoP is one sender-constraining option. It reduces the utility of a stolen token by binding use to a key. It does not prevent a compromised authorized agent from asking for a harmful transaction within a broad scope.

Test both layers separately

Build an access test suite and an action-authority suite. A wrong issuer, expired token or wrong audience should fail before business policy. A valid token with a disallowed counterparty should reach policy and receive a stable domain denial. Include a direct-route test to confirm the protected service cannot be reached around the enforcement point.

The authentication versus authorization architecture maps the control owners. How to authorize an MCP tool call applies the same distinction to MCP. The live platform overview is the Intelliger product destination for evaluating enforcement patterns.

OATI is available as a developer preview with public schemas and verification examples. Treat production identity integration, token exchange and business-policy enforcement as system-specific work that needs independent review.

OAuth and authority design questions

Should every MCP tool receive its own scope?

Not necessarily. Scopes should be understandable access grants, not a mirror of every dynamic tool and record. A sensitive tool may deserve a distinct scope, while transaction details still belong in external policy. Excessive scope granularity creates consent and lifecycle problems; scopes that are too broad expose more service surface. Test the chosen scope set against real roles and use step-up only for access that a user can meaningfully understand.

Can token claims carry business limits?

They can carry stable, short-lived attributes, but rapidly changing budgets, supplier status and single-use counters are hard to keep current in a self-contained token. If a claim is used, define its issuer, freshness, units and conflict behavior. A policy service should reject disagreement rather than pick the more permissive source. Record the token identifier or digest and the external state versions used in the decision.

What does sender constraint add?

A sender-constrained token makes theft less useful by requiring proof from a bound key. It does not protect against the legitimate agent process being manipulated or compromised. The process can still present a valid proof for a harmful request. Apply sender constraint to credential security, then enforce request-bound business authority at the service that owns the action.

How should multi-tenant audiences work?

Audience identifies the protected resource, while tenant context identifies the organization whose records and policy apply. Bind both and partition authorization state. A valid resource token for tenant A must not become usable against tenant B because a caller changed a path or header. Include tenant in routing, cache, replay and idempotency keys, and test identical domain identifiers across tenants.

When is token introspection appropriate?

Introspection can provide current token status and central revocation, at the cost of latency and availability dependency. Locally validated tokens reduce that dependency but rely on expiry and distributed revocation policy. Choose per risk and operational model. Neither option removes the need to check current agent status, delegated authority and business state after token validation.

Review scopes with the teams that own the protected operations, not only the identity platform. A scope named payments:write may look appropriately narrow to an IAM administrator while covering several buyer entities, rails and destination changes. Document which service surface the scope opens, then list the transaction facts that remain outside it. That division becomes the policy contract and the negative-test plan.

Revisit that division when the API adds an operation. Expanding an existing endpoint under an old scope can create authority that no consent, grant or policy review considered. Treat new side effects as an access-model change.

Add one denial test for each new side effect before release. A valid legacy token should not inherit the new business action merely because routing still accepts its scope.