Presumably STDIO depends on the local AuthN/PAM that enabled the user space IO to begin with? I suspect what people are concerned about is the authorization of the LLM to the agent and its data rather than authN. AuthN in stdio would be the user that started the processes, or went through some AuthN chain allowing stdio to forward (I.e., ssh, sudo, etc). Am I missing something?
The bigger issue is that we need a good why to authenticate more dynamically. In the context of a desktop app (desktop claude, claude code) where you are running an application locally, for your own purposes it can run as your own user.
But when you are running things in any kind of multi-user/multi-tenant scenario, this is much harder and the protocol doesn't really address this (though also doesn't prevent us from layering something on top). As a dumb (but real) example, I don't want a web-enabled version of of an MCP plugin to have access to my company's google drive and expose that to all our chat users. That would bypass the RBAC we have. Also I don't want to bake that in at the level of the tool calls, as that can be injected. I need some side channel information on the session to have the client and server to manage that.
Ok fair enough - effectively there needs to be an authorization propagation channel that is systematic and bypasses the LLM and probabilistic layers through to each endpoint through the server. The issue isn’t the MCP server and client themselves but that there’s no clear and defined way to pass authZ through to the other side. AuthN should be handled at the interface and the AuthZ propagation is the crucial missing piece. Right?
Yep - that is my take. It isn't a weakness of MCP as such, but it a gap for which no good tooling exists afaik.
No they are concerne with SSE/HTTP as some made some MCP server over HTTP without auth in 2025. Then call it MCP issue.
Right - that’s my point. It’s janky to put AuthN into a high level protocol like MCP when low level protocols do a better job that’s more reliable and thoroughly vetted. You can do full on SAML etc and go hog wild without ever touching MCP while inheriting all the thorough analysis and implementation pressure testing down stack. Doing something unsafe because you don’t know what safe looks like isn’t application protocols fault.