Runtime Context for AI Agents

Runtime Context for AI Agents

Sep 22, 2026

Guest:

  • Emanuela Zaccone

For an AI agent working with Kubernetes, more context can become more noise.

Emanuela Zaccone of Sysdig outlines the reasons why useful Kubernetes AI must have runtime context, causation, and specific guardrails if it is to progress from providing explanations to carrying out remediation.

In this interview:

  • How K8sGPT, kagent, and MCP fit into the Kubernetes AI landscape

  • Why runtime context matters more than raw alert volume

  • How agents should handle uncertainty, confidence, and root cause analysis

  • Where human approval, reversible actions, and least-privileged permissions belong

Subscribe to KubeFM Weekly

Get the latest Kubernetes videos delivered to your inbox every week.

or subscribe via

Relevant links

Transcription

Bart Farrell: What three emerging Kubernetes tools are you keeping an eye on?

Emanuela Zaccone: There are at least three I'm watching. Spoiler: none of them is the tool, meaning none of them is the only one that will provide all of the value or the full answer. If you look at those on a maturity range, one of the ones I'm looking at is K8sGPT. It uses LLMs to read the cluster and explain what's breaking in plain language, which is really relevant when you're trying to deal with what's happening up there and figure out what the issue is. That's why I really like that one. Second is kagent. It's a sandbox, part of CNCF. There you can push tasks into autonomous agents, and then they run inside the cluster and take multi-step action. So it's a step farther than the first one. Probably the third one that I think is absolutely key to all of the conversation around AI is MCP. It started as a standard, or at least that was the claim. But actually, it is the standard. It's now the standard interface for how all of these agents work. So I think it's something that we should carefully take a look at and see how that evolved. The reason I told you none of them is the answer right there is that when you get an explanation of what's happening on Kubernetes, you're almost this close to solving the issue because you are getting there. The real frontier, where I think these tools in general, not just the three we mentioned, but all Kubernetes tools should focus, is figuring out how to make autonomous decisions based on what's really happening at runtime, based on all of this information. Tools that go in that direction are probably the most interesting ones to look at. But I know there are plenty of them out there, so I'd be curious to also hear what else might be interesting out there. That's my short list though.

Bart Farrell: All right. Let's say a Kubernetes security alert fires in production. Before an AI agent can tell you what actually matters, what evidence does it need to correlate? Runtime behavior, vulnerabilities, workload identity, network activity, deployment history, cluster state. And how do you stop more context from simply becoming more noise?

Emanuela Zaccone: More context is more noise. Everybody was thinking, okay, I need to get as much context as possible. The point is that with AI, the more context you get, the more noise you're bringing in. So I don't need a dump of information. That doesn't help me. What I need is relevant information with runtime as the spine of it, because I don't need to know everything that is happening. Even in terms of the identities and vulnerabilities you mentioned, just tell me what is happening at runtime. If I have 100 vulnerabilities I'm looking at, but only a small percentage of them are about workloads loaded in memory, or related to images that are network exposed or that are currently used, that's what screams urgency, not just knowing that I have tons of them. Just tell me what is happening at runtime, what is potentially more urgent for me to look at, and let me focus on what matters to me. So at this point, context isn't the win. The right context is the win. Otherwise, more context, as you said, becomes more noise and doesn't help me.

Bart Farrell: AI is pretty good at summarizing alerts. Root cause analysis is much harder. In a Kubernetes incident, how do you get an agent from these things happened at roughly the same time to this change actually caused the problem? And what should the agent do when the evidence isn't strong enough to know?

Emanuela Zaccone: At this point, with how much AI has advanced, correlation is cheap. It's easy to say which events are related, why they are related, and what is happening there. The hard part is causation. That's also what makes the difference between a good agent and agents that can actually help you out. Let me explain what I mean. For example, just telling you, these events are relevant because they're happening at the same time and they share some commonalities, like they happen on the very same cluster or they are related to the same identity or the same person. Okay, that's good. But the why piece of the story, anchoring that change to a timeline, to a specific runtime process, to the process tree, not just co-occurrence. That's what makes the difference. And when the evidence is thin, the agent should surface its confidence and tell you that there might be uncertainty. By nature, AI is always trying to give you an explanation. If it doesn't know the root cause, it will make it up. Just to tell you, okay, it depends on this. I believe that very good agents should be designed to tell you when they do not know. Since we are talking security, I don't need a made-up justification for events that might be correlated. I just need to know when they do not correlate and when correlation is uncertain. That's why I was saying correlation is cheap, because it's very easy to get there. But having the ability to get to the real and relevant correlation and know when that really matters, that level of confidence is a feature and that's what makes the difference between a good agent and a bad one.

Bart Farrell: Where should an AI agent's authority stop in a production Kubernetes environment? Emanuela, can you walk me through the progression from explaining a problem, to recommending a fix, to opening a PR or ticket, to actually taking an action like isolating or terminating a workload. What has to be true before you allow each step?

Emanuela Zaccone: One of the things that I always discuss with customers and with people in the industry working on this topic is that the relevant thing is defining the guardrails that we want to put in place and at what exact moment. What they expect from an agent is that it should investigate at machine speed, but act with human trust. That means, for example, let's assume I'm investigating a runtime event or a vulnerability. The very first thing I want to do is get an explanation. And it's good, the explanation is read-only. It's perfect. It can get the context, what is relevant, all the information that I need to know, and gather all of that context for me. It's already saving me time. So that's absolutely good. It's okay. Then there is a second step where after gathering all of this context, what I'm expecting is a remediation strategy or assessment of what I should do next to reduce my risk. The point is that in this context, the human in the loop decides if this is relevant and what to do next. And of course, at that point, the very next thing I should expect would be to open a PR or a ticket. Here, we start having some very specific guardrails in place, not just that I need to be part of this decision, but that this action should also be reversible. And this is absolutely key. And then, once this is in place, the very last thing will be to decide what remediation, what fix to apply, or decide to go for actions like isolation or termination, at that point I should be very much in the loop as a human or there should be a very high confidence and well-scoped suggestion from the AI. Long story short, before I allow any agent to act, there must be very specific policy guardrails that are in place, least-privileged permissions, a certain confidence threshold that I need to define. So that, of course, I will gather all of the context that I need to make a decision, going to the very action point where I need to be, but I still need to be part of that, as a human. And in general, before each step, what needs to be true is that I need to have proportionate permissions for the agent, the guardrails we mentioned, and this should be clear to everyone in my team and my company. There is no good AI without these guardrails in place.

Bart Farrell: What's next for you? What are you going to be working on next?

Emanuela Zaccone: Right now, we've evolved a lot. The last thing I worked on was a fully headless cloud security suite. It was moving toward customers that are very advanced in AI. I think we just scratched the surface. The more we see AI evolving, the more we see workflows and needs coming up. What I'm observing, especially working closely with customers, is that for probably the very first time, in the history of tech, both as vendors and users out there, so customers as users, we are all sitting on the same side. We are both builders. So when I say what's next, it's not what's next just for me, but what's next for the industry is that we will see AI and in general the use of AI for security advancing at a pace that we will see the impact of very soon. We are all building toward a future where not just attackers, but also defenders are building their own solutions in their own custom way. And I can't wait to see what's coming next.

Bart Farrell: How can people get in touch with you?

Emanuela Zaccone: Definitely via all Sysdig channels. Use the available ones like LinkedIn or our presence on X or elsewhere online. Or directly find me on LinkedIn and let's talk AI.

Subscribe to KubeFM Weekly

Get the latest Kubernetes videos delivered to your inbox every week.

or subscribe via