Every cloud environment has doors nobody remembers leaving open: a permission granted for a project that ended, a role scoped broad because narrow felt slower, a service account nobody’s touched since it was created. That access used to sit dormant because finding it took patience and expertise just a few, nation-state attackers had. Not anymore. In July, researchers detected the first known case of fully-agentic ransomware, an AI agent that ran a full extortion operation on its own, and it worked by walking through exactly this kind of standing access, door after door, without a human ever touching the keyboard.

Your business had to grow, and access grew with it

The over-permissive nature of the cloud eventually comes down to one simple fact - the business needs to keep running. A new service needs to talk to three others, so someone attaches a broad role instead of writing the narrow policy, because shipping today matters more than a scoped permission that might block something next month. A contractor gets admin for a two-week project and nobody remembers to revoke it in month six. A service account gets created once, works, and then nobody touches it again, because touching working infrastructure feels riskier than leaving it alone.

None of that is negligence. It’s just what happens when granting access is cheap and removing it is expensive, in effort and in the risk of breaking something nobody fully remembers anymore. Multiply that across every account, every service, and every third-party integration a business has signed up for over the years, and you get an environment where what’s allowed has almost nothing to do with what anyone actually needs. Microsoft’s own research backs this up: 98% of the permissions granted to human and workload identities in the average multicloud environment go unused. That’s nearly all of a cloud’s access sitting there, granted, unused, and unreviewed.

For a long time this was a “hygiene” problem, because dormant access mostly stayed dormant. A permission nobody had used in three years was still, practically speaking, a permission nobody was going to stumble into by accident. That’s the assumption the last decade of cloud security tooling was built on, and it’s the assumption that just stopped holding.

AI doesn’t wait to notice. It walks every open path today

A human attacker works through a list of possibilities one at a time, gets tired, gets pulled onto something else, and misses things. An AI agent, on the other hand, can perform full reconnaissance in minutes. All an attacker needs to do is point one at an environment and it will try every credential, enumerate every reachable service, and follow every permission that’s technically still valid, all in parallel, without ever needing a break. Dormant access stops being dormant the moment something is willing to try every door at once and never gets bored.

This plays out in two ways. The obvious one is on the attacker’s side: agentic tooling has collapsed the skill floor for offense to the cost of a monthly subscription. A single hacker can now run reconnaissance and move laterally in minutes - tasks that used to take a skilled team days. The less obvious threat is that attackers don’t even need to bring their own agents, because you’re likely already running them. The same assistant your team brought in to save time inherits whatever access its identity was granted. Whether that agent makes a clumsy mistake while trying to be helpful, or gets manipulated into using that access where it doesn’t belong, the result is the same. Nothing had to break in. Something you already trusted just started going through those same doors on someone else’s behalf.

Either way, every unused, over-scoped, and forgotten permission in your environment becomes an immediate target, tested at the speed of the model. That means teams can no longer hope to out-run AI-driven attacks. Instead, we need to take a step back and block access risk right where it starts, at the infrastructure layer.

It already happened, and nobody touched the keyboard.

This isn’t hypothetical anymore. In July, Sysdig’s threat research team published research on an operation they named JADEPUFFER, calling it “what we assess to be the first documented case of agentic ransomware: a complete extortion operation driven end-to-end by a large language model (LLM).” By their own account, there was no human at the keyboard for any of it. Here’s how it actually played out, step by step:

1. Got in through a known flaw. It exploited an unauthenticated code-execution bug in Langflow, an open-source tool for building AI agents, letting it run Python straight on the host.
2. Harvested what was lying around. It swept the environment for API keys and cloud credentials, dumped Langflow’s own database, and found an object store answering on the default MinIO address with a password nobody had ever changed, minioadmin:minioadmin.
3. Walked through that unlocked door. The default credential handed it several buckets, including one holding Terraform state, and a file it already knew to look for by name, credentials.json, containing a live access key and secret.
4. Moved to its real target. It pivoted to a separate database server and exploited a five-year-old authentication bypass in Nacos, Alibaba’s configuration service, because the default signing key, public since 2020, had never been rotated.
5. Planted a backdoor, then fixed its own mistake. Using root database credentials of unknown origin (Sysdig never saw how JADEPUFFER got them) it inserted a backdoor admin account. The first attempt failed. Thirty-one seconds later, having diagnosed the error and rewritten the fix itself, the account worked, faster than most people can read a stack trace.
6. Encrypted, ransomed, and destroyed. It encrypted 1,342 configuration records, planted a ransom note, and started dropping entire databases, leaving comments in its own code about which one to destroy next: “REDACTED is largest - drop it too.”

Look underneath, and it’s the same weak point every time: access

Go back through what actually let JADEPUFFER move, and none of it required real skill. A MinIO instance answering to a default password nobody had rotated. A signing key that’s been public since 2020 because nobody forced a rotation. A database account with root privileges reachable straight from the internet, because at some point that was the fastest way to get something working. Every one of those is exactly the kind of access described earlier: granted for convenience, maybe even necessary at the time, then left in place because removing it felt riskier than leaving it alone.

JADEPUFFER didn’t find a zero-day. It found a cloud that looked like every other cloud, mostly fine on paper and quietly reachable underneath. The vulnerability that got it in the door, an unauthenticated code-execution bug in Langflow, mattered less than what was waiting on the other side of it. Patch that one bug and the operation still had a handful of standing weaknesses left to traverse through before anyone would have noticed. The entry point changes every time. What actually decides how far an attacker, human or AI, gets once they’re in is the standing access nobody circled back to remove.

Here’s what keeps you off the list

Sysdig’s own recommendations for this exact case are the right immediate moves:

• Patch the Langflow flaw.
• Rotate Nacos’s signing key instead of shipping the documented default.
• Keep Nacos off the open internet and away from a root database connection.
• Add egress controls so a compromised host can’t beacon out to a stranger’s server.
• Run detection built to catch this kind of behavior inside the database layer.

Do all of that and you’ve closed the specific chain JADEPUFFER used.

But the chain was never really the point, the standing access underneath it was, and that’s a bigger job than patching one flaw. Start here:

• Map what every identity can actually reach, not what its policy claims it should reach, including the identities behind AI orchestration servers and the agents wired into everyday workflows.
• Use what’s already free in your cloud. AWS IAM Access Analyzer, GCP’s IAM Recommender, and Azure access reviews all surface unused access you can take back today, no new tool required.
• Put removal on a schedule, not a once-a-year audit. A permission that was safe to ignore in 2024 isn’t safe to ignore in an environment where an agent might try it in the next five minutes.

That’s the piece Act is built around. We map what every identity can reach across a cloud, surface the access that’s standing but unused, dormant, or simply broader than the job requires, and safely remove it through native cloud controls instead of adding another dashboard for someone to read later.

The goal was never a better description of exposure. It’s making sure the only ways into your environment are the ones that have to stay open. And when someone does get in, because eventually someone will, that’s when they find dead ends instead of open paths, no easy next hop, no quiet route to the next system, just enough friction that they give up and go bother someone else.