The news about JADEPUFFER from July 1 went almost unnoticed. According to Sysdig, the entire attack was carried out by an LLM agent: it breached an unpatched server, reached a production database, encrypted the service settings, deleted the source data, and demanded a ransom.
When scripts failed, the agent fixed them on the fly. Researchers counted more than 600 purposeful actions in total. But it failed at the one thing that mattered: it never saved the encryption key or handed it to the attacker. According to Sysdig, recovering the data after paying the ransom would have been impossible.
JADEPUFFER wasn’t caught in time, even though it left plenty of traces: it ran its own scripts, scanned the network, and altered the database schema. Which made me wonder: what if an attacker never needed to run anything foreign on the system at all?
Picture a company’s own customer support AI agent with write access to a database. It uses that access as part of normal work, and file-based security tools may never notice encryption happening inside the database. Through a prompt injection, an attacker gets the agent to adopt a malicious goal: find the most valuable data it can reach and encrypt it.
The agent doesn’t run any conspicuous CREATE TABLE or DROP TABLE statements - it just uses ordinary UPDATE queries to replace row contents with encrypted values. The queries come from the same account it uses every day: no foreign process, no schema change. A mass UPDATE can still give the attack away through the volume and nature of the changes, but the usual signs of malware are gone.
At that point I set aside all these intriguing speculations and tried to examine the scenario more rigorously.
JADEPUFFER and a hijacked in-house agent are different attacks. In the first case, a malicious LLM agent exploits a vulnerability to gain access to a server and runs its own code there. In the second, an attacker uses a prompt injection to make an agent already operating inside the organization use the permissions it was granted. So the JADEPUFFER case alone doesn’t prove that the second scenario would work in practice.
For such an attack, the malicious instruction has to reach the agent’s context and influence its actions. The agent itself needs access to valuable data and the ability to perform dangerous operations without human confirmation - for example, mass-editing data, exfiltrating it, or changing service settings. The attacker doesn’t need to know the internal network layout in advance: the agent can do the reconnaissance itself.
Individual pieces of this scenario already exist. LameHug generated commands through a language model based on a predefined task description. The lab experiment Ransomware 3.0 searched for valuable files on its own and encrypted them. In the JADEPUFFER case, the destructive operation already happened on a real system. And in 2025, a supply-chain compromise planted a malicious instruction inside the official Amazon Q Developer extension: it was meant to delete local files and cloud resources, but failed to execute due to a bug.
The hijacked in-house agent scenario hasn’t been publicly documented yet, but its main components have already shown up separately.
If Sysdig’s conclusion about the operation’s autonomy is correct, JADEPUFFER shows that an LLM agent can find targets on its own, fix its own errors, and carry a destructive operation through to the end - and it wasn’t stopped even though it left plenty of visible traces. A hijacked in-house agent could look far more ordinary. So it’s worth assuming we might not recognize the malicious instruction at all. In that case, the job of defense is to limit the possible damage in advance: give the agent access only to the data and operations it actually needs, cap the volume of changes it can make, and require human confirmation before any destructive action.