VIII · Safety & ControlEmerging★

Delegated Agent Authorization

also known as On-Behalf-Of Agent, Scoped Agent Delegation, 認証付き委任

Have an agent act for a principal using scoped, short-lived, revocable delegated credentials rather than the principal's own static secrets, so each action stays attributable across the principal-to-agent-to-subagent chain and a compromise is contained.

Context

A team is deploying an agent that performs real actions for a user — reading mailboxes, calling internal services, moving money, editing records — and often delegates parts of the task to sub-agents or tools. Each of those calls hits a system that needs to know who is acting and with what authority. The team has to decide how the agent proves it is allowed to do what it is attempting, on whose behalf, and within what limits.

Problem

Sharing the user's own credentials or a long-lived broad API key with the agent is the path of least resistance and the most dangerous one: the agent inherits everything the user can do, the key cannot be scoped to the task, and when it leaks — into logs, a prompt, or a compromised sub-agent — it cannot be cleanly revoked. It also collapses the principal chain: a downstream service sees only the borrowed credential and cannot tell whether the user, the agent, or a sub-agent three hops away initiated the action. Without a way to express bounded, attributable delegation, every agent action is either over-privileged or unauditable.

Forces

  • An agent acting for a user needs authority, but inheriting the user's full credentials over-privileges it.
  • Static long-lived secrets cannot be scoped to a single task and cannot be revoked cleanly when they leak.
  • Downstream services need to know the real initiator across a principal-to-agent-to-subagent chain.
  • Delegation must be narrow enough to contain a compromise yet broad enough to complete the task.
  • Each sub-agent needs its own narrower slice of authority, not a copy of the parent's.

Example

A scheduling agent needs to read one user's calendar and send invites, nothing more. Instead of taking the user's account credentials, it exchanges a consent token for an access token scoped to calendar read-write, valid for fifteen minutes, stamped with the user as the delegating principal. When it hands the drafting step to a sub-agent, that sub-agent gets a token scoped to draft-only. If either token leaks, it expires fast, reveals nothing about the user's password, and can be revoked without touching the user's account.

Diagram

Solution

Therefore:

Use a delegation flow (an on-behalf-of grant, token exchange, or workload-identity federation) in which the agent trades a proof of the user's consent for an access token scoped to just the task's needs, with a short lifetime and a claim identifying the delegating principal. The agent never holds the user's primary credentials. When the agent spawns a sub-agent or calls a tool, it exchanges its token for a further-narrowed one, so authority only shrinks down the chain. Tokens are revocable centrally, and every issued token and the action it authorised are logged, reconstructing the full principal chain (user, agent, sub-agents) for audit and dispute.

What this pattern forbids. The agent must not hold or reuse the principal's primary credentials; it may act only under a scoped token whose authority is no broader than the task, and each sub-agent hop may only narrow that scope, never widen it.

And the patterns that stand alongside it, or against it —

  • complementsPolicy-Gated Agent Action (KRITIS)★— Each agent action passes through a policy gate (NIS2, EU AI Act, BSI rules) and is tagged with Run ID + Model Digest + Policy Hash for WORM-audit reconstruction.
  • complementsSecrets Handling★— Ensure the model never receives secrets in plaintext; tools resolve credentials from references at runtime.
  • complementsAgent Credential Vault★— Broker the agent's credentials at action time through a managed vault of passwords, MFA secrets, and digital personas, so secrets never enter the prompt or context and the agent authenticates as a governed identity.
  • complementsDeontic Token Delegation·— Reify obligations, permissions, and prohibitions as transferable deontic tokens that agents pass along the delegation chain with provenance, so duty and accountability transfer with the work, not only the credentials to perform it.
  • alternative-toStatic Role for a Dynamic Agent✕— Anti-pattern: authorize a goal-driven agent with static, login-time, role-based privileges, so its standing permissions persist between and beyond tasks, forcing a choice between over-granting broad access and blocking the agent mid-task.
  • complementsTenant-Scoped Tool Binding★— Bind every tool call and retrieval to the active tenant in code at the execution layer, so a multi-tenant agent can never be talked into reading or writing another tenant's data.
  • complementsEphemeral Agent Identity★— Mint each agent run a short-lived identity of its own, scoped to one task and provisioned just-in-time, then revoke it on completion so no standing credential outlives the work.
  • alternative-toIdentity Impersonation✕— Anti-pattern: let the agent act under the principal's own full identity and token, so every action it takes is recorded as the principal's and audit cannot separate user-initiated from agent-autonomous decisions.
  • alternative-toBlanket-Authorization Accountability Rupture✕— Anti-pattern: a user grants an agent one broad standing authorization to act across apps, and when an autonomous action later causes harm no party retained whole-process control, so liability fractures across user, platform, and agent.
  • complementsVerifiable Purchase Mandate★— Anchor agent-initiated payments in a cryptographically signed mandate that captures the user's authorization and travels with the transaction, so a merchant or payment network can independently verify the agent acted on genuine user intent.
  • complementsSigned Agent Card★— Cryptographically sign an agent's published capability card so a consuming agent can verify it was issued by the claimed domain before binding to or delegating to it, closing the spoofing gap in agent-to-agent discovery.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in frameworks

References

Provenance