Hacker News Reader

Comment by isbvhodnvemrwvn | Hacker News Reader

It's significantly more difficult to secure random clis than those apis. All llm tools today bypass their ignore files by running commands their harness can't control.

View on HN

I'm fuzzy when we're talking about what makes an LLM work best because I'm not really an expert. But, on this question of securing/constraining CLIs and APIs? No. It is not easier to secure an MCP than it is a CLI. Constraining a CLI is a very old problem, one security teams have been solving for at least 2 decades. Securing MCPs is an open problem. I'll take the CLI every time.

You should read the article, it explains very well why that is completely wrong. cLIs don’t have a good story about security, are you serious?? They either use a secret , in which case the LLM will have the exact same permission as you as a user, which is bonkers (not to mention the LLM can leak your secret now to anyone by making a simple curl request) and prevents AI auditing since it’s not the AI that seems to use the secret, it’s just you! And the other alternative is to run OAuth flows by making you authorize in the browser :). That at least allows some sort of auditing since the agent can use a specific OAuth client to authorize you. But now you have no ability to run the agent unattended, you will need to log in to every possible CLI service before you let the agent work, which means your agent is just sitting there with all your access. Ignorance about best security practices really makes this industry a joke. We need zero standing trust. Auditability. Minimum access required for a task. By letting your agent use your CLIs as if it was you, you throw away all of that.

OP never mentioned letting the agent run as him or use his secrets. All of the issues you mention can be solved by giving the agent it’s own set of secrets or using basic file permissions, which are table stakes.

Back to the MCP debate, in a world where most web apis have a schema endpoint, their own authentication and authorization mechanisms, and in many instances easy to install clients in the form of CLIs … why do we need a new protocol, a new server, a new whatever. KISS

    > OP never mentioned letting the agent run as him or use his secrets

That is implicit with a CLI because it is being invoked in the user session unless the session itself has been sandboxed first. Then for the CLI to access a protected resource, it would of course need API keys or access tokens. Sure, a user could set up a sandbox and could provision agent-specific keys, but everyone could always enable 2FA, pick strong passwords, use authenticators, etc . and every org would have perfect security.

That's not reality.

Just use a custom PATH and run in a chroot jail.

CLI sandboxing is a solved problem compared to whatever MCP is.

I don't think so. There is no MCP standard for authentication, our infosec banned MCP because of that.

It's right there in the docs and it's just OIDC + OAuth: https://modelcontextprotocol.io/specification/draft/basic/au...

While the spec includes OAuth 2.1 now, that's only half the story. The real question is where the credentials live.

When your agent calls a CLI or curls an API, it uses credentials stored on the developer's machine.

For one person that's fine. But for 50 agents across a department, each needing keys for Slack, Jira, GitHub, your CRM, and a dozen internal APIs? You've recreated the pre-SSO world, except access is autonomous and at machine speed.

Remote MCP servers (streamable HTTP, not stdio) change that. The agent authenticates via OAuth/SSO, the server holds the downstream keys, and the user never sees them. Disable the SSO account and every agent loses access.

This is the same pattern as centralizing database credentials instead of baking them into every microservice config, just on a different layer.

Longer version: https://dev.to/dennistraub/missing-from-the-mcp-debate-who-h...

Yes; I made the same point in my write up.

The auth story is heavily overlooked by most folks that are solo-vibing and then think that advice, the tools, and the practices that work for 1 works for a team or org.

Reply on news.ycombinator.com