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 the agent 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.

Neighbourhood

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

References

Provenance