JadePuffer: the first ransomware run by an AI agent

For two years we’ve repeated the same caveat in posts about AI security: models are an amplifier of human work, not an independent attacker. Sysdig’s report on a campaign named JadePuffer forces a partial revision of that sentence. The researchers describe what they consider the first documented case of a ransomware operation carried out from start to finish by an agent built on a large language model: reconnaissance, credential theft, lateral movement, persistence, privilege escalation and data encryption — with no human steering each step.

This isn’t a story about “AI that decided to attack on its own”. It describes a tool someone configured and released, which then handled obstacles by itself at a pace no human operator could match. And it’s that capacity to adapt — not the mere use of AI — that matters here.

What actually happened

The attack chain is short and, worth emphasising, contains not a single exotic technique. All the novelty lies in who was making the decisions.

Entry: a known Langflow flaw. The starting point was exploitation of CVE-2025-3248 — unauthenticated remote code execution in Langflow, a popular open-source framework for building LLM applications. We covered that vulnerability separately in our post on the Langflow flaw. There’s an irony in it: a tool for building AI applications became the entry point for an attacking AI agent.

Pivot to the database. From the Langflow instance the attacker moved to a production MySQL server running Alibaba Nacos (Naming and Configuration Service), using root credentials whose origin Sysdig could not determine. That’s an important methodological caveat — the researchers honestly flag a gap in the reconstruction rather than closing it with a guess.

Impact: encrypted configuration. The agent encrypted 1,342 service configuration items in Nacos and then deleted the originals. That target selection deserves its own comment, which I’ll return to below.

Why this is a milestone, not just a headline

Three elements distinguish this operation from the “ransomware with AI” that marketing has talked about for two years.

1. Real-time adaptation

The most telling detail in the report: in one sequence the agent went from a failed login to a working fix in 31 seconds. The operation repeatedly retried failed steps with corrected parameters — doing exactly what an experienced operator does when meeting resistance.

The difference is speed. A human analysing an authentication error needs minutes: read the message, recall the syntax, check documentation, try again. An agent closes that loop in seconds and does it across multiple paths in parallel. The consequence for defenders is mundane: the window between an attacker’s first mistake and their successful workaround shrinks — and that window is exactly where a SIEM alert could still change the outcome.

2. No human in the operational loop

In a classic ransomware attack there’s an operator who logs into a panel, reviews results, makes decisions, and is constrained by time zones, fatigue and how many targets they can juggle. Here those constraints disappear. A campaign needs no night shift and has no limit on parallel intrusions other than compute.

That has direct implications for criminal economics. The ransomware-as-a-service model requires recruiting affiliates with specific skills. An agent lowers the competence threshold: work that required an experienced operator is done by automation.

3. The target was configuration, not user files

The most interesting technical decision concerns what was encrypted. Classic ransomware goes for file shares, documents and backups. JadePuffer hit service configuration in Nacos.

In a microservices architecture Nacos acts as a service registry and central configuration store: it holds addresses, connection parameters, environment settings and information about which service lives where. Encrypting and deleting 1,342 configuration entries means applications can no longer find each other. It doesn’t matter that files on disk are untouched — the system as a whole stops working.

From the attacker’s perspective that’s economical. Encrypting terabytes takes hours and generates enormous, easily detected disk activity. Encrypting a few thousand small configuration entries takes moments, is quiet, and produces the same business outcome: downtime.

That’s a warning for anyone whose continuity planning rests on file backups. The question “do we back up documents” must be joined by “do we back up and version our configuration” and “how long would it take to rebuild the service registry from scratch”.

What this case does NOT prove

Analytical honesty requires separating observation from extrapolation, because it’s easy to overstate this report.

It isn’t evidence of autonomous, self-directed AI. Someone configured the agent, gave it a goal, tools and access. The autonomy concerns execution, not intent. That’s a meaningful distinction: we’re discussing advanced automation, not agency.

It isn’t a technically unprecedented attack. It used a known vulnerability with an available patch and root credentials that should not have been reachable. Had the environment been patched and properly segmented, the agent would have had nothing to work with. The basics failed, not advanced defences.

It doesn’t mean every attack will now look like this. We have one documented case. Generalising from it about the whole threat landscape would be an overreach — though ignoring it would be an equally large mistake.

We don’t know everything about the chain. The origin of the root credentials remains undetermined. That gap matters, because it concerns the key step: moving from a network-exposed system to a production database.

What changes for defenders — concretely

Despite appearances, the conclusions aren’t about “defending against AI”. They’re about things that should be done anyway, whose priority just rose.

The available response window is shrinking

If an attacker closes the “error → correction” loop in seconds, detection based on weekly log review stops making sense. You need rules that act automatically: unusual authentications, code execution by a service that never does that, mass operations on configuration. That’s an argument for building detection as code, not for another tool.

It’s also worth noting that a burst of rapid, failed attempts is itself a signal. Humans err at human speed; automation produces a distinctive pattern of dozens of attempts in tens of seconds. That’s detectable — if anyone is looking.

AI systems are becoming targets, not just tools

The entry point was a framework for building LLM applications. A year ago most companies had none; today they run in production, often deployed by product teams outside the standard process. The questions to ask:

• Do we know where our AI tools run (Langflow, n8n, notebooks, MCP servers, RAG panels)?
• Are they patched and covered by the same cycle as the rest of the infrastructure?
• Is any of them internet-facing without authentication?
• What permissions do they hold to databases and other services?

That’s precisely the area we describe in discovering shadow AI. JadePuffer shows it isn’t a theoretical governance exercise — it’s attack surface.

root credentials in a production database remain the core problem

All the sophisticated parts of this story lose significance next to the fact that the agent obtained root access to a production MySQL server. No AI is required to exploit that.

The fundamentals are unchanged: unique, least-privilege accounts per service, no shared administrative accounts, rotation and storage of secrets in a dedicated system rather than configuration files (secrets management), and segmentation that stops an application-layer system from talking directly to a production database (internal network segmentation).

Back up configuration, not just data

Since configuration became the target, recovery planning must cover it. Practical questions: is service configuration versioned in a repository? Can you rebuild the service registry from code (infrastructure as code)? Has anyone ever rehearsed restoring an entire environment rather than a single server? We set out the fundamentals in the 3-2-1 strategy, but configuration is often excluded from it — and that needs fixing.

Restrict agent permissions — including your own

This is the mirror image of the problem. If you deploy AI agents, the same rules apply that you’d want constraining an attacker: least privilege, execution isolation, no access to the management layer, full action logging. We wrote about it in non-human identities and in AgentForger. JadePuffer shows why that isn’t excessive: an agent with broad permissions is equally effective when working for the adversary.

Detection signals worth deploying

Rules that address this specific pattern, and a wider class of attacks along with it:

Signal	Why it matters
A web service (e.g. an AI framework) spawning child processes	Classic result of RCE; an application service shouldn’t launch a shell
Dozens of failed authentications in tens of seconds, then success	The distinctive rhythm of automation correcting parameters
A connection from an AI system to a production database	Usually unjustified; if needed, it should be narrowly defined
Mass modification or deletion of configuration entries	A direct indicator of this attack
Use of a database root/admin account from an unusual host	A sign of credential compromise
A sudden spike in write operations in the service registry	Encryption of configuration rather than files

None of these rules requires a tool “for detecting AI”. They require knowing what is normal in your environment — the hardest and most rewarding work in detection.

Preparing for further campaigns of this class

Since we have one documented case rather than a trend, the right response isn’t to rebuild your security programme but to shift priorities in a few areas.

Treat AI tools as production systems. Frameworks for building LLM applications, workflow orchestrators, notebooks and proxy servers enter environments quickly and often outside the standard deployment path. The result: nobody knows their versions, nobody tracks their advisories, and their permissions were granted “for testing”. Pull them into the inventory, assign an owner and bring them into the patch cycle — a one-off effort with an excellent effort-to-benefit ratio.

Build a profile of normal behaviour for AI services. Detecting this attack doesn’t require recognising “an agent”. It requires knowing that an LLM framework instance has never before connected to a production database or launched a system shell. A normality profile beats any signature here.

Rehearse a fast-operation scenario. If your response plan assumes the team will assemble, analyse and decide after the first alert, test it under time pressure measured in minutes. The usual conclusion is simple: some decisions must move to automation, because humans won’t make them in time — especially host isolation and revoking an account’s privileges.

Define a configuration recovery procedure. Ask your team how long it would take to rebuild the service registry and environment configuration if they vanished tonight. If the answer is “I don’t know” or “a few days”, you have a concrete project — regardless of whether you ever meet agentic ransomware.

Check whether you can see mass operations. Encrypting 1,342 configuration entries is a mass operation. So is a bulk table read, a bulk deletion of cloud objects, or a bulk permission change. A threshold alert on such activity is cheap to deploy and catches a whole family of attacks, not just this one.

Frequently asked questions (FAQ)

Does this mean AI has started attacking companies on its own? No. A human configured and launched the agent, defined the goal and provided tools and access. The autonomy applied to executing the attack’s steps, not to deciding to carry it out. That distinction matters — this is a step change in automation, not a machine with agency.

We don’t use Langflow. Does this affect us? The vector — no. The pattern — yes. Langflow was an incidental entry point: a network-exposed system with an unpatched, known vulnerability. That role could fall to any tool in your environment, especially one deployed outside the standard process. The question is: what plays that role for us, and is it patched?

Would classic security tooling detect such an attack? Yes, if it’s oriented toward behaviour rather than signatures. The agent performs the same actions a human would: spawning processes, authenticating, connecting to a database, modifying data in bulk. The effects are detectable, not the “use of AI”. What changes is the required speed of response, not the type of signal.

Is this the end of ransomware-as-a-service with human affiliates? Not in any foreseeable timeframe, but the barrier to entry drops. Work that required an experienced operator can be automated, which increases the pool of potential offenders. For defenders the practical consequence is simple arithmetic: more attempts, in less time.

Where do we start with limited resources? With three things you need anyway: inventory and patch network-exposed AI systems, remove shared database administrative accounts, and check whether you can restore environment configuration rather than just files. Get in touch if you’d like us to verify that for you.

Summary

JadePuffer matters not because it demonstrates a new attack technique — it doesn’t. Entry through an unpatched, known flaw and root credentials in a production database is a decade-old scenario. It matters because it moves the operator’s decision-making into automation that closes the response loop in seconds and needs no sleep.

For defenders the conclusions are disappointingly mundane, which is why they’re credible: patch AI systems like the rest of your infrastructure, because they’re now part of the attack surface; remove broad credentials from the application layer, because they turn an entry into a catastrophe; extend recovery planning to configuration, because the target is shifting from files to what holds the system together; and shorten your response time, because the adversary just shortened theirs. If you want to know how far such an agent would get in your environment — let’s verify it with a controlled test.

---

Sources and further reading: Sysdig — JADEPUFFER, BleepingComputer, SecurityWeek, CISA KEV.