alt Hacker NewsI think there are some primitives for agents that need to be built out for better security and being able to reason about them.
Agents run on infra, they have network connectivity, they have ACLs and permissions that let them read+write+execute on resources, they can interact with other agents.
To manage them from both an infra and security perspective, we can use the existing underlying primitives, but it's also useful to build abstractions around them for management, kind of like how microservices encapsulate compute+storage+network together.
I think of agents as basically microservices that can act in non-deterministic ways, and the potential "blast radius" of their actions is very wide. So you need to be able to map what an agent can do, and it's much easier to do that if there are abstractions or automatic groupings instead of doing this all ourselves.
Replies
Right, those abstractions and controls already exist in the Kubernetes ecosystem. I can use one set of abstractions for everything, as opposed to having something separate for agents. They are not that different, the tooling I have covers it. There are also CRDs and operators to extend for a more DSL like experience.
tl;dr, I don't think the shovel analogy holds up for most of the Ai submissions and products we see here.
[dead]
The "non-deterministic microservices" framing is exactly right and I think most infra teams underestimate how much that changes things. With a normal service, you can map inputs to expected outputs and write tests. With agents, the blast radius is probabilistic and context-dependent.
The monitoring problem alone is closer to fraud detection than traditional APM. You're not looking for "is this thing up," you're looking for "is this thing subtly wrong in a way that compounds over the next 10 steps."