An agent node inside concentric permission rings being narrowed to least privilege.

How to scope an agent’s permissions

Scoping is the part of Know Your Agent that decides what an agent may actually do. Identity tells you who the agent is and who is accountable for it; scope tells you the outer boundary of its authority — which actions, against which resources, up to what limits, for how long, and in which environment. An agent with a strong identity and a broad token is still over-privileged, and over-privilege is what turns a single compromised credential or a misread instruction into a business-impacting event.

This guide assumes the framing in What is Know Your Agent? and the verification steps in How to verify an agent. It covers the mechanics of scoping, the difference between delegating authority and impersonating a user, and the anti-patterns that quietly widen a scope over time.

Start from least privilege

Least privilege means granting the minimum authority the task requires, for the shortest time that makes sense, and nothing more. For agents this is harder than for a service account, because an agent decides at runtime which tool to call and with what parameters, rather than following a fixed code path.

NIST’s zero-trust model removes implicit trust based on network location and treats person and non-person entities alike, so an agent inside your perimeter is not thereby trusted. OWASP makes the same point operationally: restrict an agent’s access to the minimum necessary, grant each tool or server its own scoped credentials, and never share tokens across servers.

The practical rule: the scope should be derived from the task, not from the tool. “This agent may book a HEL–BCN economy flight on the principal‘s account, up to €1,200, before 31 October” is a scope. “This agent has the bookings scope” is a doorway.

Delegation versus impersonation

When an agent acts for a user, the service on the other side needs to distinguish two very different situations:

  • Impersonation — the agent becomes the user; downstream sees only the user. The agent’s own identity disappears, and with it the ability to hold the agent accountable.
  • Delegation — the agent acts on behalf of the user; downstream sees both the actor (the agent) and the subject (the principal).

OAuth defines the client as an application making protected resource requests “on behalf of the resource owner”, and RFC 8693 formalises the distinction between impersonation and delegation so a downstream service can tell who is acting and who is on whose behalf. For KYA, delegation is almost always the right default, because it preserves the pair of facts you need for accountability: which agent did it, and for whom.

A delegated token should therefore carry both roles — conventionally the subject (`sub`) as the principal and the actor (`act`) as the agent — plus the scope. RFC 8693 is the exchange that mints that token from the principal’s grant and the agent’s assertion.

The five dimensions of a scope

A useful scope is explicit along five dimensions. If any dimension is left open, that is where over-privilege enters.

DimensionQuestionExampleWhere it lives
ActionsWhich operations?`bookings:create`, `invoices:read`OAuth `scope`, or rich authorization detail
ResourcesAgainst what?One account, one repository, one supplierToken audience, resource indicator
AmountUp to what limit?≤ €1,200 per booking, ≤ 50 invoicesFine-grained authorisation detail
TimeUntil when?Single task; token TTL minutes → hoursToken `exp`, scope expiry
EnvironmentWhere?Staging vs production; one tenantAudience/issuer binding, policy engine

OAuth 2.0 Rich Authorization Requests (RFC 9396) exist precisely because a bare `scope` string cannot express amount, resource or condition. MCP’s authorization profile likewise requires a client to identify the intended server with a resource indicator, so a token minted for one server is not silently accepted by another.

Audience binding matters as much as scope. A scoped token for “create bookings up to €1,200” that any service will accept is still a problem. Bind the token to its intended audience (and, for high-value actions, to the agent’s key — see below), and the scope’s resource dimension becomes enforceable.

Just-in-time, short-lived credentials

The strongest scope is one that barely exists. Instead of provisioning a long-lived credential with a fixed set of permissions, mint the credential when the task starts, give it the narrowest scope and the shortest lifetime that will complete the task, and let it expire. SPIFFE issues short-lived keys that are “rotated frequently and automatically”, so there is no static secret to leak. OWASP’s Non-Human Identity Top 10 lists Long-Lived Secrets and Secret Leakage as distinct risks for exactly this reason.

Short lifetimes do three things at once: they bound the blast radius if a credential is stolen, they make revocation cheaper (waiting for expiry is often enough), and they force the agent to prove itself again rather than run forever on a token issued months ago.

For high-value or cross-boundary actions, combine a short-lived scoped token with proof of possession. DPoP (RFC 9449) binds the token to a key the agent holds and signs a per-request proof; mutual TLS (RFC 8705) binds it to a client certificate instead. A stolen token alone is then not enough — and DPoP is explicitly designed to allow detection of replayed tokens.

Approval gates

Some actions should not complete on the agent’s word alone: payments above a threshold, destructive operations, first-time counterparties, changes to the agent’s own scope. The workflow is a gate, not a hard block:

  1. The agent requests the action and attaches its scope and evidence.
  2. Policy checks the request against the delegation.
  3. If it is inside a low-risk envelope, it proceeds; if not, a named human approves or declines.
  4. Either way, both the decision and the reason are logged (see Audit trails for agents).

OWASP recommends human approval for high-risk actions and warns against auto-approving tool calls; the confirmation must show the full parameters, not a friendly summary, and must not be bypassable by text the model controls. In the EU AI Act’s terms, human oversight of high-risk systems must be assigned to competent, authorised people — a design point, not a legal opinion (see the note below).

A gate is only as good as its default. Make the default “deny”, and open specific envelopes explicitly.

Anti-patterns

Anti-patternWhy it failsWhat to do instead
Broad token reused across toolsOne compromise or one bug exposes everythingPer-tool, per-server scoped credentials
Scope derived from the tool, not the taskTools accumulate permissions “just in case”Derive scope from the task; review regularly
Impersonation when delegation is meantAgent identity vanishes; no one to hold to accountUse delegation semantics (actor + subject)
Long-lived tokens with no rotationLeak-and-run window of monthsJust-in-time, short-lived, rotated credentials
Bearer tokens with no key bindingAny interception is replayableProof-of-possession (DPoP or mTLS)
Missing audience checkToken for service A works at service BBind token to intended audience
Scope creep over timeAuthority silently accumulatesRe-scope on each task; expire idle grants
Approval UI that trust the model’s summaryInjection can hide the real parametersShow full parameters; keep gates out of model control

Checklist

  • Scope is derived from the task, not the tool
  • Each action, resource, amount, time and environment dimension is explicit
  • The agent acts by delegation, not impersonation (actor and subject both visible)
  • Credentials are minted just-in-time and short-lived
  • High-value actions require proof of possession, not a bare bearer token
  • The token is bound to its intended audience and issuer
  • High-risk actions pass a human approval gate with full parameters shown
  • Deny is the default; specific envelopes are opened deliberately
  • Scope is reviewed and re-derived as the task changes, not accumulated

FAQ

Is a scope the same as a permission?

A scope is the boundary of authority expressed for a credential; a permission is the underlying capability a policy decides to allow or deny. You set a scope so the credential cannot express more than the task needs, and you enforce permissions per request so the action is allowed. Both are needed: a narrow scope with no per-request check still approves anything the token can do.

Should an agent ever hold a broad credential?

Ideally not. Where a legacy system forces it (a salted, non-scoped API key), treat the credential as compromised-by-default and compensate: keep lifetimes short, put a policy-enforcing gateway in front, log every call, and isolate the agent. The compensating control is the scope you cannot express in the credential.

How short is “short-lived”?

As short as the task allows. A single booking may need a token valid for minutes; a long-running migration may need hours. OAuth’s introspection (RFC 7662) lets a resource server confirm a token is still active before a high-value action, so a slightly longer lifetime can be tolerated where a revocation check closes the gap.

Does scoping replace verification?

No. Scoping is step 3 of the seven-step verification checklist: you still verify the credential per action and confirm the specific action is authorised. Scoping defines the envelope; verification enforces it.

Not legal advice. Where scoping decisions are constrained by regulation — for example human-oversight duties for high-risk AI systems, or payment-scheme rules for agent-initiated transactions — treat this guide as a technical starting point and confirm your obligations with qualified counsel. The site’s framing of KYA is an identity-and-accountability discipline, not a legal standard.

Primary sources

Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.