Writing ·

How to enforce least-privilege delegation between AI agents in 2026

Treat each agent handoff as an explicit, bounded delegation: narrow the resource and scope, set expiry and budget, then enforce the envelope outside the model before a consequential tool action.

By Youssef Hemimy · agent safety · agent workflows · MCP · AgentOps

Treat every agent-to-agent handoff as an authorization decision: give the next agent a named parent, only the resource and scope its task needs, a short expiry, a bounded budget, and a revocation path. A deterministic policy point—not the receiving agent's prompt—should check that envelope and the relevant session state before a consequential tool action runs.

Routing a specialist is not authorizing one

A workflow router can decide which specialist should receive a task. That is separate from deciding what the specialist may do after it receives the task. Passing an ambient credential and calling it a handoff makes that second decision invisible.

RFC 8693 distinguishes delegation from impersonation: in a delegation, the actor remains identifiable as the party acting on behalf of another principal. It also supports requests for a target resource, audience, and scope, which gives a practical baseline for narrowing a downstream grant rather than copying a parent's authority wholesale.

A delegated handoff becomes inspectable when the policy boundary can see who delegated, what was narrowed, and whether the next action is still permitted.

Issue an envelope the policy layer can inspect

The paper's proposed Agentic Principal Chain carries authority across principals, narrows scope and budget, evaluates requests against accumulated session state, and enforces a result outside the model. For a real system, the important move is less exotic: make the authority available to the policy boundary as structured data rather than as an assumption buried in an agent's context.

  • Parent and delegate identities: who granted authority and who is using it now?
  • Target resource and scope: which system and operations may this task reach?
  • Expiry and budget: when does the grant end and what consumption is bounded?
  • Action class and revocation reference: what next action is expected and what can invalidate it?

A recorded chain is not a chain-aware policy

RFC 8693 permits nested actor claims to express a delegation chain. But it says a token consumer should use only the top-level claims and current actor for access-control decisions; earlier nested actors are informational. If a workflow needs parent-aware revocation, a shared budget, or a prohibition on a sequence of individually valid actions, it needs explicit state and enforcement outside the token.

That is where a production tool contract earns its keep: it gives the boundary an inspectable final action. Keep the protected tool surface controlled too, as in private MCP server exposure.

Check the action sequence, not merely the next tool name

The paper's distinctive idea is that individually permitted actions can still form a prohibited outcome. Its conditional result depends on a complete restriction set and serialized admission; unmodelled or concurrent paths can evade the check. Treat that as a hardening question, not a solved property: which action combinations must never coexist in one session, and which system owns the state needed to tell?

Make authority expansion explicit. Use human approval gates when a person must decide whether a broader scope, new budget, or longer lifetime is acceptable. Use agent workflow graphs to show where those boundaries and recovery paths sit.

Roll it out at one consequential handoff

  1. Choose one handoff that reaches a consequential tool or dataset.
  2. Write the delegate's smallest resource, scope, expiry, and budget.
  3. Keep issuance, evaluation, and revocation outside both agents' prompts.
  4. Send every consequential tool call through the same policy point.
  5. Test denied expansion, expiry, budget exhaustion, revocation, and prohibited action sequences.
  6. Log the parent, delegate, envelope decision, tool request, and outcome.

Keep the evidence boundary honest

The paper evaluates its architecture across 3,154 benchmark and simulation instances. That is useful mechanism-level evidence, not production-deployment evidence. It does not establish live attack rates, and it leaves residual risk for harmful actions that remain within authorized scope, parameter-level attacks, incomplete restrictions, and attacks that span sessions.

So do not present delegation envelopes as an anti-prompt-injection force field. They are one durable boundary alongside tool contracts, parameter validation, approval controls, and observability.

Sources

FAQ

Is a sub-agent authorized because its parent agent is authorized?

No. Treat the handoff as a new delegation decision. Scoped token exchange can convey a named actor and narrower authority, but the deployment must decide exactly what the delegate may do.

Is a nested delegation chain enough to enforce policy?

No. RFC 8693 says earlier nested actors are informational for an access-control decision. Parent-aware revocation, cumulative budgets, and sequence restrictions need explicit policy state outside the token.

Does least-privilege delegation stop every harmful agent action?

No. The source paper leaves residual risks including harmful actions within scope, parameter-level attacks, incomplete restrictions, and cross-session attacks. It is a useful boundary, not a universal security guarantee.

Building something that has to hold up?

We do this work for teams — agent reliability hardening, custom MCP servers, and full-stack AI systems built to survive production.