The way every agent framework handles MCP is a latent security problem | Hacker News Reader

The way every agent framework handles MCP is a latent security problem

2 pointsAn0n_Jon6 comments

When you configure MCP servers in any agent framework today, they all connect at session init and stay connected for the entire session.

If your agent is set up with 12 integrations, all 12 are live from the moment the session starts. Holding connections, processes, and attack surfaces. Even if 9 of them never get called.

If you're hosting your own MCP servers, you're paying for all of them 24/7 for no real benefit.

The right model is closer to how ephemeral infra works: spin up on tool call, tear down when done. Exposure window is exactly as wide as the operation that opened it.

Docker's MCP Gateway actually does something like this at the infra layer, container per call, destroyed after, but that's a deployment concern. The agent runtime still assumes everything is connected and waiting.

This is one of the features built in Orloj [0]. MCP servers summoned on demand rather than pre-connected long running processes.

Curious whether people running agents in production are actually hitting this, or whether it's being absorbed somewhere in the infra layer without much visibility.

[0] https://github.com/OrlojHQ/orloj

Yeah, I hit this. I run an MCP server that talks to a corporate messaging API — if it stays connected the whole session, any hallucinated tool call can fire off messages to an entire org while the agent is doing something unrelated.

There's no real reason that connection needs to stay open the whole time. Feels like overkill.

Read-only stuff is probably fine staying persistent, I guess. Anything that sends or mutates state feels different though.

MCP doesn't really have a way to express that kind of boundary per tool, so the runtime can't do much with it.

Haven't tried Orloj yet but "summoned on demand" sounds closer to what I'd want.

Yeah, agreed it feels like overkill keeping the resource running if nothing is calling it. Even with read only you still have the issue with wasted resources but I get what you mean.

Orloj is a runtime with policies you apply as guardrails to keep agents in check for tools and other limits which all happen at the runtime level. And building out the tooling it just made sense to containerize tools so they can be spun up on demand and stay alive when needed and spin down after.

The boundary problem you're describing is also a trust issue, not just a connection lifecycle one. Even with ephemeral connections, you still need to know whether the agent making the call should be allowed to make it at all.

We use reputation-based admission control in production, agents below a certain trust threshold simply cannot invoke sensitive tools. The hallucinated tool call scenario you described is exactly what this prevents, independent of whether the connection is persistent or on demand.

agentveil.dev if curious.

Yeah the governance is also built into Orloj as well as applied policies. More so acting as guardrails at the runtime level. Ill take a look at agentveil and would love to know your thoughts on Orloj as well.

The connection lifecycle is one problem, but even with ephemeral connections you still have the authorization gap — MCP has no built-in concept of per-tool, per-user permissions. We ran into this building an MCP aggregator (ToolMesh, Apache 2.0) where 15+ backends connect through a single gateway. Our approach: OpenFGA for fine-grained ReBAC authorization on every tool call, plus an Output Gate that can run e.g. DLP policies before results reach the LLM. The attack surface isn't just about which servers are connected — it's about what each agent is allowed to do with them. https://toolmesh.io

Yeah, this is the reasons why Orloj has built in policies which are applied to your resources and managed at the runtime level. This way you can allow only certain tool usage per agent for a more fine grained setup.

Reply on news.ycombinator.com