logoalt Hacker News

bostiktoday at 6:34 AM1 replyview on HN

I would say the truth[tm] is likely somewhere in the middle ground. Right now corporate MCP deployments happen to satisfy two very specific stopgap niches:

    * Internal services that never had real APIs are getting them retrofitted via the MCP layer
    * MCP servers can run with dedicated service accounts that assume-role to a safe(r) subset of the calling user's permissions
The first one is a business benefit. Enterprises tend to have a lot of data siloes, and coordination between teams/departments/units just to learn that a given data set exists takes a LOT of time - even before you start to arrange suitable access to any of them.

The second one addresses a much deeper architectural chasm. We want to have our agents carry nearly-the-same-but-not-the-most-dangerous permissions as we do. No regulated business can risk unleashing agents with zero judgement capacity to wreck their systems, and on the other hand the existing identity systems are not geared for real-time dynamically adjusted user permissions. The need for so called "agent-aware IAM" is urgent. So instead of letting users connect to the internal APIs directly with their full suite of powers, MCP servers act as stand-ins for API gateways.

MCPs are not as flexible as full-fledged CLI tools, and that's a bit of a shame. But they can also become identity-aware proxies that enforce the intended permissions for agent-safe use. It will probably take years before IAM systems can adapt to the needs of the new world, and it will take another DECADE after that for the improved IAM systems to become universally available across the larger enterprises. So in a big way I agree with you:

> MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.

"Workable" is a load-bearing term. MCP servers are by no means perfect, but they are good enough for specific needs and allow to move the balancing point as needed while the world catches up.

I'm an engineer and prefer CLI or raw API access 99% of the time. But I also have decades of scars from infosec. The single biggest security threat for a business used to be an employee who could not get their job done. They found ways to work around the roadblocks. These days the single biggest threat is an employee who can not get their job done, but has an infinitely patient agent with vast latent capabilities at their disposal.


Replies

bluegattytoday at 2:36 PM

So this is thoughtful - but - MCP isn't actually a very good solution for corporate automation either.

Corporate automations face the same problems human driven agents use:

+ The 'tool' section of the chat is not the right place, and it's too limiting + The very concept of MCP server introduces a brittle layer - for what purpose?

CLI for local calls, REST for remote.

That's it.

We build security around that the same way we would otherwise.

Now -> 'better / standard' json type calling for both of those!

Sure! 'Agent Calling API' or something. Yes.

'Agentic Identity Standard'? Yes to that as well.

But MCP was 'the right solution for a period in LLMs that has been superceded.

If MCP did not exist today - we would not invent it. That's the strongest argument I think.