JADEPUFFER: What the first agentic ransomware teaches us about AI assurance
Sysdig's Threat Research Team documented the first end-to-end, LLM-driven ransomware operation. Their report is the definitive account, and worth reading in full. This post adds one layer on top of it: the assurance lens. We decompose the incident into stages and map each to a specific, cited control, the assurance failure behind it, and the validation evidence an organization should be able to produce. And we publish the same map as machine-readable JSON, so a GRC platform, a SIEM, or an agent pipeline can consume it directly.
The lesson is not simply that AI can automate ransomware. It is that autonomous systems need verifiable evidence of authority, intent, scope, and runtime behavior before they act. The harder problem is proving, continuously and automatically, that your own autonomous systems cannot behave the same way.
What happened, in brief
Ransomware has historically depended on human operators, or at least human-authored playbooks. Sysdig assesses JADEPUFFER as the first documented end-to-end LLM-driven extortion operation: more than 600 self-narrating payloads that diagnosed and fixed their own failures in as little as 31 seconds. It entered through an internet-facing Langflow instance (CVE-2025-3248). Langflow is a widely used open-source framework for building LLM and agent applications; this deployment held provider API keys and cloud credentials in its environment. The agent swept those secrets, pivoted to a production MySQL and Nacos server, and encrypted 1,342 configurations with a key it generated, printed once, and never saved. Based on Sysdig's observed artifacts, payment would not enable recovery.
The entry point is the part worth sitting with. The weapon and the target were both AI infrastructure.
The map, at a glance
This is an Incident-to-Assurance Mapping, the method behind these briefs: decompose an incident into attacker stages, and map each to its assurance failure, the control that addresses it, and the validation evidence that proves it holds. Read Sysdig for the forensics. Read the table below for what to govern. Each row is an attacker stage, the assurance failure that enabled it, the Apeiris control that addresses it, and the evidence you should be able to produce to prove it holds.
| Attack stage | Assurance failure | Control | Evidence to produce |
|---|---|---|---|
| Loading the map... | |||
The control IDs above are Apeiris-native, and each is mapped to cited external frameworks (NIST, OWASP, ETSI, ISO, and others) in the domain JSON it links to and in the downloadable artifact. Each control is also machine-addressable through a stable URI (apeiris://<domain>/controls/<ID>), so governance tools, autonomous agents, and evidence pipelines can reference the same control without translation.
The assurance lens
Security asks whether controls exist. Assurance asks whether they can be continuously demonstrated with objective evidence. Documentation is no longer enough for autonomous systems: the evidence must be generated as the system acts. Because agentic systems operate at machine speed, their assurance must be machine-verifiable.
Most of the industry response to an incident like this stops at posture: patch faster, do not expose services, use runtime detection. That advice is correct, and it is not enough, because it does not tell an operator which specific, testable control turns each attacker step from a success into a caught event, or what evidence proves it. Assurance is the discipline of naming those controls and proving they hold. Three things we try to add here:
- Specificity over hygiene. Not "harden your stuff," but a named control per stage, each carrying a validation objective, the required evidence, and a machine test you can run.
- The evidence reframe. Sysdig's sharpest finding is that the agent narrated its own intent, which gives defenders a new signal. The assurance version of that same observation: legible intent is exactly what an assured agent should be signing as evidence at the moment it acts. JADEPUFFER's intent leaked out by accident. An assured agent emits it by design, as a verifiable record that the actor, its authority, and its behavior were valid when it acted.
- AI infrastructure is its own attack surface. An orchestration server that holds credentials, an agent framework, an MCP server: these are not just "web services," they are agentic assets with their own control set.
One honesty note we hold to: mapped is not satisfied. The controls here address each stage. We make no claim that any target satisfied them.
Stage by stage, with the control, why it matters, and the evidence
Loading the map...
Questions every CISO should ask after reading this
- Which AI-orchestration platforms are internet reachable?
- Can we prove none of them hold long-lived provider credentials?
- Can we prove our agents execute inside enforced sandboxes?
- Can we prove agent intent is logged and attributable?
- Would we detect a JADEPUFFER-style campaign before the first destructive action?
- Can we automatically produce validation evidence for every answer above?
The Agentic Infrastructure Exposure Check operationalizes these questions as a two-minute assessment, mapping your answers directly to the controls and validation evidence described above.
control-map.json): attacker stage, assurance failure, control URI, validation objective, and required validation evidence, consumable directly by GRC platforms, detection pipelines, or autonomous agents. Pull it into a GRC register, a detection-engineering backlog, or an agent that checks your own orchestration hosts against it. Or run your declared stack through the Apeiris Advisor to see which of these controls your deployment already covers. We also built a focused companion for exactly this: the Agentic Infrastructure Exposure Check. Answer a short set of questions about your orchestration deployment and get the specific controls that close your gaps, with the validation evidence to produce.Explore the controls: Agentic domain, Security domain, Resilience domain.