Enterprise Managed Authorization - Clarifying Agent vs User Identity

Start by reviewing the Enterprise-Managed Authorization profile and the current access-token identity model described in the issue, especially the user sub and client client_id claims. Determine whether agent-versus-user execution context is intended to be conveyed to resource servers or is out of scope, then document the answer and expected handling for enterprise API providers.

While reviewing the Enterprise-Managed Authorization profile for MCP, I had a question from the perspective of an enterprise API provider (i.e., systems behind an MCP Server).

In the current flow, access tokens ultimately presented to MCP Resource Servers identify a user (sub) and a client (client_id). However, it is not clear how a downstream API or system can determine whether a request is being executed directly by the human user, or by an autonomous or semi-autonomous agent acting on the user’s behalf.

From the API’s point of view, these cases appear indistinguishable (please correct me if I am wrong), which effectively results in the agent fully impersonating the user at the backend system.

In many enterprise environments, this distinction is important for:

• API-level policy enforcement (e.g., different rules for human vs delegated/agent actions)
• Audit and regulation requirements
• Explicit restrictions on silent or opaque user impersonation by agents

This raises a couple of clarification questions:

• Is the current assumption that MCP Clients are treated purely as passive user agents (similar to browsers or CLIs)?
• If not, is there an intended mechanism (in this spec or elsewhere) to convey “acting on behalf of” or execution context to resource servers so they can apply agent-aware policies?
• If this is considered out of scope for the Enterprise Managed Authorization profile, where is this distinction expected to be handled?