MCP's shipped auth extension buys the agent's token with an employee's browser login

The repo arithmetic is the whole story of where this protocol is. Four named pieces on the roadmap ^[1]. One stable file and one draft file in the ext-auth repo ^[2]. Two of the four exist only as open pull requests ^[18]: SEP-1932 for DPoP and SEP-1933 for Workload Identity Federation, both opened on 2025-12-05 ^[11][12]. Measured to their last recorded updates, that is 269 days open for the DPoP profile and 262 for workload identity federation ^[16][17]. The commands that produced those listings were run before publication on 2026-09-05, so read the counts as of that date ^[15].

Here is what actually happens when a client uses the stable extension. A browser redirect goes to the enterprise IdP. The user logs in. The IdP issues an ID token to the MCP client, the client exchanges that ID token for an Identity Assertion JWT Authorization Grant, and presents the ID-JAG to the MCP authorization server to get an access token ^[5]. The IdP evaluates group membership and conditional access policy at the exchange step, which is what makes access grantable and revocable from a single admin console ^[6]. That is good work against the problem it names, which is each employee authorizing each MCP server one at a time ^[4]. Three things would have to be true for the same flow to cover an unattended agent: a browser at session start, a human available to log in, and an IdP policy that can express the agent's scope as that human's group membership. According to webofmike, the extension was not built for the 3 AM namespace case and does not claim to be ^[7].

The draft is the machine-to-machine path, and its prerequisite is in the text: pre-registered client credentials, typically established out-of-band through administrative channels, with Dynamic Client Registration not used ^[8]. Somebody creates a credential and puts it somewhere the agent process can read. The objection webofmike raises is empirical rather than theoretical, since the LiteLLM .pth payload swept environment variables and .env files, and a credential the agent holds is a credential in whatever else reads those ^[9]. JWT client authentication instead of a shared secret is a real improvement, and it still leaves a registered client with a key to keep ^[10].

SEP-1932 would apply RFC 9449 to bind an access token to a key pair the client controls, so a leaked token cannot be replayed by whoever picked it up, which is the difference between a bearer token and a sender-constrained one ^[14]. Both proposals still carry TBD in the field where the pull request template asks whether the proposal has been tested in a real application ^[13], which is the field I read first on any spec PR. The published account of SEP-1933's motivation stops mid-sentence, so what its federation model would actually attest is not on the record ^[19].

Which leaves the issuance layer where it was. The one stable extension authenticates the employee who started the session, and the agent acts on that employee's delegated authority ^[3]. Anything running when no employee started a session gets an identity you chose, from whatever your platform already uses to attest a workload. If DPoP lands afterwards, the cost is key handling and token binding in clients that are already deployed ^[14].