Enterprise Managed Authorization - Clarifying Agent vs User Identity
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Documentation
- Clarity
- Needs clarification
- Activity status
- Stale
- Domain
- api, authorization, documentation
Research direction
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.
Written by the indexing model from the issue text.
Description
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?
- Dominant language
- MDX
- Stars
- 164
- Forks
- 54
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from modelcontextprotocol/ext-auth
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
-
DEBUG Openbug
Difficulty 5/5 Over a week Newbie friendliness 10/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 30/100
modelcontextprotocol/ext-auth#26 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
modelcontextprotocol/ext-auth#21 · 1 comment ·
All issues in modelcontextprotocol/ext-auth
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
mksglu/context-mode#1200 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
clawsweeper:needs-maintainer-review clawsweeper:needs-product-decision clawsweeper:no-new-fix-pr impact:auth-provider issue-rating: 🌊 off-meta tidepool P2
Difficulty 1/5 Under an hour Newbie friendliness 80/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100