Engineering Agent Authorization, Part 1: Designing Capability Tokens That Bound Scope, Custody, Delegation, and Lifetime

AI agents turn model-generated choices into tool calls that can read data and change external systems. For engineers building those integrations, authorization is a practical design problem: which task may the agent perform, which component holds its credentials, and what limits apply when a tool choice is wrong?

Part 1 covers credential scope, custody, delegation and lifetime. Part 2 examines where to enforce those limits.

TL;DR: Issue authority for a bounded task, keep powerful credentials with trusted components, and distinguish application permissions from provider credentials. Short expiry and proof of possession help, but preventing repeated effects and stopping access require additional controls.

Consider an invoice-review agent that needs to read one invoice and create a separate result. A credential that can read every invoice and overwrite any result grants more authority than the task requires.

Separate the identities and credentials

Start by separating the model from the runtime. The model proposes a tool invocation. Runtime code validates the invocation and obtains or uses credentials. A credential can be available to that code without appearing in a prompt. That separation reduces exposure through model output, but the code still needs enforceable limits on the operations it performs.

• Workload credential — What it establishes: Which application is making the request. Who validates it: Authority, broker or receiving service.
• Action capability — What it establishes: Which bounded operation the application may perform. Who validates it: Participating gateway, trusted tool or broker.
• Provider credential — What it establishes: Which operations the provider permits on its resources. Who validates it: Downstream provider.

The action capability is application-defined. Roles may overlap; check each credential’s audience, scope and lifetime.

A verified user grant supplies the basis for delegated authority; bind it to the requesting workload. For unattended work, identify the application authority explicitly. A human name in an agent-generated request is insufficient evidence of delegation.

OAuth token exchange provides standard request and response machinery for exchanging security tokens. It supports delegation and impersonation semantics, but the deployment still defines which exchanges it permits. The issuer must authenticate the requester and evaluate the relevant grants. [1]

Request authority for a specific task

For invoice INV-1042, the read operation should identify an immutable source version. The write operation should identify a separate result destination and forbid overwriting existing results. Reading the source and writing the result are distinct permissions; approval of one should not silently authorize the other.

OAuth security guidance recommends restricting access tokens by audience, resources and actions. Rich Authorization Requests supplies a structured authorization_details parameter for finer-grained permissions. The application must define the meaning of its authorization type and ensure the issuer and verifier share that interpretation. [2] [3]

A capability for creating the review result could contain:

{
  "iss": "https://authority.example",
  "sub": "invoice-review-worker",
  "aud": "https://review-api.example",
  "iat": 1792670400,
  "exp": 1792670460,
  "jti": "cap-example-1042",
  "authorization_details": [{
    "type": "invoice_review_result",
    "actions": ["create"],
    "result_id": "INV-1042-review-1",
    "source_version": "v7",
    "action_digest": "sha256:<action-digest>"
  }]
}

This is a payload fragment, not a signed or usable token. The invoice authorization type and its domain-specific fields are custom. The 60-second lifetime is a design choice for this capability, not a promise about a downstream cloud credential. JSON Web Token (JWT) defines claims such as issuer, audience, expiration and token identifier; a jti identifies a token but does not itself consume it. [4]

• iss, sub, aud — What the verifier establishes: Accepted issuer, workload identity and intended receiving service.
• iat, exp, jti — What the verifier establishes: Issuance, expiry and token identity; identity alone does not prevent reuse.
• authorization_details — What the verifier establishes: Custom operation, result and source constraints checked against execution.

Verify the signature with trusted issuer keys, allow only approved algorithms, and validate issuer, audience and lifetime. Use distinct validation rules for each token type so a workload credential cannot be accepted as an action capability merely because its signature is valid. [4] [12]

The authority should resolve tenant membership, source ownership and allowed destinations from trusted configuration. Letting the model supply those facts unchecked would turn a narrow-looking token into a signed copy of an untrusted assertion.

Bind the approved action to the executed action

An action digest can bind a capability to exact normalized parameters. Define a versioned action object containing the tenant, operation, target, source version and relevant parameters, then hash its canonical encoding. At execution, the trusted verifier constructs the same object from the operation it will actually perform and compares the digest.

Canonicalization needs a precise contract. JSON Canonicalization Scheme defines deterministic serialization within its supported JSON constraints. Application rules still need to address defaults, units, identifiers and which fields affect execution. [5]

Test an approved destination A against a request for destination B; reject it before the write. Also test adapters that change the target after verification.

Exact binding has a cost: changing an approved parameter requires fresh authorization. Reserve it for operations where that precision matters. Resource-and-action restrictions may be sufficient for a broader read task. Neither approach determines whether the review conclusion is correct; business validation remains a separate responsibility.

Separate theft protection from repeated execution

Sender-constrained tokens require the presenter to prove possession of associated key material. Demonstrating Proof of Possession (DPoP) specifies an application-layer proof that binds a request to a key and, at a protected resource, to the access token. Its checks include the HTTP method and URI. It does not protect the request body or general headers, and compromised client code with access to signing operations can still act. [6]

Proof replay prevention and business-operation deduplication are separate concerns. A legitimate runtime can generate a fresh proof and repeat the same write. A one-use capability requires an atomic reservation at the verifier. The destination also needs an idempotency mechanism or suitable conditional write so retries cannot create unintended duplicate effects.

That extra state complicates recovery. A reservation can succeed just before the process crashes. The retry path must determine whether the operation happened, rather than blindly issuing a new capability and replaying it. Short expiry reduces the period of credential exposure; it does not solve that ambiguity.

Keep delegation within verified grants

When a planner delegates to a worker, the issuer should evaluate the requested child operation against the parent’s permitted authority and any applicable user grant. Give the child a suitable audience and scope. Do not infer broader permission from an agent’s reputation, role-like nickname or successful history.

RFC 8693’s nested act claims record earlier actors. Token consumers must treat those earlier actors as informational, using top-level claims and the current actor for access-control decisions. If an application needs delegation-depth limits, it should enforce a separate, trusted issuance policy rather than reinterpret actor history as a portable permissions model. [1]

Assign ownership of delegation grants, mappings and renewal rules.

Respect provider credential boundaries

A broker can exchange its protected authority for a restricted child credential. For direct access, it returns that child to runtime code, which then calls the provider. It can instead supply the child to a trusted gateway or tool service that enforces application rules before calling the provider. The provider enforces its own credential and policy semantics; it does not automatically evaluate a custom action digest or application block list.

• AWS STS role session — Useful restriction: Session policies narrow permissions granted through the role. Limit to account for: AssumeRole requests start at 900 seconds; inspect resource policies too.
• GCP Credential Access Boundary — Useful restriction: Bounds a service account token’s access to Cloud Storage resources. Limit to account for: Cloud Storage only; not arbitrary application-parameter checks.
• Azure Blob user delegation shared access signature (SAS) — Useful restriction: Selects storage resources, permissions and validity interval. Limit to account for: Revocation has key and permission dependencies; propagation may be delayed.

AWS documents the intersection of role and session policies for role-derived permissions. Effective access also depends on other policies: within an account, a resource policy granting directly to a role-session ARN can escape implicit denies in a session policy. Review the complete access path, not just the broker’s generated JSON. [7] [8]

Google’s Credential Access Boundaries apply specifically to Cloud Storage. For Azure, choose the SAS type deliberately; Microsoft recommends user delegation SAS where SAS is used. Its revocation documentation warns about cached keys and role assignments. [9] [10] [11]

Design the stop path before issuing credentials

Blocking new capabilities or exchanges prevents new issuance. It does not recall every credential already delivered. For direct provider access, the response depends on provider expiry and supported revocation or policy changes. For application-mediated execution, a verifier can reject later admissions after consulting authoritative block state. Already admitted or in-flight work needs separate handling.

Direct access removes a business-data proxy from the path, but leaves the provider in charge of what a delivered credential can do. An application verifier can enforce finer rules and check current state, at the cost of another trusted component and potentially another availability dependency.

Keep tokens and credential-bearing URLs out of prompts and routine logs. Retain enough nonsecret identifiers to investigate an ambiguous outcome.

Before implementation, be able to answer five questions: who holds each credential, which service accepts it, what operation it permits, what prevents reuse, and what stops further use after an incident. The companion article, Your AI Agent Has Permissions. Who Enforces Them?, follows those answers through gateways, trusted tools and cloud IAM.

References

Primary sources checked October 22, 2026.

1. RFC 8693 OAuth 2.0 Token Exchange, especially sections 2 and 4.1.
2. RFC 9700 OAuth 2.0 Security Best Current Practice, sections 2.2 and 2.3.
3. RFC 9396 Rich Authorization Requests, sections 2, 6 and 9.
4. RFC 7519 JSON Web Token, section 4.1.
5. RFC 8785 JSON Canonicalization Scheme, section 3.
6. RFC 9449 Demonstrating Proof of Possession, sections 4.3, 7, 11.4 and 11.7.
7. AWS STS AssumeRole API, DurationSeconds and Policy.
8. AWS permissions boundary evaluation, resource policies for role sessions.
9. Google Cloud Credential Access Boundaries.
10. Microsoft shared access signatures overview.
11. Microsoft user delegation SAS revocation.
12. RFC 8725 JSON Web Token Best Current Practices, sections 3.1, 3.3 and 3.8–3.12.