3 ms·
Can you explain the auth part? I feel like auth for an agent is largely a matter of either verifying its context or issuing it a JWT that's scoped to its rights
by staticassertion 6mo ago
Can you explain the auth part? I feel like auth for an agent is largely a matter of either verifying its context or issuing it a JWT that's scoped to its rights, which I assume is quite similar to how any tools would work. But I'm very unfamiliar with MCP.
- monkpit 6mo agoI think they’re saying you could start up the mcp and pass it creds/auth for some downstream service, and then the LLM uses the tool and has auth but doesn’t know the creds.
- simonw 6mo agoRight. If you're running a CLI tool that is authenticated there's effectively no way to prevent the coding agent from accessing those credentials itself - they're visible to the process, which means they're visible to the agent. With MCP you can at least set things up such that the agent can't access the raw credentials directly.
- zbentley 6mo agoThis is right. It’s not about scoping auth, it’s about preventing secret misuse/exfil. (Moved from wrong sub)
- steve-atx-7600 6mo agoAlso, you can set permissions to allow and disallow specific mcp server tool calls. With a skill you’d have to do something in the shell environment to block unwanted behaviors with auth or other means in a way that isn’t declarative.
- dcherman 6mo agoHow so? Let's use a common CLI tool as an example - kubectl. Config is generally stored in ~/.kube in a variety of config files. Running `kubectl config view` already redacts the auth information from the config. LLMs could invoke `kubectl` commands without having knowledge of how it's authenticated.
- simonw 6mo agoIf the agent has permission to run kubectl config view what's to stop it from reading those config files directly?
- dcherman 6mo agoThe same permissions model that works for other tools. In Claude Code terms, allow Bash(kubectl:*). Deny Read(**/.kube/**). That allows kubectl access without allowing the tool to read ~/.kube directly. Your argument is the same for an MCP server - auth is stored somewhere on disk, what's to stop it from reading that file? The answer is the same as above.
- simonw 6mo agoWould that stop Claude from executing this code: python -c ' print(open("~/.kube/config.txt").read()) ' The point I'm making here is that with an MCP you can disable shell access entirely, at which point the agent cannot read credential files that it's not meant to be able to access.
- dcherman 6mo agoYou can make the identical argument for the CLI tool. Allow kubectl, deny everything else.
- simonw 6mo agoI don't understand. My argument here is that one of the reasons to use MCP is that it allows you to build smaller agents that do not have a full code execution environment, and those agents can then use MCPs to make calls to external services without revealing those credentials to the agent. I think we both agree that if your agent has full Bash access it can access credentials.
- dcherman 6mo ago
- deleted 6mo ago[deleted]
- JambalayaJimbo 6mo agoThe MCP implementation is itself an agent right? Is that not just pushing the problem somewhere else? Also, I run programs on my machine with a different privilege level than myself all the time. Why can’t an agent do that?
- simonw 6mo agoI define the agent as the harness that runs the LLM in a loop calling tools. The MCI implementation is one of those tools. I wouldn't call an MCP implementation an agent.
- conception 6mo agoNo, mcp just is a server that returns prompts to the llm. The server can be/do whatever. You can have an echo mcp that list echoes back whatever you send it.
- gavmor 6mo agoTypically, no; an MCP is a deterministic program with SSE protocols.
- staticassertion 6mo agoOh. Yeah, that's neat at least. I don't think it's a big deal but that's nice enough.