When the Hacker Is an AI Agent

Last week, security researchers at Sysdig published something that has been quietly making the rounds in IT and security circles. They caught a cyberattack in their telemetry that was driven, in real time, by a large language model. Not a human reaching for ChatGPT to write a script. Not an automation framework with AI sprinkled in. An autonomous agent, reading the output of each command and deciding what to do next, ran the entire post-compromise phase by itself.¹

That distinction matters more than it sounds. Most of us have spent the last two years worrying about how AI is changing the work we do at our desks. This is the first well-documented case of AI doing somebody else's work on the other side of a firewall, and that somebody else happens to be the people trying to break in.³

What actually happened

On May 10, the Sysdig Threat Research Team was watching one of their environments when an attacker exploited a known vulnerability in marimo, an open-source Python notebook. That part is ordinary. The vulnerability, CVE-2026-39987, gave the attacker a foothold on the host. So far, this looks like a Tuesday in any SOC.

Then things sped up. The attacker grabbed AWS credentials out of an environment file on the compromised box. Used those to find an SSH key sitting in AWS Secrets Manager. Used the SSH key to jump onto a downstream bastion server. From there, they dumped the entire schema and contents of an internal PostgreSQL database. Total time from the first command to the database walking out the door: under one hour. The database dump itself took less than two minutes.¹

You can read that as "another fast breach" and move on. The Sysdig team did not. They looked at the recorded command stream and found four fingerprints that pointed to something more interesting than a fast scripted attacker.⁴

How they knew it was an AI

The team's argument is worth walking through, because the signs are not subtle once you see them.

First, the attacker ran a database dump against a target they had no information about. Nothing on the compromised host identified what application owned the internal database. The attacker still issued a generic "AI workflow" style query, then bundled six specific table names into one big SQL block, including a credential table that does not exist in the application schema they appeared to be guessing at. They were composing in the moment, not reading from a playbook.¹

Second, a planning comment in Chinese, which translates roughly to "see what else we can do," leaked into the middle of a shell command, in the same session, sourced from six different IP addresses, at sub-second intervals. No human types like that. No pre-written script writes itself comments mid-run. The Sysdig team's reading: an AI orchestrator was narrating its own work, and the narration accidentally spilled into the command stream.¹

Third, every command was shaped for a machine to read. Output dividers between probes. Output capped at 30 or 40 lines so a model's context window did not get flooded. Pagers disabled so nothing waited for a human to press space. Standard error redirected to /dev/null so the agent's view stayed clean.¹

Fourth, the chain consumed its own output. A password read out of a config file ended up substituted into the next database query. A secret ID lifted out of one AWS API response became the input to the next call. That "read this, then pick the next move based on what you read" pattern is exactly what an LLM agent does in a tool-use loop.¹

Michael Clark, who leads the Sysdig research team, put it well. "We are not watching AI replace attackers. We are watching attackers replace their scripts with AI."²

Why this is different from "hackers use AI"

We have known for a while that bad actors use AI tools the same way the rest of us do, to write phishing emails faster, debug malware, summarize stolen documents. That is AI as a helper. A human is still steering.

What Sysdig caught is different. The human picked a target, set things in motion, and stepped back. The agent did the reconnaissance, made decisions, recovered from surprises, and improvised against a database whose schema it had to guess. The economics of that are what change.⁵

For a long time, the bar to running a complex multi-step intrusion was engineering time. Somebody had to sit down and write a playbook for the specific stack they were attacking. That is what kept the most damaging attacks expensive and rare. With an agent doing the composing, the bar drops to inference budget. Pennies per minute of model time.³

The other shift is harder to put a number on. A scripted attacker that hits an unexpected file or a missing schema either falls back to something hard-coded or aborts. An agent reads the surprise, reasons about it, and tries something else. As the Sysdig team noted, the attacker no longer needs to see your environment to operate inside it.¹

What this means if you work in IT

A few things are worth taking away from this without spiraling.

If you run anything internet-facing, the patch window matters more than it used to. CVE-2026-39987 was already on CISA's Known Exploited Vulnerabilities list before this incident, and the federal due date for patching had passed.¹ If a known bug shows up in your inventory, the time between disclosure and an automated agent exploiting it at scale is now measured in hours, not weeks.

Signature-based detection ages quickly against this kind of attacker. A pre-built playbook leaves fingerprints, the same command order, the same probe sequence, the same user agent string. An agent composes against the environment it sees, so the fingerprint is different every time.¹ The detection that holds up is rooted in what the attacker is trying to accomplish (reading credentials, dumping a database, escalating to admin), not the specific commands they ran to get there.

And if you have credentials sitting in environment variables or .env files on internet-reachable hosts, this is your reminder. The minute someone gets a shell, those credentials are gone, and the next pivot is automated.

The honest part

None of this means the sky is falling. The attack Sysdig caught was clever, but it was not magic. It exploited an unpatched vulnerability that should have been patched. It harvested credentials that should not have been on disk. It moved laterally through an environment that, if you squint, could have been built tighter.

The point of stories like this is not to make IT folks feel like they are losing a race. The point is to notice that the work we have always known we should do (patching faster, keeping secrets out of source, paying attention to what credentials touch what infrastructure) just got more rewarding to do well, and more expensive to ignore.²

If anything, there is good news here for the security side of IT careers. The skills that matter most going forward are not "can you write a faster script than the attacker." They are "can you reason about what an attacker is trying to do, and put the right guardrails in the way." That is human work for a while yet.