[staticassertion]

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]

I 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]

Right. 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.

[dcherman]

How 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]

If the agent has permission to run kubectl config view what's to stop it from reading those config files directly?

[dcherman]

The 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]

Would 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.

[zbentley]

This is right. It’s not about scoping auth, it’s about preventing secret misuse/exfil.

(Moved from wrong sub)

[steve-atx-7600]

Also, 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.

[JambalayaJimbo]

The 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?

[conception]

No, 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.

[simonw]

I 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.

[gavmor]

Typically, no; an MCP is a deterministic program with SSE protocols.

[staticassertion]

Oh. Yeah, that's neat at least. I don't think it's a big deal but that's nice enough.