In late June 2026, something happened inside a victim’s network that had never been documented before. An AI agent broke into an internet-facing server, searched it for credentials, worked out which internal systems were worth attacking, moved across to a production database, encrypted 1,342 configuration records, deleted the originals and wrote its own ransom note — and it made those decisions itself, without a human typing the commands.

Cloud security firm Sysdig published its analysis of the intrusion on 1 July 2026, naming the operator JADEPUFFER and calling it the first documented case of agentic ransomware. Within days of that report going live, the same operator came back with something worse: a purpose-built ransomware binary designed to destroy trained AI models, documented by Sysdig on 20 July.

Both campaigns are worth understanding together, because separately they read as news and together they read as a warning. The attacker entered through an AI framework, and eventually built a weapon aimed at the AI assets that framework connects to. Meanwhile, in both campaigns, paying the ransom would not have recovered the data.

Table of contents

What autonomous AI ransomware actually means

The phrase gets used loosely, so it’s worth being precise. Three different things are often described the same way:

TermWhat it meansHow long it’s existed
AI-assisted attackA human uses an LLM to write a phishing email, debug an exploit or generate malware codeWidespread since roughly 2023
Scripted automationA human writes an attack script that runs a fixed sequence of stepsDecades
Agentic ransomwareAn LLM makes the operational decisions across the attack chain, choosing targets and adapting when steps failFirst documented July 2026

Sysdig uses the term agentic threat actor (ATA) for an operator whose attack capability is delivered by an AI agent rather than a human-driven toolkit. That distinction matters. A script does the same thing every time and breaks when it hits something unexpected. An agent reads the error, works out why it failed, and tries a different approach.

One important caveat that many headlines dropped: a human was still involved. Sysdig’s Michael Clark, director of threat research, told CyberScoop that “a human still set up and pointed the operation and provisioned the infrastructure behind it, the command-and-control server, the staging server used for the stolen data and chose a victim.” The agent connected to the victim’s MySQL server using root credentials that researchers did not observe being harvested from the environment, suggesting a person obtained them in an earlier compromise.

So “fully autonomous” is accurate about the execution of the attack chain, not about the operation as a whole.

How the first AI-run ransomware attack unfolded

The entry point was not exotic. It was a critical vulnerability that had been patched, publicly documented and flagged by the US government for more than a year.

Phase 1 — the door. JADEPUFFER exploited CVE-2025-3248, a missing-authentication flaw in Langflow, an open-source framework for building LLM applications and agent workflows. The bug lets an unauthenticated attacker execute arbitrary Python on the host through the code-validation endpoint. It carries a CVSS 3.1 base score of 9.8 (Critical), affects Langflow versions before 1.3.0, and was added to CISA’s Known Exploited Vulnerabilities catalog on 5 May 2025 with a federal remediation deadline of 26 May 2025.

Once inside, the agent enumerated the host and swept the environment for secrets in parallel — LLM provider API keys, cloud credentials across Western and Chinese providers, cryptocurrency wallet material and database configuration files. It dumped Langflow’s own backing Postgres database, harvested the stored credentials and API keys, then deleted its staging files.

It also found a MinIO object store reachable on the internal network, logged in with the vendor default credentials (minioadmin:minioadmin), listed every bucket including one holding Terraform state, and pulled a credentials file by name. For persistence, it installed a scheduled task beaconing to attacker infrastructure every 30 minutes.

Phase 2 — the pivot. The Langflow host was never the objective. Captured artefacts showed the real target was a separate internet-exposed production server running MySQL and Alibaba Nacos, a service-discovery and dynamic-configuration platform common in microservice architectures.

The agent attacked Nacos from several directions at once, including a 2021 authentication-bypass issue and Nacos’s default JWT signing key — a value that has been publicly documented since 2020 and still ships unchanged in many deployments. It then surveyed the host for a container escape, testing whether it could read the Docker socket and container control files, and wrote itself a completion marker before moving on.

Phase 3 — encryption and destruction. The agent encrypted all 1,342 Nacos service configuration items, dropped the original configuration and history tables, and created a table containing the ransom demand, a Bitcoin address and a Proton Mail contact. It then escalated from row-level deletion to dropping entire database schemas, annotating its own reasoning about which databases were highest value as it went.

Across the session, Sysdig counted more than 600 distinct, purposeful payloads.

The 31 seconds that convinced researchers an AI was driving

The strongest evidence for autonomy wasn’t what the agent did when things worked. It was what it did when things broke.

The agent tried to insert a backdoor administrator account into the Nacos database. The password hash it generated came back empty because of a path problem in how it called a helper library, so the stored hash was blank and the subsequent login failed. Here is the sequence Sysdig recorded, in UTC:

TimeWhat happened
19:34:24Inserts a backdoor admin account with a password hash generated via a subprocess call
19:34:36Login attempt fails; no token returned
19:34:48Tests default credentials and regenerates a hash for a simpler password — diagnosing two possible causes in parallel
19:35:07Issues a corrective payload: switches from a subprocess call to importing the library directly, verifies it is importable, deletes the broken account and reinserts it correctly
19:35:18Login succeeds

The gap between the failed login and the correct multi-step fix was 31 seconds, and the fix was 15 lines of coordinated code. Diagnosing a subprocess path issue from an error message, drafting a corrective script and submitting it takes a human considerably longer.

Sysdig cited three other independent signals. The payloads were self-narrating — saturated with plain-language commentary explaining why each action was being taken, including return-on-investment reasoning about which database to destroy. Human operators don’t annotate disposable one-liners that way; LLM code generation does it reflexively. The corrections were specific to each failure mode rather than generic retries: when a request returned XML instead of JSON, the next payload parsed XML; when a token-forgery attempt reported a custom secret in use, that entire approach was abandoned; when a database drop failed silently because of a foreign-key constraint, the next payload disabled the constraint check, dropped the database and re-enabled it. And the agent read and acted on free-text context presented by the target in a way a pattern-matching scanner could not.

One curious detail complicates the picture. The Bitcoin address in the ransom note is the canonical pay-to-script-hash example used across Bitcoin developer documentation — the kind of string that saturates LLM training data as a placeholder. It is also a live wallet with 737 confirmed transactions and roughly 46 BTC received over its history, currently holding nothing, with every deposit immediately swept elsewhere. Sysdig offers two readings and says it cannot distinguish between them: either the model hallucinated the address from training data, or the operator configured a real wallet that happens to match the documentation example.

The detail most coverage skipped: the ransom was uncollectable

This is the part worth pausing on, and most news write-ups mentioned it only in passing.

The AES key used to encrypt the Nacos configurations was generated from random values, printed once to standard output, and never saved or transmitted anywhere. The victim cannot recover the encrypted configurations even if the ransom is paid in full. The ransom note also claimed AES-256, while the MySQL function used defaults to AES-128 in ECB mode unless the server was reconfigured — so the note overstated its own encryption. The practical outcome is identical: the data is gone.

Sysdig also noted that the claim of data theft was the agent’s own assertion. Before dropping databases, its code commented that the data had already been backed up to a staging server, but researchers found no independent evidence that anything was actually exfiltrated to it.

That reframes the incident. This was not really an extortion operation that happened to be automated. Functionally, it was a destruction event with a payment request attached — and whether that was deliberate or a consequence of an agent that didn’t properly handle its own key management, nobody outside the operation can say.

If you are writing an incident response plan, that is the uncomfortable takeaway. Traditional ransomware playbooks assume a rational counterparty with a working decryption service, because reputation is part of the business model. An agent-driven operation offers no such assurance.

Diagram of the agentic ransomware attack chain from Langflow exploitation to database encryption

Round two: ransomware built to destroy AI models

On 20 July 2026, Sysdig published a follow-up. Within days of the first report, JADEPUFFER returned to the same Langflow instance with a materially upgraded toolkit.

Gone were the improvised Python scripts and database-native encryption. In their place: ENCFORGE, a compiled, UPX-packed Go binary using AES-256-CTR for bulk encryption with the per-run key wrapped by an embedded RSA-2048 public key. It kills processes holding file locks before encrypting, can safely resume after interruption, self-deletes after running, and renames encrypted files with a .locked extension. At the time of analysis, common threat-intelligence tools recognised neither the packed nor the unpacked hash.

The attribution link is straightforward: the extortion contact embedded in ENCFORGE is the same Proton Mail address disclosed in the first report.

What ENCFORGE targets

The binary sweeps roughly 180 file extensions, and the selection is the clearest evidence of deliberate design:

  • Model formats and checkpoints: .ckpt, .h5, .onnx, .pb, .pt, .pth, .safetensors, .ggml, .gguf, .pkl
  • Vector and embedding indices: .faiss, .vec
  • Training datasets: .parquet, .arrow, .feather, .tfrecord, .npy, .npz, .duckdb

Sysdig’s strongest argument that this is intentional rather than incidental is the binary’s own help text. An --include flag lets the operator append extra file types to the encryption list, and the example given in the help output is LoRA fine-tune adapter files and legacy GGML weights. Those are not the examples you write for a general-purpose file encryptor.

The delivery was also notable. The initial attempt to download the binary into the container failed. Rather than abandoning the objective, the agent built a container-escape toolkit in session — iterating through six Python scripts and converging on a working escape in five minutes and 24 seconds, each version fixing a specific failure in the one before it — then copied the binary across the namespace boundary and ran it on the host.

Why encrypted models are different from encrypted files

Ransomware operators bet that victims don’t keep good backups. Targeting model artefacts raises the stakes on that bet, for a reason that has nothing to do with cryptography.

An encrypted spreadsheet restored from last night’s backup is last night’s spreadsheet. A model checkpoint restored from last month’s snapshot is missing every training run, fine-tuning iteration and dataset revision since then — and closing that gap means re-running the work, not restoring a file.

Sysdig puts direct recovery cost for a representative enterprise-grade fine-tuned model at $75,000 to $500,000, reflecting current cloud GPU rates across multiple training runs plus the engineering hours to design, manage and validate them. That figure is per model, and production environments often keep several specialised variants on shared storage that a single run would encrypt together. If the training data sits on the same host — which is common — recovery is blocked entirely until the dataset itself is rebuilt.

One point of relief: binary analysis found no network capability, no outbound dial and no staging logic in ENCFORGE at all. There was no leak site and no payment portal. It is single-extortion, destruction-first ransomware. The encryption is the threat.

Revolution or evolution? What researchers actually say

TechyKnow’s view is that the honest answer is less dramatic than the headlines, and more concerning than the pushback.

Independent researcher and red teamer Vibhum Dubey called the campaign “an evolution in execution than a completely new ransomware technique,” telling CSO Online that attackers have automated reconnaissance, credential theft and deployment for years. “The difference is that an AI agent can connect those stages together and make decisions without waiting for a human operator.”

His concern is adaptability, not encryption speed. “Traditional detections assume attackers follow fairly predictable paths. An AI agent can quickly change tactics if something is blocked, making every intrusion look slightly different. I’m less worried about the encryption stage than the quiet phase beforehand, where the agent maps identities, privileges, and trust relationships while avoiding detection.”

Prashant Sharma, a cybersecurity consultant at Cyble, made a similar point about defensive priorities staying stable. “Modern EDR, XDR, and SOC platforms are built to flag malicious behavior rather than the underlying technology driving it. Whether an attack is carried out manually or orchestrated by an AI agent, actions such as credential abuse, privilege escalation, lateral movement, data exfiltration, and ransomware deployment still leave detectable behavioral traces.”

Both are right, and neither is reassuring. Sysdig’s own framing is the sharpest version of why: none of the individual techniques were novel. The Nacos issue dates to 2021. The default signing key has been public since 2020. The MinIO credentials were the vendor defaults. The Langflow CVE had a patch and a federal deadline more than a year old. What changed is that stringing all of it together no longer requires a skilled operator.

As Clark put it: “The skill floor for running a full ransomware operation just dropped to whatever it costs to run an agent.”

Why the AI stack is now both the door and the target

Read the two campaigns as one story and a pattern appears that neither alone makes obvious.

The entry point was an AI framework. Langflow deployments are attractive precisely because of what they are: AI-adjacent servers that frequently hold LLM provider API keys, cloud credentials and connections to vector databases and object stores in their runtime environment, often stood up quickly to prototype something and left without network controls.

The payload, one campaign later, was built to destroy AI assets — model weights, vector indices and training data.

The same infrastructure that makes an AI orchestration server useful makes it a high-value foothold, and the assets it connects to are now the target. That closes a loop worth taking seriously if your organisation has spent the past two years standing up AI tooling faster than it has been securing it. This is also a reminder that the low-code and no-code development boom has a security dimension: tools designed to let non-specialists ship quickly also let them expose a code-execution endpoint to the internet without realising it.

It is the same underlying failure TechyKnow covered when researchers found 175,000 publicly exposed APIs — infrastructure reachable from the internet that nobody remembered was reachable. What agentic tooling changes is the economics of finding it.

What to do if you run AI infrastructure

None of this requires a new security programme. It requires doing unglamorous things to systems that were probably set up in a hurry.

Patch and reduce exposure

  • Update Langflow to 1.3.0 or later. CVE-2025-3248 has been in CISA’s KEV catalog since May 2025, and its remediation deadline has long passed.
  • Do not expose code-execution or code-validation endpoints to the internet. Put AI orchestration tools behind authentication and network controls.
  • Never expose a database server’s administrative account to the internet. Enforce unique credentials and source-IP restrictions on management ports.
  • Change vendor default credentials and default signing keys. Two of the footholds in this campaign were documented defaults.

Get secrets off AI orchestration hosts

  • Do not store provider API keys or cloud credentials in the runtime environment of a web-reachable AI server. Scope them to a secrets manager instead. Sysdig confirmed these were swept immediately on access.
  • Rotate anything that was reachable by the application process on any host that ran a vulnerable version.

Treat model artefacts as tier-one backup assets

  • Keep offline or immutable snapshots of production model artefacts and core training datasets. Ransomware hitting .gguf, .safetensors and .ckpt files can take down a production AI system without touching a single business document — which means an AI-blind backup policy leaves your most expensive assets unprotected.
  • Apply filesystem permissions so model weight directories are not readable by the web application process user.
  • Store training data separately from model artefacts, so losing one doesn’t block recovery of the other.

Watch behaviour, not tools

  • Alert on application processes accessing the Docker socket, and on privileged container creation with host bind mounts. A framework like Langflow has no legitimate reason to create containers.
  • Alert on namespace-crossing commands issued from inside a container.
  • Add mass .locked file creation on machine learning asset paths to your detection coverage.
  • Apply egress controls so a compromised application host cannot beacon to arbitrary destinations.

Sysdig published full indicators of compromise and a YARA rule for the ENCFORGE family in both reports. If you run Langflow or Nacos, that is where to start — we have deliberately not reproduced live attacker infrastructure details or working payload code here, and defenders should pull them from the primary source.

What to watch next

Clark’s expectation is the one to hold onto: “We have not yet seen operations against other victims, and given how cheap this agentic ransomware operation is to run, I would expect this will not be the last.”

Three things are worth tracking over the next few months. First, whether JADEPUFFER’s task-ID campaign tracking — Sysdig observed identifiers suggesting a broader fleet operation — turns into confirmed victims beyond the one documented. Second, whether other operators adopt the same model, which would show up as a rise in intrusions that reuse ancient vulnerabilities at unusual speed. Third, whether agentic operations start including working key escrow, because the moment they do, the destruction-first character of these two campaigns becomes conventional extortion with an automated operator.

The broader trend line is the one TechyKnow has been tracking all year in agentic AI: the same properties that make agents useful for legitimate work — chaining tools, adapting to failure, running unsupervised — are exactly what make them effective for attackers. The capability is not the problem. The exposure is.

The practical next step: if your organisation stood up an AI tool in the last eighteen months, find out today whether it is internet-reachable, what credentials live in its environment, and whether anything it touches is in your backup policy. That audit costs an afternoon. The alternative, per Sysdig’s own numbers, starts at $75,000 per model.