A security team left a trap designed to catch an AI agent, and the attacker walked straight past it. That single detail makes the recent Marimo incident, dissected by Sysdig, one of the cleanest looks yet at the line between a human attacker and an AI one, and it quietly complicates the story everybody has been telling for a year. The intruder moved from a pre-auth vulnerability in a Marimo notebook to an SSH bastion host in eight seconds, a pace we now reflexively attribute to machines. There was no AI in the loop. Just a person with a toolkit they had built by hand.
The eight-second breach
The way in was CVE-2026-39987, a pre-authentication remote code execution flaw in Marimo, the interactive Python notebook platform popular with data-science and machine-learning teams. Marimo exposes several WebSocket connections, and every one of them enforced an authentication check, except the terminal endpoint, which did not. Anyone who opened a connection to it received an interactive shell as the Marimo process user, with no credentials at all. It is the kind of bug that reads like an oversight because it is one: the guard was on every door but the one that mattered.
From that shell, the chain to full cloud access was short and brutal. It is worth walking through, because each link is a lesson in where secrets go to die.
| Step | What happened |
|---|---|
| 1 | Connect to the unauthenticated terminal endpoint — instant shell, no password |
| 2 | Harvest AWS credentials from two places: the process environment and the app’s Redis backend |
| 3 | One credential pulled a private SSH key from AWS Secrets Manager |
| 4 | Log in to the SSH bastion, and through it into the victim’s cloud |
| Total | 8 seconds of execution on top of ~4 hours of prior preparation |
The honeytoken that fingerprints an AI
Here is the part that should interest anyone building or defending AI systems. Sysdig had planted a trap tuned specifically for autonomous agents: a hidden instruction sitting in a file, telling any language model that read it to echo a secret marker. The reasoning is elegant. An AI agent crawling the filesystem would ingest that instruction as input and, being an obedient text predictor, print the marker, outing itself. A human reading the same file would just see a weird string and move on.
The operator opened that exact file twice and never printed the marker. That is how the researchers concluded they were watching a person, not a bot. It is a small moment with a big implication: defenders are starting to weaponise prompt injection in reverse, as a detection mechanism, laying bait that only an AI would take. We have written about prompt injection as an attack in security skills versus prompt injection; here it becomes a tripwire. Telling human from machine is quietly becoming its own discipline, and the trap is only as good as the assumption behind it — that agents can’t resist their instructions. That assumption will not hold forever.
“Machine speed” was never the AI’s alone
The eight-second figure is the one that travels, and it deserves an asterisk. Before that sprint, the operator had spent roughly four hours across earlier sessions writing and debugging their toolkit. By showtime they had eight ready-made scripts that fired the whole chain from a single command. Across a nine-hour session they typed more than 850 interactive commands by hand and used no recognisable public offensive tooling. The eight seconds were execution; the speed was baked in during preparation.
This is worth sitting with, because it corrects a lazy assumption. We keep crediting AI with the acceleration of attacks, and it is true that AI collapses the barrier for people who could not previously build this kind of tooling, a shift we documented in how attackers automate exploitation with AI and saw play out at scale in the PaperCut campaign. But a skilled human with a pre-staged playbook has always been able to hit machine speed. AI democratises the preparation; it does not invent the speed. And for a defender the conclusion is identical either way: whether the fast thing on the other end is an agent or a well-drilled human, your window to react is effectively zero.
Why AI and ML infrastructure is the soft underbelly
The choice of target is not incidental. Notebooks like Marimo and Jupyter rarely run in isolation; they sit next to machine-learning pipelines, which means they live on hosts with GPUs, large and often sensitive datasets, and credentials for AWS, GCP and model providers. Researchers describe a box like this bluntly as the door to the victim’s cloud account, and this incident proved the description exact: AWS keys in the environment and in Redis, one of them unlocking an SSH key in Secrets Manager, and from there the bastion.
The deeper problem is cultural. ML infrastructure is stood up by data scientists optimising for iteration speed, not by security engineers, so the boring questions — is this notebook exposed to the internet, why does it hold long-lived cloud keys, what can it reach — get asked after the incident rather than before. As teams wire agents and notebooks into everything, that gap is exactly the kind of thing a threat model for agentic and generative AI is meant to force into the open, and it is why what an AI tool can actually reach on your host is no longer an academic question.
What to do about it
- Patch and don’t expose. Update Marimo to 0.23.0 or later (the flaw has sat on CISA’s KEV list with a May remediation deadline) and keep notebooks off the public internet entirely, behind a VPN or an allow-list.
- Kill long-lived cloud keys. Static AWS credentials in an environment variable or a Redis instance are a gift. Use short-lived, scoped tokens so a stolen credential expires before it is useful, and lock down instance metadata access.
- Assume the reachable secret is the reached secret. If a notebook host can read Secrets Manager or a bastion key, treat that path as already traversed and segment accordingly, so one shell does not become the whole cloud.
- Gate what agents and tools can actually do. A runtime that mediates dangerous actions and keeps a tamper-evident log — the model behind Airlock and the three lines of defense for AI agents — turns an unexpected shell into a blocked action and an alert instead of a silent pivot.
- Instrument for detection, human or machine. The honeytoken trick works today; build the logging and behavioural signals that catch fast lateral movement regardless of who, or what, is driving it.
The bottom line
The Marimo incident is valuable precisely because it refuses to fit the script. A human, with no AI, matched the speed we blame on bots, and slipped a trap built to catch bots, by doing the unglamorous work of preparing in advance. The takeaways are not exotic: fix the unauthenticated endpoint, get notebooks off the internet, stop leaving long-lived cloud keys where a single shell can scoop them up, and put a real boundary around what your tools and agents can touch. Speed is not the AI’s monopoly, and it never was; preparation is. The only safe assumption is that whoever comes for your ML infrastructure — carbon or silicon — will already be moving faster than your incident response, so the defence has to be standing before they arrive.