[lll-o-lll]

Cool cool. Except.

What about auth? Authn and authz. Agent should be you always? If not, every API supports keys? If so, no fears about context poisoned agents leaking those keys?

One thing an MCP (server) gives you is a middleware layer to control agent access. Whether you need that is use-case dependent.

[mstipetic]

Also resources - which are by far the coolest part of MCP. Prompts? Elicitation? Resource templates? If you think of MCP as only a replacement for tool calls I can see the argument but it's much more than that.

[upcoming-sesame]

That's not a limitation of CLIs, they can work with a different auth as well.

they are just a superior tool to MCP because the agent can write code that invokes, pipes and do many other things with the tool

[friendzis]

> If not, every API supports keys?

How would MCP help you if the API does not support keys?

But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to?

You ARE running your agents in containers, right?

[lll-o-lll]

> How would MCP help you if the API does not support keys?

Kerberos, OAuth, Basic Auth (username/password), PKI. MCP can be a wrapper (like any middleware).

> But that's not the point. The agent calls CLI tools, which reads secrets from somewhere where the agent cannot even access. How can agent leak the keys it does not have access to?

If the cli can access the secrets, the agent can just reverse it and get the secret itself.

> You ARE running your agents in containers, right?

Do you inject your keys into the container?

[Marha01]

> If the cli can access the secrets, the agent can just reverse it and get the secret itself.

What do you mean by this? How "reverse it"? The CLI tool can access the secure storage, but that does not mean there is any CLI interface in the tool for the LLM to call and get the secret printed into the console.

[_flux]

In principle it could use e.g. the `gdb` and step until it gets the secret. Or it can know ahead where the app stores the cerentials.

We could use suid binaries (e.g. sudo) to prevent that, but currently I don't think we can. Most anyone would agree that using a separate process, for which the agent environment provides a connection, is a better solution.

[e12e]

Seperate process as a seperate os user, and/or namespace.

[_flux]

I mean definitely a good starting point is a share-nothing system, but then it becomes impossible to use tools (no shared filesystem, no networking), so everything needs to happen over connections the agent provides.

MCP looks like it would then fit that purpose, even if there was an MCP for providing access to a shell. Actually I think a shell MCP would be nice, because currently all agent environments have their own ways of permission management to the shell. At least with MCP one could bring the same shell permissions to every agent environment.

Though in practice I just use the shell, and not MCP almost at all; shell commands are much easier to combine, i.e. the agent can write and run a Python program that invokes any shell command. In the "MCP shell" scenario this complete thing would be handled by that one MCP, it wouldn't allow combining MCPs with each other.

Maybe an "agent shell" is what we need.