With AI agents, runtime is the only place truth lives

Lately, some of the most influential people in security and AI have been arguing publicly about how fast frontier AI models should be developed. While that’s an important debate with very real stakes, it's not the only one shaping what security teams have to deal with today. 

The AI agents that matter to our organizations right now have already been deployed, or are in the process of being deployed. They run in real infrastructure, hold credentials, and reach production applications. Our businesses already depend on them and won’t pause while we sort out the pace of what comes next.

So, instead of focusing on that, I’d like to explore something concrete: What actually changed underneath our security programs in the last year and, in technical terms, what it takes to get ahead.

The challenge of securing agentic AI

For most of my career, cybersecurity meant defending people and organizations, and you did that by protecting their software assets: applications, data, and infrastructure.

Software assets are deterministic. You know exactly what the software is capable of doing before it runs. That single property is the foundation beneath nearly every control security teams have built, and it’s why you can write a policy in advance. That’s also why allowlists work and baselines matter.

On the other side of that coin, you have people, and people have identities. When something goes wrong, there’s a name attached. You have an account, a session, a manager, and a chain of accountability.

An agent is neither a traditional software asset nor a person. It is software doing a job, running with human-grade abilities and access, choosing its own steps. It writes its plan while it runs, and its plan can be different the next time, even for the same request. So the two assumptions holding up our controls for people and software both break: You cannot enumerate the behavior in advance, and the identity acting on the system may very well not be the identity responsible for it.

This is a wholly different kind of thing running inside your environment. It poses a novel challenge that requires a proportionate solution.

Agents move faster than people can review by hand

AI agents act, fail, and correct themselves in seconds. In July, our threat research team discovered an operator they dubbed JADEPUFFER, the first documented end-to-end agentic ransomware campaign. A threat actor pointed their AI at a CVE and then took their hands off the keyboard while the agent ran the full campaign alone. 

To me, the most striking detail about JADEPUFFER was a login failure the AI agent triaged and fixed in 31 seconds. It diagnosed its own mistake, changed its approach, and launched a working fix in less than a minute. 

JADEPUFFER happened to be an attacker’s agent, but nothing about that speed is unique to outside threats. The AI agents that organizations deploy plan, fail, and retry at the same pace, with whatever access they’re given.

I don’t bring up these findings to be alarmist, but because of what they mean to a security team’s operating assumption. Every security program I’ve seen has a human somewhere in the loop, reviewing, approving, or escalating. Thirty-one seconds is not a pace at which people can review and still stay ahead. Neither is eight minutes, which is the time it took another AI-assisted intrusion to reach administrative access. 

This doesn’t mean taking humans out of security, but it does mean augmenting human speed so it doesn’t stand between a threat and a real-time response. Defense can’t be a step that happens after the fact. It has to be the thing that blocks or stops an action the instant it happens.

An agent's account of its own actions is not a trustworthy alibi

In late July, OpenAI disclosed that agents in an isolated evaluation environment had chained together previously unknown flaws and leaked credentials to reach another company's production systems. As a result, Anthropic reviewed 141,006 evaluation runs where its models could have obtained internet access and found three incidents in which models touched real systems. 

While the notion of AI escaping its sandboxes has driven much of the news, it's arguably even more important to look at what the models concluded about their own situation. One agent recognized that the environment it had breached was real and kept attacking anyway. Another reasoned its way back to deciding it must still be in a simulation. Only one model stopped once it understood where it was.

An agent's understanding of its own circumstances is not a control surface. If its understanding is unreliable, or its guardrails don’t stop it from conducting malicious actions, then its account of its own behavior is certainly not trustworthy. 

Most of today’s AI security tooling relies only on an agent’s logs: The prompts it received, the tool calls it says it made, and the actions it says it took. That data is valuable, as it’s the only place you can see what an agent says it was trying to do. But at the precise moment it matters most, when something goes awry, those logs lose all validity. Software that has been hijacked or is acting recklessly can forge or erase the record of what it did. 

Treated as context, an agent’s own account is invaluable. Treated as evidence, it becomes a liability. If an agent is compromised, so is its story.

Four non-negotiable properties of runtime defense for agentic AI

Runtime was once a word for insiders. It meant protecting a user or a software asset in real time, like a container running in production, without latency between detection and alert.

Now, runtime is at the center of the conversation. It’s becoming clear that runtime is the only way to understand what sophisticated and unpredictable entities like AI agents do, and also the most effective way to govern them. But for agents, runtime has to mean more than it used to.

Real runtime requires four non-negotiable properties: observing below the agent, observing inside the agent, correlating the two, and acting at the moment of execution.

1. Observe below the agent. At the kernel level, you can actually see the processes that are running, the files that are being opened, and the connections that are being made. An agent can misreport a tool call, but it can't rewrite the system call it just made. That makes kernel data the source of truth, but it's also thin on meaning. A system call tells you a process opened a connection, but it doesn't tell you why, or on whose behalf.

2. Observe inside the agent. Coding agents like Claude Code and Codex expose their own activity through facilities like hooks, configuration files, session data, APIs, and many others. That's where you see what the kernel can't: the prompt behind an action, the MCP server an agent invoked, or the web search it ran. None of this is proof on its own, as it's the layer the agent controls, but it's rich in meaning. And without it, the kernel view is a list of actions with no intent or context.

3. Correlate and enrich, don't just collect. The value comes from putting both views together, and it works in two directions. First, the inside view enriches the kernel view. A network connection from an anonymous process becomes a connection from an agent, running under a personal account instead of the enterprise one, in a session that's analyzing private customer data. Same system call, but completely different risk. Second, the kernel view checks the inside view. When what the agent reported doing and what the machine actually did disagree, that disagreement is the detection itself. It's the single most reliable signal that something is going wrong, and you can only see it if you can compare both views simultaneously.

4. Judge and act at the moment of execution. Because an agent's plan is being written at runtime, you can't enumerate actions in advance. The same action can be trivial or catastrophic depending on what the credential behind it reaches right now. Reading a key in a test harness is noise, but reading the key that administers production is an incident, and those keys and environments are constantly changing. Only the correlated, enriched view can tell those two apart in the moment, and it has to be able to block or stop an action the instant it's judged rogue or malicious.

Sysdig has spent a decade on a version of this problem, following software in motion wherever it runs. The lesson from that decade is that the kernel alone was never enough. System calls became useful when they were married to context from the container, Kubernetes, and the cloud, so a connection made by a process became a connection made by the payment service running in production. Agent harnesses are the newest, richest source of that context. What's new is the shape of the workforce. Where are your AI agents, what can they do, what did they actually do, and which human is accountable for them?

Regulators are moving in the same direction, too. The EU AI Act, for instance, will require high-risk AI systems to automatically log events across their lifetime, in some cases down to which person verified a result. Those logs are only worth having if they're grounded in what actually happened, and not just what the agent reported.

AI agents start on endpoints, but the blast radius lives in the cloud. And none of this works as an endpoint view and a cloud view stitched together after an incident has occurred. It has to be one view that follows the agent in real time.

Governance that cannot constantly see what is happening is only governance in theory, and runtime that can only see what an agent says it did is runtime in name only.

‍