AI Agents Need Their Own Identity. Mine Were Using... Erm... Mine.

Really thorough rundown, especially the eight-way comparison table. One thing the short-lived-token tier doesn't quite resolve: Restock Agent runs unattended overnight and Tier 1 says swap the forever-secret for a short-lived token, but a token short enough to be a meaningful control surface won't outlive an actual overnight run, so something has to refresh it mid-task. If that refresh just re-issues the same scope without checking anything, you've bought token rotation and nothing else, the same standing authority is still alive, just wearing a new token every few minutes. The revocation you actually want, admin pulls the agent's access or the sponsor situation changes, only does anything if the refresh step re-runs the authorization decision rather than rubber-stamping the previous one. Worth being explicit about which of the two you're buying when picking a TTL, since "short-lived" reads as a security property but is only one if the refresh path checks something new each time.

The distinction between “who is the agent?” and “what is it allowed to do?” is the part I’d underline. Identity solves attribution, but authorization has to be evaluated at the action boundary, otherwise you just end up with a perfectly auditable agent that is still over-privileged.

The “working for a person vs. working for itself” split is also a useful design decision to make before choosing the token flow. In production agentic systems at IT Path Solutions, that distinction affects delegation, scope, expiry, audit trails, and especially how much authority survives a handoff between agents.

The multi-hop section exposes the harder problem: carrying delegation metadata is not the same as being able to trust it. Until every hop can independently reduce authority and the final system can establish who actually approved the consequential action, adding more agents mostly increases the ambiguity in the audit trail.