Eight minutes to admin: why AI-assisted attacks shrink cloud response time

I read a breach report from The Register recently that stuck with me, not because an attacker used AI — that is not news any more — but because of how ordinary the rest of the story was. An intruder got from stolen credentials to administrative privileges in an AWS account in about eight minutes, according to Sysdig’s analysis. The intrusion happened on 28 November 2025, and Sysdig published its report on 3 February 2026. No novel exploit, no zero-day. Just a familiar attack path, run faster than a human would manage alone because, in Sysdig’s assessment, an AI copilot was helping with the code.

That is the part worth sitting with. Not “AI can attack you,” which we already knew, but “AI has quietly deleted the response-time cushion you were counting on.”

Three things are true at once right now, and they do not resolve into a tidy story:

• LLMs help attackers reason, plan, and generate exploit code faster than before.
• LLM APIs are themselves valuable cloud resources now, which makes them targets — credential theft, quota abuse, and what the security world calls LLMjacking. LLMjacking is the theft of cloud or LLM API credentials to run a victim’s paid model access at the victim’s expense.
• LLMs are embedded deep inside production systems used by hundreds of millions of people, sitting in the same blast radius as your databases and queues.

Banning AI use is not a serious answer to any of this — I am not going to pretend it is. The real question is narrower and more useful: how do you design infrastructure that stays resilient when the attacker on the other end has an AI copilot too? That is what this post is about.

How a stolen credential became an administrator

Sysdig’s reconstruction reads like a checklist of things that were each individually plausible. A test IAM user, likely created on purpose to automate Bedrock tasks with Lambda, had its credentials sitting in public S3 buckets that held RAG data. The attacker did not have to break anything. They simply used what that user was allowed to do.

Notice what is missing: a zero-day. Every step is an ordinary permission doing exactly what it was told to. The whole operation lasted about two hours and touched 19 principals, but the eight minutes to administrator is the part that matters for defenders.

Agentic attacks in 2026: JADEPUFFER and the marimo database breach

Two terms get blurred in the headlines. In an AI-assisted attack, a human uses an LLM to research, generate or adapt code. In an agentic attack, software drives an LLM in a tool-execution loop: it runs a command, reads the result, chooses the next action and adapts, with little or no human in between. Sysdig describes the eight-minute breach as the first kind, with LLMs used throughout the operation. It has since documented two cases it assesses to be the second kind. Those are the researchers’ conclusions from observed evidence, not proof that every stage was autonomous.

The first, published on 1 July 2026, is what Sysdig assesses to be the first documented case of agentic ransomware, tracked as JADEPUFFER; CyberScoop reported it. The entry point was a Langflow vulnerability (CVE-2025-3248, an unauthenticated remote code execution flaw in the /api/v1/validate/code endpoint of Langflow before 1.3.0). CyberScoop reports more than 600 distinct payloads in rapid succession, and that the agent accessed OpenAI, Anthropic, DeepSeek and Gemini keys while gathering information about the victim. Sysdig is careful about what it claims: it cannot see the operator’s prompt or configuration, so its conclusion that an LLM drove the operation end to end rests on inferences from the payloads.

The second happened on 10 May 2026. Sysdig described an LLM agent (report published 26 May) moving from a vulnerable marimo notebook (CVE-2026-39987) to an internal PostgreSQL database in four pivots and about an hour: remote code execution, replayed AWS credentials, an SSH key held in AWS Secrets Manager, and an SSH bastion. Different entry points, same underlying story: the skill and time an attack used to require have both dropped, and the defence has to be structural rather than reactive to keep up.

Does banning or filtering AI stop offensive use?

Banning AI use is roughly as effective as making compilers safe by banning certain keywords. The tempting alternative is narrower: limit what a model will generate. Rate-limit code that matches exploit patterns, flag reconnaissance-style prompts like “how do I escalate AWS privileges”, add policy filters around exploit terminology.

Provider-side safeguards have a real job. They slow down inexperienced attackers, create an audit trail, and catch obvious misuse at scale. But the hard problem is intent, not content. A blue-team engineer, a pentester, and an attacker often ask exactly the same question, for different reasons. Block the knowledge and you block the defenders along with the attackers. A determined attacker just rephrases, switches to a local model, or chains the steps together by hand.

Think of filtering as a seatbelt. It helps, and I would not drive without one, but it is not the crash structure. Safeguards on model outputs cannot replace the controls that protect your cloud account.

Why IAM design beats restricting LLM capabilities

An LLM is a general-purpose tool, not a gated capability. We never managed to restrict search engines, compilers, debuggers or documentation, and AI joins that list rather than breaking the pattern.

What we can do is harden the infrastructure so exploits stay hard even with perfect AI guidance, detect misuse before the attacker reaches the objective, and focus on privilege boundaries rather than prompt text.

The weakness in the eight-minute breach was never the model. It was a chain of ordinary things: credentials in a public bucket, an IAM user that could rewrite a Lambda function, and a function running as an administrator. Permission to change code that runs as a privileged role is, in effect, permission to use that role. The fix is not stricter AI rules. The fix is better IAM design, which is a less exciting sentence than it deserves to be, given how much it would have prevented.

Privilege escalation without breaking anything

Think of a hotel guest who has no key to the manager’s office but is allowed to rewrite the instructions the manager follows each morning. The guest never opens the door. The manager does it for them.

In AWS terms: a developer cannot read a production secret directly, but can update a Lambda function whose execution role can. They edit the function to read the secret and return it. That is the shape of the eight-minute breach, with an administrator role standing in for the secret. Least privilege applies to identities, and also to the relationships between identities, code and services: who can change what runs as whom.

IAM policies, boundaries and SCPs

These controls answer different questions, and the last one is easy to mistake for a replacement for the others:

Effective permissions are the intersection of what these controls allow, and an explicit deny anywhere wins. AWS puts it plainly: if a permission is blocked by an SCP, a user in the account cannot use it, even with the AdministratorAccess policy attached. That is what makes an SCP a useful backstop.

Infrastructure hardening is the crash structure: least privilege still limits blast radius, ephemeral credentials still expire, SCPs still block forbidden actions, detection still fires on anomalous behaviour, regardless of how capable the attacker’s AI gets. AI does not bypass physics, permissions, or trust boundaries. It just gets attackers to them faster. That compression of time, not any new kind of cleverness, is the actual change.

How to apply access control to LLM resources with SCPs and least privilege

Access control is where things get concrete, and where I would actually spend my time.

An LLM running in your cloud account is a resource, the same as an S3 bucket or a database, and it deserves the same discipline:

• Service Control Policies (SCPs): AWS Organizations guardrails that set the maximum permissions for member accounts and, as above, grant nothing by themselves. They do not apply to the management account, so keep workloads out of it. AWS publishes an example SCP for Amazon Bedrock that denies every model except an approved list.
• Monitoring for anomalous model usage — sudden spikes, unfamiliar regions, odd invocation patterns.
• Treating LLM API keys like credentials: rotate them, scope them to least privilege, keep them environment-scoped rather than shared.

Sysdig, the firm that documented the eight-minute breach, recommends exactly this: SCPs to limit approved Amazon Bedrock models, model invocation logging, and least privilege on IAM execution roles (source) — and it works because it targets a real attack surface instead of an abstraction. You can deploy this today. It is not a research programme.

LLMjacking is not only about stolen API keys. Sysdig’s June 2026 research also covers exposed model servers: Ollama listens on port 11434 with no authentication by default, and researchers have catalogued roughly 175,000 publicly exposed instances. On 12 June 2026, Sysdig saw an actor use a misconfigured Ollama server as the reasoning engine for an automated offensive security tool, observed in development against practice ranges rather than real victims. If you run local models, keep them bound to localhost or behind authentication. Free compute is attractive to everyone.

Assume breach: ephemeral credentials and fewer privilege-escalation paths

The shift that actually matters is architectural, not model-specific:

• Ephemeral credentials. Short-lived, automatically expiring IAM role sessions, no long-term access keys sitting around waiting to leak.
• Design for “assume breach.” Expect lateral movement, and minimise how far it can get.
• Reduce privilege-escalation paths. In the eight-minute breach, the stolen IAM user could change the code of Lambda functions. One of them ran as an administrator, so the attacker overwrote its code to create access keys for an admin user and read them from the function’s output. Sysdig notes that swapping a function’s execution role needs both lambda:UpdateFunctionConfiguration and iam:PassRole, but nothing in the report shows this attacker needed that: the powerful role was already attached to the function.

Short-lived credentials are not a cure-all. They shrink the window in which a stolen key is useful, which would have mattered here, where the key belonged to an IAM user and sat in a bucket. But they do not help once the attacker is inside a running workload, because that workload keeps receiving fresh credentials. Short-lived credentials reduce exposure; least-privilege roles limit damage. You need both.

The eight-minute timeline is the argument in miniature, although I would not treat eight minutes as a universal deadline. There is no rule that detection must beat code generation. What matters is whether you can detect and contain an attack before it reaches its objective. Three measures help you check:

If the attack progression time is eight minutes and your MTTD is thirty, the arithmetic is not on your side.

Can you recognise signs of AI-assisted attacks?

The eight-minute breach left a few clues. Sysdig noted that the script’s comments, comprehensive exception handling and the speed at which it was written strongly suggest LLM generation. The comments were in Serbian, which Sysdig reads as a likely hint about the actor’s origin, not about the AI. The same report lists other signs it calls consistent with AI hallucination: invented AWS account IDs (runs of ascending and descending digits) and a reference to a GitHub repository that does not exist.

None of this is proof. Clues like these are consistent with LLM use; they do not establish who, or what, wrote a script. And attackers adapt: comments get stripped, code gets cleaned up, prompts get refined. Useful as a signal. Not something to build a defence on.

Signs of AI assistance matter less than what the activity does. Here is a sequence worth correlating across identities and resources, because the eight-minute breach produced most of it:

• An unexpected UpdateFunctionCode20150331v2 event on a function with a privileged role. That is how CloudTrail records the Lambda UpdateFunctionCode call.
• The function running shortly afterwards, followed by IAM activity such as new access keys.
• New administrative access, or unusual Secrets Manager reads.
• Spikes in Bedrock model invocations, or GPU instances launching that nobody asked for.

Any one of these is noise. Four in a row from one identity, within minutes, is a story.

Cloud security priorities against AI-assisted attacks

If I had to prioritise, in order:

1. IAM design. Remove privilege-escalation paths. Ask who can change code that runs as a privileged role, and minimise UpdateFunctionCode, UpdateFunctionConfiguration, PassRole and any wildcard permission you can find.
2. Credential strategy. Short-lived, scoped, and rotated automatically — not by whoever remembers to do it quarterly.
3. Detection speed. Use behaviour-based alerting alongside signatures. Exact indicators age out quickly; behaviour is harder to change, though attackers can adapt that too.
4. Blast-radius reduction. Separate accounts, roles, and environments, so a single compromised credential cannot reach everything.
5. Operational readiness. Assume breach, and actually rehearse the response rather than filing it as a policy document.

None of this depends on how clever the attacker’s AI happens to be. That is the entire point of building it this way.

Prevention will sometimes fail, which is why I would add recovery to the picture: immutable backups, rehearsed incident playbooks, and a tested way to revoke credentials in a hurry.

A five-minute AWS security check

The eight-minute breach turned on three questions you can ask of your own account today: which role does this function run as, what can that role do, and who changed the function recently? The commands below only read configuration and events. They change nothing, so they are safe to re-run. They assume the AWS CLI v2 and credentials that may read Lambda, IAM and CloudTrail. The syntax follows the AWS CLI reference, but try them in a sandbox account first if you can.

1. Find the execution role of a function

# Read-only: show the execution role and last change time of one Lambda function
aws lambda get-function-configuration \
  --function-name my-function \
  --query '{Role:Role,LastModified:LastModified}' \
  --output json

{
    "Role": "arn:aws:iam::123456789012:role/my-lambda-role",
    "LastModified": "2026-10-09T08:14:52.000+0000"
}

That output is illustrative; the account ID is AWS’s documentation placeholder. Look at the role. Does this function need everything the role allows, and is the role an administrator?

2. Inspect the role’s policies

# Read-only: list the managed and inline policies attached to a role
aws iam list-attached-role-policies --role-name my-lambda-role
aws iam list-role-policies --role-name my-lambda-role

These return policy names, not permissions, so open each policy and read what it allows. AdministratorAccess, or any "Action": "*" on a role that function code can reach, deserves a second look.

3. Find recent code updates

# Read-only: the 20 most recent Lambda code updates in the current region (last 90 days)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=UpdateFunctionCode20150331v2 \
  --max-items 20 \
  --query 'Events[].{Time:EventTime,User:Username,Event:EventName}' \
  --output table

CloudTrail logs this call as UpdateFunctionCode20150331v2, not plain UpdateFunctionCode, according to the Lambda documentation, so searching for the plain name finds nothing. Event history covers the past 90 days of management events in a single region, so repeat the command per region. It is no substitute for an organisation-wide trail with alerting. The question to ask is simple: who changed this function, and was that change expected?

Two cheap follow-ups: enable Lambda versioning and aliases, as Sysdig recommends, so a silent code swap is easier to spot, and set an alert on the same CloudTrail event.

Do on-device models protect against AI-assisted attacks?

Running models locally (speech-to-text, summarisation, document processing) protects users: less data leakage, less centralised logging, less exposure of sensitive inputs. It does not stop an attacker from using AI, or prevent AI-assisted exploitation of your infrastructure. This is privacy protection, not intrusion prevention. Both are worth having. They are not substitutes for each other.

Key takeaways: least privilege, fast detection, small blast radius

LLMs did not break cloud security. They exposed how optimistic our assumptions already were: that attackers move slowly, that humans are the bottleneck, that there would be time to notice and react. Those assumptions were quietly wrong before AI showed up. AI just made the gap hard to ignore.

The mature response is not to muzzle AI on either side of this. It is to build infrastructure that stays standing when AI is involved in the attempt to break it: least privilege, fast detection, small blast radii, short-lived trust. We cannot stop people from using tools.

AI did not create the exposed credentials, the vulnerable endpoints, or the excessive permissions. It made exploiting them faster. That is where our defences need to improve.

Did you find this useful? Let me know how your own IAM boundaries hold up against an eight-minute clock — I would like to hear what you find.

References

1. AWS intruder pulled off AI-assisted cloud break-in in 8 mins — The Register
2. AI-assisted cloud intrusion achieves admin access in 8 minutes — Sysdig
3. What is LLMjacking? — Sysdig
4. Sysdig clocks first documented case of agentic ransomware — CyberScoop
5. CVE-2025-3248 — NIST National Vulnerability Database
6. AI agent at the wheel: How an attacker used LLMs to move from a CVE to an internal database in 4 pivots — Sysdig
7. JADEPUFFER: agentic ransomware for automated database extortion — Sysdig
8. LLMjacking evolved: attackers are using stolen AI compute to build offensive agentic tools — Sysdig
9. Service control policies (SCPs) — AWS Organizations User Guide
10. Example SCPs for Amazon Bedrock — AWS Organizations User Guide
11. Logging AWS Lambda API calls with AWS CloudTrail — AWS Lambda Developer Guide
12. Viewing CloudTrail event history — AWS CloudTrail User Guide
13. lookup-events — AWS CLI Command Reference