MCP has a great advantage over agent using cli: MCP is much easier to secure so that it's hardwired that the agent can only call the pre-configured MCP server. We run our agents so that they don't have access to public internet, so they could not run any cli commands. It's all either built-in agent tools, or 3rd party mcp servers. The agents never have access to any credentials, which makes them much more safe to use than a claude code running in yolo mode with fetching random cli binaries from the web.

Can you not just install/ restrict the available CLIs in the same way you do with MCPs?

Or what else am I missing about why MCP is more secure than a CLI?

MCP allows you to easily separate API requests from their access tokens, so that the LLM only has access to the requests part. Giving an LLM CLI access removes all boundaries, anything goes.

EDIT: to add an example: I have a personal claw agent that I only use CLI, I don't care. But I'm also building an agent inside a company product, and there we use MCP all the way.

You can easily do this with simple Unix `chmod x-rw` on a wrapper that makes HTTP requests, adding the access token as it does.

Another examole which is trivial with MCP but hard with cli binaries: blocking certain commands, such as write operations from the agent. With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.

Just use scopes in the API key the agent uses? If you’re exposing something publicly that should be a requirement anyways.

That’s how I use gh, aws, etc. No need to modify any of the code in the cli, they’re just wrappers.

I want the harness to use read freely but require confirmation for write.

Access control is the operating system's job, and modern OSes already provide plenty of great tools for doing that.

Just use the existing sandboxing infrastructure like bubblewrap, seccomp, etc. I have way more faith in that than in something than some regex-based blocklist.

With MCP your client can easily have a blocklist for commands, but with cli you would need to code custom logic for each cli separately.

Nah. Just don't let your model do anything potentially destructive until three or four other models have vetted the proposed action.

Filtering individual commands can never provide more than the shallowest semblance of security. If a smart model is hellbent on deleting your production database, it will write its own Python program to do it if the usual commands are blocked.

How do you ensure the cli can use the auth without knowing how to read it ? It’s potentially a bearer Token

[dead]

It is crazy how the preferred way or securing AI are vibe coded MCP servers which at the same time do access control, credentials handling and HTTP server/client boilerplate. Want to use a new API: just vibe code a new MCP you won't fully review. It is hardly better than yoloing. The security critical parts needs to leave MCP and be integrated with, or be in front of, the API in a way humans will understand and review.

Are there actual people suggesting this or did you combine multiple posts that were arguing different things?

The parent suggests MCP as a way to secure credentials and enforce guardrails, and sibling comments iterate on this. I might be reading a bit between the lines with my comment, but did not intend to derail the discussion.

But the parent who suggested MCP for security didn't say anything about vibe coding it. The person who talked about vibe coding an MCP was the one saying MCP isn't very useful.

I think that’s exactly right: MCP provides a capability security model for agents.

How in the world MCP is going to be more secure? It introduce a big surface layers for injection attacks and supply chain attacks..

To be devil’s advocate: if you are just running commands with bash or power shell or the like there is no protection. You might have some rules that ban

rm -rf ~

but sandboxing in general is not an easy problem.

It is. The issue is all the weird constraints that usually come up with it. Like I want to use my favorite code editor, I want easy copy and paste, or I can’t bother setting up a separate user account on my computer.

On unix, you can easily create a new user account, switch to it (or ssh or setup vnc), and run the tool there. If users are enough for servers on the internet, they can be for your workstation (unless there’s something like copyfail, but you can make do with a vm then).

[dead]

[dead]