Lessons from securing AI systems at runtime (agents, MCPs, LLMs) | Hacker News Reader

Lessons from securing AI systems at runtime (agents, MCPs, LLMs)

1 pointjoyjeetdan3 comments

Over the last year, we noticed a pattern while working with teams deploying AI in production.

The hard problems weren’t model choice or prompt quality. They showed up after deployment.

Agents started calling tools nobody remembered wiring up. LLMs accessed internal APIs through chains that weren’t obvious from logs. Execution identity diverged from user identity. MCP servers became quiet but critical control planes.

Most existing security assumptions break in these scenarios because they assume:

static services

clear ownership

single-hop execution

pre-defined boundaries

AI systems violate all of those.

We recently spent a week documenting and shipping solutions around runtime visibility and governance for AI systems, focusing on how agents, MCP servers, APIs, and models actually behave once live.

Instead of high-level frameworks, we tried to answer practical questions:

What exists right now?

Who is acting on whose behalf?

What tools are being invoked, and in what sequence?

Where does data flow during real executions?

We wrote up the learnings and what we built here: https://www.levo.ai/resources/product-release/launch-week-2026-recap

Not posting this as a “launch”, more as a discussion starter. Curious how others are thinking about securing AI systems once they stop being demos and start being infrastructure.

"Agents started calling tools nobody remembered wiring up"

This is very familiar to me. I have seen this problem before. Because AI is often a network of microservices and follow service mesh patterns, there is an inherent ability for agent workloads to reach other agent workloads even if they weren't designed for that. To me, that is an 'authorization' problem and traditional solutions focus on policies to control authorization. But an authz policy approach is avoided because it involves a central server, additional latency, and is a single point of failure.

I found a different approach that restricts the authorization of agent interconnections to a pre-defined topology and has strict access controls per agent during runtime use dynamic access credentials unique to the agents in the topology. There is no central server.

And the dynamic access credentials guarantee the control and security of the data flows over the authorized AI topology during runtime.

I think about securing AI systems a lot. And I am amazed that people expect conventional API security to protect AI systems when these same solutions are failing tremendously for every other kind of API. In my opinion, AI is a leap-ahead technology that needs a leap-ahead security approach rather than the conventional API security methods.

Happy to discuss further

One thing that surprised us: gateways and logs were useful, but insufficient. The real gaps appeared when execution spanned multiple agents, tools, and identities over time. Would love to hear how others are handling this today.

So true — once multiple agents and tools are involved, it becomes a system-tracking problem, not just a logging problem.

Reply on news.ycombinator.com