In an organisation we can’t limit MCP access. It’s all or nothing. Everything the user can touch, the MCP can touch.
We can trust humans not to do stupid things. They might accidentally delete maybe two items by fat-fingering the UI.
An Agent can delete a thousand items in a second while doing 30 other things.
With bespoke CLI tools we can configure them so that they cannot access anything except specific resources, limiting the possible blast radius considerably.
> In an organisation we can’t limit MCP access.
Why not? I'd imagine that you could grant specific permissions upon MCP auth. Is the issue that the services you're using don't support those controls, or is it something else?
I haven’t seen a single major MCP provider that would let us limit access properly
Miro, Linear, Notion etc… They just casually let the MCP do anything the user can and access everything.
For example: Legal is never letting us connect to Notion MCP as is because it has stuff that must NEVER reach any LLM even if they pinky swear not to train with our stuff.
-> thus, hard deterministic limits are non-negotiable.
it's straightforward to spin up a custom MCP wrapper around any API with whatever access controls you want
the only time i reach for official MCP is when they offer features that are not available via API - and this annoys me to no end (looking at you Figma, Hex)
Indeed, ever since MCPs came out, I would always either wrap or simply write my own.
I needed to access Github CI logs. I needed to write Jira stories. I didn't even bother glancing at any of the several existing MCP servers for either one of them - official or otherwise. It was trivial to vibe code an MCP server with precisely the features I need, with the appropriate controls.
Using and auditing an existing 3rd party MCP server would have been more work.
That’s what we’re doing, but it’s annoying. Why can’t they just let us limit access for the official MCP easily?
Agreed. Sounds like a failure of the services, but not MCP. Can't believe in 2026 we don't have better permissions on systems like this.
“Communism can work we just did not see a good implementation of it”. If majority of implementations fail at it -> protocol is defined incorrectly. With security first approach it would not be the case.
(everything I write about MCP means "remote MCP" by the way. Local MCP is completely pointless)
MCP provides you a clear abstracted structure around which you can impose arbitrary policy. "identity X is allowed access to MCP tool Y with reference to resource pool Z". It doesn't matter if the upstream MCP service provides that granularity or not, it's architecturally straightforward to do that mapping and control all your MCP transactions with policies you can reason about meaningfully.
CLI provides ... none of that. Yes, of course you can start building control frameworks around that and build whatever bespoke structures you want. But by the time you have done that you have re-invented exactly the same data and control structures that MCP gives you.
"Identity X can access tool Y with reference to resource pool Z". That literally is what MCP is structured to do - it's an API abstraction layer.
maybe make an mcp that has whatever limitations you need baked in?
> We can trust humans not to do stupid things. hold my beer
I can definitely delete a thousand items with a typo in my bash for loop/pipe. You should always defend against stupid or evil users or agents. If your documents are important, set up workflows and access to prevent destructive actions in the first place. Not every employee needs full root access to the billing system; they need readonly access to their records at most.
These people aren’t doing bash loops, they’re regular non-technical people who just want to use an AI Agent to access services and aggregate data.
If people accidentally delete stuff, they tend to notice it and we can roll back. If an agent does a big whoops, it’s usually BIG one and nobody notices because it’s just humming away processing stuff with little output.
An accountant might have access to 5 different clients accounts, they need to do their work. They can, with their brain, figure out which one they’re processing and keep them separate.
An AI with the same access via MCP might just decide to “quickly fix” the same issue in all 5 accounts to be helpful. Actually breaking 7 different laws in the process.
See the issue here?
(Yes the AI is approved for this use; that’s not the problem here)
> These people aren’t doing bash loops, they’re regular non-technical people who just want to use an AI Agent to access services and aggregate data.
Over the last few months, this pattern of discussion has become pervasive on HN.
Point.
Counterpoint.
(Not finding a flaw with the counterpoint) "Yeah, but most people aren't smart enough to do it right."
I see it in every OpenClaw thread. I see it here now.
I also saw it when agents became a thing ("Agents are bad because of the damage they can do!") - yet most of us have gotten over it and happily use them.
If your organization is letting "regular non-technical" people download/use 3rd party MCPs without understanding the consequences, the problem isn't with MCP. As others have pointed out in this thread, you can totally have as secure an MCP server/tool as a sandboxed CLI.
Having said that, I simply don't understand yours (and most of others') examples on how CLI is really any different. If the CLI tool is not properly sandboxed, it's as damaging as an unsecured MCP. Most regular non-technical people don't know how to sandbox. Even where I work, we're told to run certain agentic tools in a sandboxed environment. Yet they haven't set it up to prevent us from running the tools without the sandbox. If my coworker massively screws up, does it make sense for me to say "No, CLI tools are bad!"?
[dead]