Problem
In agent identity mode a resource verifies the agent token and sees sub, so it is natural to key resource-side policy on the agent identifier (identifier → allowlist). That policy does not survive the move to auth tokens: an auth token deliberately carries no agent identifier and no delegation chain ((#why-no-agent-identifier), added in -11), and the resource enforces against sub (the person), scope, and r3_granted. Nothing in the draft warns that policy pinned to the agent identifier has to be re-expressed as scopes or R3 operations before those endpoints leave agent identity mode.
This is the failure mode a real deployment walked into: a per-agent label allowlist at the resource, designed in agent identity mode, silently unenforceable in their planned auth-token phase. Neither of their own review passes noticed; the design reads fine until you know where agent identity stops flowing.
Suggested direction
A short paragraph in (#resource-access-modes) or (#why-no-agent-identifier), addressed to resource implementers: agent identity mode is the only mode in which the agent identifier reaches you; if your authorization decisions use it, they are mode-local by construction; express durable per-operation policy as scope or R3 operations, which flow in every mode.
Context
From the notes.ito.com deployment review (writeup, review pass) — the most consequential finding of the review, and as much a doc failure as a reader failure.
Problem
In agent identity mode a resource verifies the agent token and sees
sub, so it is natural to key resource-side policy on the agent identifier (identifier → allowlist). That policy does not survive the move to auth tokens: an auth token deliberately carries no agent identifier and no delegation chain ((#why-no-agent-identifier), added in -11), and the resource enforces againstsub(the person),scope, andr3_granted. Nothing in the draft warns that policy pinned to the agent identifier has to be re-expressed as scopes or R3 operations before those endpoints leave agent identity mode.This is the failure mode a real deployment walked into: a per-agent label allowlist at the resource, designed in agent identity mode, silently unenforceable in their planned auth-token phase. Neither of their own review passes noticed; the design reads fine until you know where agent identity stops flowing.
Suggested direction
A short paragraph in (#resource-access-modes) or (#why-no-agent-identifier), addressed to resource implementers: agent identity mode is the only mode in which the agent identifier reaches you; if your authorization decisions use it, they are mode-local by construction; express durable per-operation policy as scope or R3 operations, which flow in every mode.
Context
From the notes.ito.com deployment review (writeup, review pass) — the most consequential finding of the review, and as much a doc failure as a reader failure.