Enterprise Managed Authorization - Clarifying Agent vs User Identity
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Documentazione
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Ambito
- api, authorization, documentation
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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?
- Lingua principale
- MDX
- Stelle
- 164
- Fork
- 53
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di modelcontextprotocol/ext-auth
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
modelcontextprotocol/ext-auth#32 · 1 commento ·
-
DEBUGApertabug
Difficoltà 5/5 Più di una settimana Idoneità per principianti 10/100
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 30/100
modelcontextprotocol/ext-auth#26 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 35/100
Tutte le issue di modelcontextprotocol/ext-auth
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 91/100
TencentCloud/Octop#1577 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
GNS3/gns3-server#2935 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
TauricResearch/TradingAgents#1476 ·
I maintainer di solito rispondono entro 2 giorni