Defending the battlefield: Stateful detections for an agentic threat landscape

A quick response is essential to defend cloud-native environments.

We have been commenting for a while on how cloud security is reaching the limits of human scale. There was a stark change in early 2026 — attacks like React2Shell are happening only hours after the vulnerability was made public, and this wasn’t an isolated case. The Sysdig Threat Research Team (TRT) clocked the same pattern for several other vulnerabilities as well against AI infrastructure tools. Not only that, but attacks are getting more automated… and even AI-driven from end to end. We’ve observed AI-assisted attacks that achieved admin access in just eight minutes and credentials stolen in three minutes. The Sysdig TRT also reported on JADEPUFFER, the first agentic ransomware operation to autonomously run a destructive database extortion playbook. 

That’s why runtime security is becoming increasingly important as a safety net. You need quality runtime detections to enable fast automated responses.

Stateful detections reduce noise

Security teams often struggle to act in time, as they find themselves buried under a list of issues, spending too much time triaging false positives and investigating each security event.

Traditional detection engines approach security events in a vacuum. They will, for example, flag when a terminal shell is open on a container. However, they lack the context to tell whether this was caused by a developer debugging an app or by a malicious actor. This investigation is left for a security engineer, who can see other alerts and trace what happened.

Stateful detections completely change the game:

• A single detection correlates several actions to reconstruct what the actor did, providing higher fidelity that the detected behavior is malicious.
• With this context, the detection can tell separate legitimate actions from malicious behaviors before it reaches the analyst.
• As a result, stateful detections reduce the number of alerts to triage. (noise reduction)
• Their alerts provide all these correlations, speeding up the investigation.

So, in our “opening a shell on a container” example, you could say that this event itself may be routine for a developer debugging a workload. Also, writing to /tmp can be a legit action. However, opening the shell, downloading a binary to /tmp, and then executing it is a flow that almost certainly corresponds to an attack.

Anatomy of a stateful detection

Stateful detection on Sysdig’s Falco agent looks like this:

This rule detects when a terminal shell opens in a container, and then it’s used to install software with a package manager.

Observations are a Sysdig Secure extension to Falco rules, and they represent stateful evaluations:

- macro: spawned_process
  condition: (evt.type in (execve) and evt.dir=< and evt.arg.res=0)

- observation: Launch Process
  condition: spawned_process
  source: syscall

You then define how to tell if two observations are related; for example, if they have the same process ID:

- obs_link_fields: same_session
  fields:
    - [proc.sid, proc.sid]

Then, you can use obs.occurs and obs.link on a Falco rule to use the observations:

- rule: Spawn Package Management Program Below Container Exec
  desc: Detect an attempt to run a package management program from a container exec
  condition: >-
    obs.occurs["Terminal shell in container"]=true and
    obs.link["Terminal shell in container-->Spawn Package Management Program, same_session"]=true
…

You can learn more about stateful detections in:

• How to detect multi-stage attacks with runtime behavioral analytics
• Observations reference in the Sysdig documentation

Adoption of stateful detections is high

In our 2026 cloud-native security and usage report, we found that 70% of organizations use stateful detections. And those who have implemented them are doing so across 91% of their cloud environments.

That kind of adoption is proof of how game-changing this new paradigm is in reducing noise and speeding up investigations.

Automated response needs trust

Organizations understand the role of automation in responding quickly to security events. However, they don’t feel confident in implementing automated responses with the potential to catastrophically interrupt business operations.

As per our 2026 cloud-native security and usage report, 75% of organizations have automated response actions configured for various policies. However, only 27% of organizations have them enabled.

That gap can be a risk in itself. Agentic threat actors (ATAs) are moving quickly and security operations that pause for human decision-making end up falling behind the attacker’s clock. 

Stateful detections may be what organizations need, as they offer higher-quality signals with better detection and fewer false positives. Once people trust the signal, they will trust the response. In fact, we see a promising future if we focus on that 27% who have enabled automated responses.

We’ve observed a 140% increase in organizations using the kill -9 command to kill a process following a threat detection alert. And when it comes to containers, there’s a 28% increase in the number of organizations that favor killing a container as opposed to pausing or stopping.

This is a sign of maturity for these teams. First, they are able to kill processes and containers without completely disrupting their services. Second, they are prioritizing security over the operational convenience of troubleshooting a running, compromised container.

Conclusion

Stateful detections are becoming an essential tool for runtime security. They provide higher-quality detections, right at a time when organizations need a confidence boost to implement runtime security. ATAs are operating in the wild right now, and defenses built for human-paced threats won’t hold against AI-driven threats. 

The 2026 Cloud-Native Security and Usage Report

Read the report