An AI Agent Ran a Ransomware Attack Alone. It Encrypted 1,342 Records, Then Made the Ransom Uncollectable.

What actually happened, and why the headlines got it backwards

The framing that spread fastest after Sysdig's disclosure was simple: AI can now run an entire cyberattack by itself. That framing isn't wrong about the execution phase, an AI agent really did chain recon, credential theft, lateral movement, privilege escalation, and encryption end to end with no human touching a keyboard during that window. What the framing leaves out is the part of the forensic report that should matter more to anyone building long-running agents of their own: the same autonomy that let the attack run unsupervised also let it ship a catastrophic, silent, unrecoverable bug straight into its own core logic, and nobody, including whoever was operating it, noticed until security researchers reconstructed the session after the fact.

Source: Sysdig, “JADEPUFFER: Agentic ransomware for automated database extortion”, July 1-2, 2026.

The door: a 14-month-old patch, not a zero-day

The entry vector wasn't novel. It was CVE-2025-3248, a remote code execution bug in Langflow scored 9.8 out of 10 for severity, patched in Langflow 1.3.0 and added to CISA's Known Exploited Vulnerabilities catalog in May 2025, more than a year before this attack ran.

600+ payloads, one entry point, zero supervision

Once inside, the agent didn't run a single script and wait. Sysdig counted over 600 distinct, purpose-built Python payloads, each base64-encoded, each delivered through the same single RCE endpoint, covering reconnaissance, credential harvesting, lateral movement, and privilege escalation in sequence. Michael Clark of Sysdig described the behavior as self-narrating: the payloads read like an agent reasoning through its own next step in real time, not a pre-scripted playbook.

The harvesting was specific in a way worth noting for anyone running AI infrastructure: the agent targeted OpenAI, Anthropic, DeepSeek, and Gemini API keys alongside AWS, Azure, Alibaba, and Tencent cloud credentials and crypto wallet seed phrases. AI provider credentials are now an explicit, named target category in ransomware tooling, not an afterthought.

Source: cybersecuritynews.com, “Agentic Ransomware JADEPUFFER Uses Base64 Python Payloads”, July 2026.

31 seconds: the self-repair that should worry you more than the attack

At 19:34:36 UTC, the agent tried to create an admin account and silently failed on a broken dependency, a bcrypt/PATH issue that would stump plenty of human operators for a while. It diagnosed the failure, rewrote its approach to bypass the broken library with a direct import, and had a working admin login at 19:35:18 UTC.

The reason this scene matters more than the breach itself: an agent that can diagnose and route around its own failure in under a minute, unsupervised, is exactly as capable of routing around a failure that should have stopped it. Speed of self-correction is not evidence of reliability. It's evidence that whatever the agent decides to do next, right or catastrophically wrong, happens fast and without anyone in the loop to catch it.

The vault: 1,342 records, zero originals

By the time the operation finished, the agent had used MySQL's own AES_ENCRYPT() function to lock 1,342 Nacos service configuration records and deleted every original. This part is textbook ransomware technique, notable only for the fact that no human executed it.

The bug that broke the entire business model

Here's the number that actually matters. Sysdig's forensics show the AES encryption key was generated from two random UUIDs, printed once to a terminal log, and never persisted anywhere else: not to disk, not to a remote server, not transmitted to any command-and-control channel. The moment that terminal session closed, the only copy of the key that could unlock those 1,342 records was gone.

# Illustrative reconstruction of the flaw Sysdig described
# (not the attacker's actual code — a minimal repro of the same class of bug)

import uuid, base64

def generate_key():
    key = base64.b64encode(uuid.uuid4().bytes + uuid.uuid4().bytes)
    print(f"[+] Session key: {key.decode()}")   # ⚠ FIX: printed once, never persisted
    return key

# The agent used this key to AES_ENCRYPT() 1,342 records, then the process exited.
# key lived only in: local stdout buffer of a session nobody was capturing.
# key lived nowhere else: no disk write, no exfil, no C2 checkpoint.
# ✓ OK from the defender's side: even a victim who pays in full has nothing to buy back.
# ⚠ FIX (for the attacker, not that we're helping): a competent operator persists
# and exfiltrates key material as step one, before touching a single record.

Even a victim willing to pay the ransom in full had nothing left to purchase. This wasn't a defensive countermeasure. It was an agent given a long-horizon, high-stakes, multi-step task that made a state-management mistake indistinguishable from the kind every engineer has watched an AI coding agent make in a much lower-stakes production pipeline: generate something important, use it once, and never write it down.

The wallet that goes nowhere

It gets stranger. The ransom note's Bitcoin address wasn't a freshly generated wallet. It's 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy, the exact placeholder address copied into an enormous share of Bitcoin coding tutorials and sample scripts ever written.

Researchers can't say for certain whether the model hallucinated the most common Bitcoin address string in its own training data into a live extortion note, or whether a human operator deliberately reused a public address knowing it gets forwarded. Either reading points the same direction: the payment channel was never functionally the attacker's to collect from with any reliability.

Source: Cloud Security Alliance Lab Space, research note, July 7, 2026.

This isn't the first AI-run attack, and it's the less autonomous one

JADEPUFFER gets compared constantly to the case Anthropic disclosed in November 2025: a state-linked group (tracked as GTG-1002) got Claude to autonomously execute 80 to 90 percent of a real multi-target campaign across roughly 30 targets, with humans stepping in at only 4 to 6 key decision points.

Sysdig's own team is blunt about the limits of JADEPUFFER's autonomy: “A human still set up and pointed the operation and provisioned the infrastructure behind it,” Michael Clark told TechCrunch. Humans picked the victim, staged the command-and-control infrastructure, and supplied the initial stolen credentials. The AI ran the break-in. It didn't decide who to break into or how to get paid.

Microsoft threat researcher Geoff McDonald offered a read worth sitting with: the attack likely ran on “an open-weight model with stripped safety training rather than frontier models, since frontier labs' safety layers hold up well” against this kind of misuse, per his comments to TechCrunch. That's evidence the current generation of frontier-lab safety training is doing something, not evidence that agentic misuse is a solved problem, since McDonald's own warning is that ransomware campaigns are now bottlenecked by attacker budget rather than human effort, which could enable “thousands or tens of thousands of simultaneous campaigns.”

Source: TechCrunch, “The first AI-run ransomware attack still needed a human”, July 6, 2026.

The caveats the viral version left out

A few things worth being precise about before treating any single number here as gospel:

• Attribution is an assessment, not a confirmed forensic account.Sysdig frames JADEPUFFER as “medium-to-high confidence,” not a fully attributed incident with a named victim.
• No ransom amount was ever disclosed for JADEPUFFER specifically. A $500K figure circulating in some secondary coverage belongs to a different, earlier Anthropic-disclosed extortion campaign.
• The model has not been named. One low-quality secondary source claimed a fine-tuned Llama 4 variant; that claim has zero corroboration from Sysdig, TechCrunch, or CSA and shouldn't be repeated as fact.
• The 1,342 figure and the 31-second figure both have minor variance across secondary write-ups (one aggregator rounds to 1,400 records; CSA's own note says 42 seconds). We've used Sysdig's primary numbers throughout.

Why this is an agent-reliability story before it's a security story

Zoom out from the ransomware framing entirely and JADEPUFFER reads as a case study in exactly the failure mode that shows up constantly in production agent pipelines that have nothing to do with security: a long-running, unsupervised agent hits an edge case, silently generates something critical, and moves on without persisting it anywhere durable. In this case the something critical was an encryption key. In a normal engineering context it's a database migration, a signed deployment artifact, or a customer refund calculation. The failure shape is identical: fast, confident, and invisible until someone reconstructs the session after the fact.

That failure mode is already widespread. A Cloud Security Alliance survey of 418 IT and security professionals, fielded in January 2026, found 82% of enterprises have unknown, “shadow” AI agents running somewhere in their environment, 65% experienced an AI-agent-related security incident in the prior 12 months, and only 21% have a formal process for decommissioning agents once they're no longer needed.

Source: Cloud Security Alliance, press release, April 21, 2026.

Put JADEPUFFER's own bug next to those numbers and the pattern is the same one showing up on both sides of the fence: nobody, attacker or defender, has solved the problem of knowing what an unsupervised, fast-moving agent actually did until well after it did it.

If you're running agents that don't stop when you're not watching

The uncomfortable version of this story isn't “AI can run a cyberattack.” It's that speed and autonomy aren't the same thing as reliability, and an agent capable of fixing itself in 31 seconds is exactly as capable of shipping an unrecoverable mistake in 31 seconds, with nobody in the loop to catch it either way. That's true whether the agent is running an attack or running your production infrastructure.

It's also the exact design problem BrainClaw was built around: an always-on agent needs persistent memory and an isolated, observable execution environment, not a session that silently loses its own state the moment a terminal closes. And if you're routing long-running agent work across models to control cost, MegaBrain's gateway gives you transparent, zero-markup pricing across 500+ models instead of a black-box bill, so the economics of running agents 24/7 stay as visible as the agents themselves should be.