Good breakdown of the identity challenge. The distinction between which agent performed an action and who authorized that agent is the harder half in practice. Most current implementations give an agent a static API key or a bearer token tied to a user session, which collapses agent identity into user identity and makes audit trails ambiguous. Once you have multiple agents operating within the same user context, you need a session-level identity that persists across tool calls and carries its own authorization scope, separate from the user session. That session identity is what makes per-request re-authorization meaningful instead of a stateless check that cannot distinguish agent X from agent Z inside the same connection. Without it, revocation becomes a user-level operation that kills all agent activity at once. The accountability question you close with is the real design constraint: if an agent action has consequences, the system needs to anchor it to a specific agent identity with a verifiable authorization trail, not just a user account.