AI-assisted cloud breaches expose the failure of static IAM controls

At a glance

What this is: This is an architectural post-mortem of an LLM-assisted cloud breach showing that static IAM controls were outpaced by AI-driven reconnaissance and privilege escalation.

Why it matters: It matters because IAM, PAM, and cloud security teams need controls that bind access to current task context, not assumptions about how long an attacker will take to act.

Context

AI-assisted cloud breaches are a governance problem as much as an incident-response problem: once attackers can enumerate services and pivot inside minutes, static permission models lose their protective value. The core issue is not speed alone but the mismatch between human-paced control design and machine-paced attack execution.

In this case, the article describes a compromised S3 bucket, valid AWS credentials, broad service enumeration, and rapid escalation into admin-level access. That pattern is especially relevant to NHI governance because the exposed credentials, standing permissions, and runtime authorisation gaps are all machine-access control failures rather than user-authentication failures.

Key questions

Q: What breaks when AI-assisted attackers find valid cloud credentials?

A: The first thing that breaks is the assumption that discovery is slow enough for human response to matter. Once a valid credential is exposed, attackers can enumerate services, locate escalation paths, and pivot before normal review cycles even begin. The control gap is not just secret exposure, but secret exposure with standing value.

Q: Why do broad-but-legitimate permissions become dangerous in cloud breaches?

A: Because a harmless-looking permission can become a bridge when combined with another action. In the article, ReadOnlyAccess plus UpdateFunctionCode created a path from observation to persistence, which means risk often comes from permission combinations rather than a single overpowered role. Teams must analyse chained authority, not isolated entitlements.

Q: What are the signs that runtime authorization is failing?

A: Look for inconsistent access behaviour across services, repeated policy logic in code, slow manual change cycles when rules move, and decision logs that cannot explain allow or deny outcomes. Those are signs the authorization layer is not operating as a shared control.

Q: Should teams prioritise zero standing privilege over faster detection for AI-assisted cloud risk?

A: Yes, because faster detection cannot compensate for controls that allow durable access to exist in the first place. If a principal has no standing privilege, there is less to steal, repurpose, or chain during a rapid attack. Detection still matters, but it should not be the primary control against machine-paced privilege escalation.

Technical breakdown

Why static IAM breaks under AI-assisted reconnaissance

Static IAM assumes the main risk is what a principal can do once access is already granted. In the article’s breach path, attackers used an LLM to enumerate more than 10 AWS services in 2 to 3 minutes, which turns reconnaissance into a compressed, automated decision loop. When access is pre-authorised and broadly reusable, the attacker does not need to guess much. They only need to chain valid permissions faster than defenders can notice the pattern. That is why the real failure is not one exposed bucket but the architecture that allowed standing access to remain meaningful after discovery.

Practical implication: treat broad standing permissions as an attack accelerator, not just a convenience risk.

How Lambda and Bedrock became privilege bridges

The article shows a common cloud failure mode: a low-friction permission such as ReadOnlyAccess sits beside an operational permission like UpdateFunctionCode, and the combination becomes far more powerful than either one alone. The attacker used that bridge to modify code and create new admin keys, which is a privilege-escalation path built from legitimate functions. Later, the move into Bedrock and GPU provisioning extended the same pattern across service boundaries. In other words, authorisation was evaluated per action, but the environment was exploitable across chained actions. That is a runtime authorisation problem, not a single-role problem.

Practical implication: map which benign-looking permissions become administrative when chained across services.

Why zero standing privilege matters more than faster detection

Zero standing privilege changes the question from how quickly you can react to how much power exists before a task begins. The article argues that if access is only created at the moment of need, there is no static credential to steal and no dormant update path to reuse. That matters because the attacker’s success depended on credentials and permissions that already had standing value before the breach began. The architectural lesson is that cloud security cannot rely on alerting alone when the control failure is prior to detection. Security must prevent the state that makes the attack viable.

Practical implication: move high-risk cloud access to task-scoped issuance rather than permanent entitlement.

Threat narrative

1. Entry occurred through valid AWS credentials discovered in a public S3 bucket containing RAG data, giving the attackers a legitimate starting point rather than forcing a brute-force compromise.
2. Credential access and reconnaissance followed immediately as the LLM-driven workflow enumerated more than 10 AWS services, including Secrets Manager, RDS, and CloudWatch, in 2 to 3 minutes.
3. Escalation happened when UpdateFunctionCode on Lambda was used to modify a function and create new admin keys, converting limited access into durable privilege.
4. Impact was reached when the attackers spread activity across 19 AWS principals and pivoted into Bedrock to invoke models and provision expensive GPU instances.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Automated Logic Enumeration is the right name for this failure mode: the breach was not just faster attack execution, but a machine-paced discovery loop that collapsed the defender’s response window. Static IAM assumes security teams have time to observe, interpret, and intervene. When an LLM can enumerate services in minutes, those assumptions no longer hold, and the governance model itself becomes the weak point.

Standing credential value is the hidden control gap: the compromised S3 bucket mattered because the credentials inside it retained reusable value after exposure. That is the exact condition NHI governance is supposed to prevent, yet many programmes still treat secret location as the control rather than secret lifespan. The breach shows that access does not need to be broad to be dangerous if it remains valid long enough to be discovered and chained.

Runtime authorisation failed because the system trusted action-level permissions more than task-level context: UpdateFunctionCode became a permission bridge into persistence because the environment did not require a verified deployment intent at the moment of execution. This is the kind of privilege creep that static IAM normalises. Practitioners should see it as evidence that authorisation must be evaluated at runtime, not just at provisioning.

Identity is now the only durable perimeter across cloud, data, and AI services: the article’s Bedrock pivot shows why separate policies for cloud services, AI services, and data layers create an integration tax attackers can exploit. The real governance problem is fragmentation across control planes, not just missing alerts. Teams need a unified view of human, machine, and AI identity behaviour or they will keep losing the same race in different services.

Zero standing privilege is the operational expression of the lesson here: the breach only worked because access already existed before the attacker’s task began. If access is ephemeral, there is nothing persistent to steal, modify, or bridge. That is the decisive governance shift for cloud identity programmes: reduce the value of every principal before it can be turned into an attack path.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

Automated Logic Enumeration: teams should treat machine-paced discovery as a design constraint, not an anomaly. Access models that assume attackers need hours to learn the environment are already misaligned with LLM-assisted tradecraft, especially when broad read permissions expose the map before the defender can react.

Identity blast radius, not just least privilege, now needs to be the planning unit: when a single credential can be used to enumerate services, mutate code, and pivot into AI workloads, the practical question is how far one principal can travel before policy intervenes. That is why cross-service authorisation boundaries matter more than isolated role reviews.

Access reviews only help when the privilege persists long enough to be reviewed. In environments where attackers can move from discovery to escalation in minutes, the control point shifts to issuance time, task context, and service-to-service policy consistency.

For practitioners

• Audit standing access in data and AI-adjacent buckets Inventory S3 locations, RAG stores, and similar data layers for credentials or tokens that retain reusable value outside a live task. Prioritise any object that can be read anonymously or by broadly scoped principals.
• Break permission bridges between read and mutate actions Review combinations such as read-only discovery plus update or code-change permissions, especially where a low-risk role can trigger persistence or key creation through a second service.
• Move high-risk cloud actions to task-scoped approval Require just-in-time issuance for actions such as function updates, secret access, and model invocation when they can alter privilege or cost exposure.
• Unify policy across cloud and AI services Align Bedrock, Lambda, S3, Secrets Manager, and related control points under one authorisation model so cross-service pivots are evaluated as a single identity event.
• Hunt for hallucinatory attacker fingerprints Watch for fabricated account IDs, unusual session naming, and other noisy artefacts that LLM-assisted attackers may leave in logs and API calls.

Key takeaways

• AI-assisted cloud breaches expose a structural mismatch between human-paced IAM controls and machine-paced attack execution.
• The article’s breach path shows how exposed credentials, benign-looking permissions, and service fragmentation can combine into full administrative compromise in minutes.
• Cloud security teams need to reduce standing privilege and collapse policy silos before rapid reconnaissance turns valid access into persistence.

Key terms

• Automated Logic Enumeration: Automated Logic Enumeration is rapid, machine-assisted discovery of services, permissions, and escalation paths. It matters because AI tools can search, test, and chain options far faster than a human attacker, turning reconnaissance into an identity security event that must be governed in real time.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Permission Bridge: A combination of individually ordinary permissions that becomes materially more powerful when chained across services or actions. In practice, a permission bridge is often how low-risk access turns into persistence, code modification, or administrative control without an obvious single misconfiguration.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.