Dora NodaAn admin login failed midway through the attack. Nobody panicked, because nobody was there — the attacker was an AI agent, and it diagnosed the failure and issued a working fix in 31 seconds. Then it kept going: harvesting more credentials, moving laterally, encrypting 1,342 configuration items, and writing its own ransom note.
That's JADEPUFFER, the agentic ransomware campaign Sysdig's Threat Research Team documented in a July 2026 report. It broke in through an unauthenticated remote-code-execution bug in Langflow (CVE-2025-3248, CVSS 9.8, patched in version 1.3.0 over a year earlier but still running unpatched at the victim), and from that first foothold, an LLM agent — not a human operator, not a pre-scripted toolkit — ran the entire attack end to end.
That distinction is the whole story. Security tooling built around "flag the dangerous command" — the same model a deploy-from-chat platform's own approval gate relies on — assumes a human or a script executes one risky action at a time, each of which can be caught in isolation. JADEPUFFER didn't run one dangerous command. It ran a sequence of individually unremarkable actions that only add up to ransomware when read together. That's the mechanism worth understanding if your own product lets an agent execute infrastructure changes, and it's why Anthropic shipped Claude Code v2.1.200 four days after the report, flipping its default permission mode from automatic to Manual.
The Kill Chain, Compressed
Sysdig's report reconstructs seven phases, each carried out by the agent reasoning in natural language about its own next step — the payloads it left behind are full of commentary explaining why it picked a target, in the tone of someone thinking out loud:
| Phase | What the agent did |
|---|---|
| Initial access | Exploited CVE-2025-3248 against an internet-facing Langflow instance |
| Reconnaissance | Enumerated the network, ranked databases by apparent size/value ("ROI prioritization," in its own words) |
| Credential harvesting | Extracted and reused stored credentials |
| Lateral movement | Pivoted from the Langflow host to the production database server |
| Privilege escalation | Regained admin access after a failed login — diagnosed the cause and fixed it in 31 seconds |
| Persistence | Established footholds to survive remediation attempts |
| Impact | Encrypted 1,342 Nacos service configuration items, deleted the originals, generated a ransom note |
No human directed any individual step. That's what Sysdig means by "agentic threat actor" (ATA): the attack's capability comes from the model's own reasoning loop, not a human operator relaying commands through it.
Why "Approve the Risky Command" Doesn't Catch This
Here's the mechanism a deploy-from-chat platform actually needs to internalize. A per-tool-call approval gate — "ask before this agent runs rm, ask before it touches prod" — is a good answer to an accidental destructive action: the agent misreads a request, proposes something dangerous, a human sees it and says no. That's the model an MCP-based deploy platform's tool-approval layer is usually built around, and it's the right first line of defense.
JADEPUFFER shows the gap. Look at four tool calls a deploy platform's own MCP server would expose, none of which is dangerous in isolation:
- List environment variables for a service — a routine debugging call.
- Curl an internal health endpoint — read-only, no state change.
- Write an updated config file — a normal part of every deploy.
- Restart the service to apply it — also completely normal.
Skimmed one at a time, an approver — human or classifier — waves all four through; each looks like something a developer does five times a day. Chained by an agent that read credentials out of the env-var dump, used them against the internal endpoint, wrote a backdoored config, and restarted the service to load it, those same four calls are the attack. The danger isn't in any single call's blast radius. It's in the sequence, and per-call review has no memory of the sequence — each approval is evaluated as if it's the first and only thing the agent has done this session.
Claude Code's Answer: Manual by Default
Anthropic's response, shipped in Claude Code v2.1.200 on July 3, 2026, was blunt: flip the default permission mode from automatic approval to Manual, so the agent asks before any file write, shell command, or network call — full stop, no risk-scoring in between. The company's stated reason wasn't JADEPUFFER specifically; it was its own telemetry showing that 93% of prompts under the old default were being approved reflexively rather than reviewed — the classic failure mode of any system that asks a human to rubber-stamp dozens of individually low-stakes decisions per session. Approval fatigue had already made per-call gating close to theater before an autonomous multi-step attacker gave it a second reason to fail.
Manual mode fixes the fatigue problem. It doesn't, on its own, fix the sequencing problem — a human clicking "approve" four times in a row for four individually reasonable-looking calls is exactly as blind to the chain as a classifier would be, unless something in the session actually tracks what's been approved so far.
Gating mutating tool calls behind a trust boundary isn't a new idea for MCP-based platforms — it's the same fix a prompt-injection attack on hijacked tool output called for earlier this year, when researchers showed a fabricated diagnostic message alone could trick a coding agent into running commands it was never asked to run. That earlier attack relied on tricking a human, or the agent, into approving one bad call dressed up as something routine.
JADEPUFFER proves the same boundary has to hold against a different attacker. It didn't need to trick anyone into approving anything that looked wrong — every call it made looked exactly as routine as it should, because each one was, on its own. The trust-tier boundary is the same fix; the threat model on the other side of it isn't.
What a Deploy-Capable MCP Server Needs Beyond "Ask Before Delete"
This is where it gets concrete for anyone building the tool layer an agent uses to actually operate infrastructure — MCP servers exposing deploy, restart, config-write, and credential-read tools are exactly the kind of surface JADEPUFFER's mechanism targets. A 2026 audit of MCP servers found 66% had at least one security finding, with shell or command injection accounting for 43% of them — the tooling layer, not the model, is where most of the exposed risk already sits. Four changes hold up against sequencing, not just single bad calls:
- Token isolation per tool. Each tool call gets its own scoped credential instead of one broad session token reused everywhere — a compromised env-var dump can't be replayed against an internal endpoint that never shared its token with the env-var tool.
- Incremental scope consent. The 2026 MCP spec update lets a client request only the access a specific operation needs, when it needs it, instead of a blanket grant at session start — narrowing what a hijacked sequence can even reach.
- Trust-tier re-authorization. Require a fresh human check when a session crosses from read-only calls (list, curl, get) into mutating ones (write, restart, delete) — the boundary JADEPUFFER's own kill chain crosses from recon into impact.
- No auto-chaining across tools. The output of one tool call — a config value, a credential, a health-check result — should never by itself authorize the next call; a human or an explicit policy check sits between reading and acting on what was read.
- Session-level anomaly tracking, not just per-call risk scoring. A classifier that scores each call independently will rate "list env vars," "curl an endpoint," "write a file," and "restart a service" as four unremarkable actions every time. Logging and reviewing what a session did as a sequence — same credential touched four tool categories in ninety seconds — is what would have made JADEPUFFER's pattern visible before the encryption step, not after.
None of these replace Manual mode. They give it something to be manual about — a session-level record of what trust tier an agent is currently operating in, so a human approving call five knows it follows four others, not that it's an isolated request.
Is Manual-by-Default the Right Trade for "AI Agent Deploys Your App"?
For a platform whose headline feature is exactly that — an agent that deploys and operates your infrastructure — JADEPUFFER argues for manual-by-default as the baseline, not an opt-in a cautious tenant has to go find in settings. Concretely, that means a graduated-trust model: read-only calls (status checks, log reads, health pings) can auto-approve because they carry no mutation risk on their own, but anything that writes config, rotates a credential, or restarts a service stays gated behind an explicit approval until a given tenant has an audit trail long enough to justify loosening it — an earned, per-tenant escalation, not a global default flipped to autonomous because it demos better.
That's a real cost against a punchier pitch: "just tell the agent to ship it" is a better demo than "approve this deploy." But JADEPUFFER is the concrete argument for paying it. The skill floor for running a multi-stage attack has dropped to whatever it costs to run an agent — and if a deploy platform's own agent can chain four boring tool calls into a production compromise, the fact that a human approved each call individually is not the safety net it looks like, unless the platform also tracks what those calls add up to.
Bex.co is the open-source, AI-native Render alternative — an agent can push a git repo and get a running HTTPS service on machines you own, through an MCP server built around exactly this trade-off: scoped tokens per tool, mutating calls gated by default, autonomy earned per tenant rather than assumed. Star the repo on GitHub or deploy your first app today.