AI Agent Authorization: From Identity to Request-Bound Authority

15 minute read · Reviewed 11 August 2026 · Security expert review required before publication

AI agent authorization is the process of deciding whether a verified agent may perform one exact action for an accountable principal under current constraints. A sound design binds the decision to the request, resource, purpose, destination, budget, time, policy version and delegated authority. Authentication and broad API scopes are inputs to that decision. They are not the decision itself.

This guide is for security architects and platform engineers who need to place agents behind a shared enterprise control boundary. By the end, you should be able to define the authorization context, implement a deterministic decision point, recover safely from stale or uncertain state and test that delegated authority cannot expand.

What AI agent authorization must establish

An authorization service needs enough evidence to answer five questions for every protected request:

1. Which agent is presenting the request, and which organization is accountable for it?
2. Which principal delegated this action, and is that delegation active and revocable?
3. Does the exact request fit the permitted action, resource, counterparty, purpose, destination and limits?
4. Which policy and approval state apply at decision time?
5. Can another verifier reconstruct the decision and observed result later?

Identity answers only the first question. A valid access token can identify a client and carry scopes, yet a scope such as payments:write rarely captures an invoice digest, supplier destination, one-time budget or human approval. The OAuth 2.0 Security Best Current Practice recommends audience restriction, sender-constrained tokens and minimum necessary privilege. It also requires resource servers to verify that a token applies to the requested action and resource. RFC 9700 provides the transport security baseline. Enterprise agents still need a transaction-aware authority layer above that baseline.

Definitions and boundaries

Authorization does not make model reasoning deterministic. It limits which proposed actions may cross the enterprise boundary. The model may interpret a ticket, prepare parameters or explain a denial. Deterministic code verifies signatures, evaluates constraints, reserves usage and releases execution credentials.

Human approval is also narrower than authority. An approval should bind one reviewed request. A vague approval such as "handle this supplier" should not become a reusable capability to change payment details or amounts.

AI agent authorization architecture

Place the policy enforcement point between the agent runtime and every consequential tool or API. The following text diagram shows the minimum flow:

agent proposal
  -> gateway normalizes request
  -> identity and issuer verification
  -> mandate and revocation resolution
  -> deterministic policy evaluation
  -> approval check when required
  -> atomic usage reservation
  -> short-lived execution capability
  -> protected system
  -> signed decision and outcome evidence

The gateway owns protocol interception and request normalization. The identity resolver verifies the issuer chain, current key and agent status. The authority service resolves a short-lived mandate and proves that any child delegation is equal to or narrower than its parent. The policy engine evaluates the normalized request. A credential broker obtains an opaque, destination-bound capability only after the decision is allowed. The protected system remains authoritative for the business result.

This structure works with REST, gRPC, MCP or an internal job queue because the internal authorization object is protocol neutral. The adapter translates a protocol request into that object and translates the structured decision back.

Build a request-bound authorization context

Do not ask the policy engine to interpret prose. Normalize the request into a versioned type and reject unknown fields before evaluation.

type AuthorizationContext = {
  version: 1;
  transactionId: string;
  agent: {
    id: string;
    organizationId: string;
    passportDigest: string;
    proofKeyId: string;
  };
  mandate: {
    id: string;
    digest: string;
    parentDigest?: string;
  };
  request: {
    action: string;
    resource: string;
    counterparty?: string;
    purpose: string;
    destination: string;
    amountMinor?: number;
    currency?: string;
    bodyDigest: string;
  };
  control: {
    audience: string;
    policyDigest: string;
    approvalDigest?: string;
    idempotencyKey: string;
    issuedAt: string;
    expiresAt: string;
  };
};

This is illustrative TypeScript, not an OATI library type. Use integer minor units for monetary limits, version the normalization rules and compute bodyDigest over a canonical representation. If two adapters can normalize the same request differently, an approval produced through one adapter might authorize another payload.

OAuth resource indicators help bind a token to its intended server. RFC 8707 defines the resource parameter, and the MCP authorization specification requires MCP clients to send it and MCP servers to validate that a token was issued for them. MCP also forbids passing the client's token through to an upstream API. MCP authorization therefore protects an important boundary. The enterprise decision still needs the tool arguments, business purpose and delegated limits.

Express authority as data

A mandate should state what the agent may attempt and when that authority ends. Keep it short lived and make delegation explicit.

{
  "mandate_id": "mandate:finance:ap-442",
  "subject": "agent:finance:ap-worker-3",
  "organization": "org:buyer:eu-1",
  "purpose": "settle-approved-supplier-invoice",
  "actions": ["supplier-payment.create"],
  "resources": ["invoice:INV-8841"],
  "counterparties": ["supplier:northwind"],
  "destinations": ["bank-destination:northwind:primary"],
  "limits": {
    "currency": "EUR",
    "max_amount_minor": 2500000,
    "max_uses": 1
  },
  "delegation": { "allowed": false },
  "expires_at": "2026-08-11T17:00:00Z"
}

This example is conceptual rather than a verbatim OATI schema object. Every constraint must have a defined comparison rule. Missing child constraints cannot mean unlimited authority. For a parent and child mandate, prove set inclusion for actions, resources, counterparties and destinations, then prove that numerical ceilings, expiry and delegation depth are no broader.

Evaluate in a fixed order

Evaluation order affects both security and incident diagnosis. Reject malformed or untrusted material before making business calls:

1. Validate object schemas and supported versions.
2. Resolve the issuer chain to an accepted trust anchor.
3. Verify the signing key, validity interval and current status.
4. Check Passport and mandate revocation.
5. Recreate the canonical signing payload and verify proof of possession.
6. Check activation, expiry, clock skew and expected audience.
7. Claim the transaction identifier in a replay store.
8. Prove child authority is a subset of parent authority.
9. Evaluate action, resource, counterparty, purpose, destination and limits.
10. Reserve one-time usage or budget atomically.
11. Check an exact approval digest when policy requires approval.
12. Issue a destination-bound execution capability.

The replay claim and usage reservation need durable, atomic semantics. Two concurrent requests must not both consume a one-use mandate. If the policy service crashes after reservation but before dispatch, recovery should inspect the transaction state rather than release authority immediately.

Cache design needs the same care. A gateway may cache issuer records, keys, mandates and policy bundles to keep local enforcement available, but every cached object needs a version, expiry and invalidation rule. Revocation should invalidate the relevant entry or move the gateway to a bounded stale state defined by policy. Material writes should fail closed when the gateway cannot establish current trust or replay state. A low-risk read may use an explicit fail-open rule, provided the rule names the resource, maximum staleness and evidence emitted. An undocumented fallback from current authorization to cached broad access is a policy bypass.

type Decision =
  | { result: 'allow'; reservationId: string; contextDigest: string }
  | { result: 'approval_required'; reason: string; contextDigest: string }
  | { result: 'deny'; reason: string; contextDigest: string };

function decide(ctx: AuthorizationContext, state: VerifiedState): Decision {
  denyUnless(state.agentActive, 'AGENT_INACTIVE');
  denyUnless(state.mandateActive, 'MANDATE_INACTIVE');
  denyUnless(state.audience === ctx.control.audience, 'AUDIENCE_MISMATCH');
  denyUnless(state.allowedActions.has(ctx.request.action), 'ACTION_DENIED');
  denyUnless(
    state.allowedResources.has(ctx.request.resource),
    'RESOURCE_DENIED',
  );
  denyUnless(
    state.allowedDestinations.has(ctx.request.destination),
    'DESTINATION_DENIED',
  );

  if (state.requiresApproval && !state.approvalMatches(ctx)) {
    return {
      result: 'approval_required',
      reason: 'EXACT_APPROVAL_REQUIRED',
      contextDigest: state.contextDigest,
    };
  }

  return state.reserveUsageAtomically(ctx.transactionId);
}

This pseudocode omits cryptographic verification and storage transactions. Its useful property is the closed decision type. An exception or timeout does not become an allow.

Keep credentials out of model context

The agent should receive a tool result, opaque handle or narrowly scoped capability. It should not receive a reusable API key that it can quote in a prompt, write to memory or send to another tool.

Proof-of-possession mechanisms reduce the value of stolen access tokens. RFC 9449 defines DPoP for binding OAuth tokens to a client key. DPoP does not express invoice limits or delegation, but it can protect the transport credential used by the gateway. For high-value actions, combine sender constraint, audience restriction, short expiry and business-level request binding.

Failure and recovery cases

An uncertain execution needs special treatment. The external system may have accepted the action even when the gateway lost the response. Keep the authority and budget reserved, query the authoritative system with the same idempotency key and append the reconciled outcome. Retrying with a fresh transaction ID can duplicate the action.

Verify the design with adversarial fixtures

Create a versioned fixture for each control and run the same cases through every language and adapter. A useful minimum set includes:

• exact boundary values for amounts, time and usage;
• expired, not-yet-active and revoked objects;
• wrong audience, wrong destination and wrong counterparty;
• parent-child delegation with one widened constraint at a time;
• Unicode and number canonicalization differences;
• transaction replay before and after cache expiry;
• two concurrent attempts against one-use authority;
• request-body, approval and policy substitution;
• crash injection before reservation, before dispatch and after dispatch;
• offline receipt verification with a rotated key.

Record expected reason codes, not just allow or deny. Then mutate one field per case. This turns the authorization model into an executable contract and exposes adapters that silently drop context.

Canonical JSON is relevant when signatures or digests cross language boundaries. RFC 8785 defines JCS so implementations can derive a repeatable representation before hashing or signing. Publish the exact profile and test vectors you use rather than assuming every JSON serializer behaves alike.

Current Intelliger and OATI boundary

Intelliger builds AI systems that can safely perform consequential enterprise work. Agent Trust is the control layer, the Enterprise Agent Gateway is the shared enforcement boundary and OATI is the open standard for identity, delegated authority, policy decisions and action evidence.

The OATI developer preview currently includes versioned schemas, canonical JSON, Ed25519 and ES256 profiles, issuer and key verification, revocation, a deterministic mandate evaluator, lookup and discovery, reference middleware, Commerce and RWA profiles, and a shared 73-case conformance suite across TypeScript, Python and Go. A public lookup service and a private trust and issuance vertical slice are deployed.

This does not establish production readiness. Independent cryptographic and protocol review remains open. The complete policy compiler, durable evidence and dispute workflows, full Hub lifecycle experience, operated customer gateway fleet and two-enterprise production acceptance exercise are incomplete. The architecture in this guide describes the control pattern teams should build and test; it does not claim that every commercial Agent Trust component is deployed.

Security review note: a qualified reviewer should verify the cryptographic profile, trust-anchor policy, revocation behavior, tenant isolation, failure mode and recovery plan for the actual deployment. This page was technically reviewed against the documented OATI developer-preview status on 11 August 2026, but it is not a security certification.

Continue with implementation detail

The Agent Trust overview explains the product control boundary. For protocol-specific work, read MCP authorization for consequential tool calls and the identity versus authority security analysis. The OATI Mandate documentation describes the portable authority object, and the public OATI repository contains schemas, SDKs and conformance fixtures.

For a review of a gateway design around a consequential workflow, contact Intelliger with the action, current credential path and failure state you need to control.