Autonomous cloud attack paths now outpace static IAM scanning

At a glance

What this is: OFFENSAI says an autonomous offensive agent solved all 122 Datadog Pathfinding Labs in AWS, highlighting that live privilege-path discovery can beat static misconfiguration scanning.

Why it matters: IAM teams need to focus on reachable permission chains, not just isolated misconfigurations, because attacker-style enumeration can uncover escalation paths that signature-based tooling misses.

Context

Cloud IAM risk is often treated as a list of bad settings, but attackers experience it as a graph of reachable actions. A single permission rarely creates compromise on its own; the risk comes from how identities, roles, and service permissions connect inside one account and across accounts. That makes privilege escalation a discovery problem, not just a posture problem.

This article is about autonomous reasoning over cloud identity paths, especially AWS roles, PassRole chains, CreateAccessKey, and cross-account assumptions. The identity angle is real and central: the question is whether a system can discover and traverse non-obvious permission paths faster than static scanning can flag them.

For IAM and NHI programmes, the practical issue is that path risk is contextual. A permission set that looks harmless in isolation can become dangerous when combined with service-specific behaviours, workload identities, or delegation chains.

Key questions

Q: What breaks when static IAM scanning is used instead of path-based analysis?

A: Static scanning breaks when the dangerous condition is not a single misconfiguration but a chain of reachable permissions. A policy can look acceptable in isolation while still allowing role passing, key creation, or cross-account movement. Path-based analysis is needed because attackers exploit the composition of entitlements, not just their presence.

Q: Why do low-privilege AWS identities still create escalation risk?

A: Low-privilege identities still create escalation risk because they can often reach service actions that unlock broader access once combined with other permissions. The danger is not the starting foothold alone, but the next valid step in the environment. If the identity can enumerate and chain permissions, privilege boundaries can collapse quickly.

Q: How do IAM teams know whether token controls are actually working?

A: IAM teams should look for short revocation latency, low scope overlap, clear ownership, and successful invalidation across downstream applications. If tokens survive role changes, show up in multiple systems, or cannot be revoked centrally, the control is failing. Governance success is measurable by how quickly access disappears when it should.

Q: What should teams do when service-specific escalation paths appear in cloud accounts?

A: Teams should treat them as governance gaps, not just isolated configuration issues. Service-specific paths often reveal that role trust, delegation, and workload permissions were reviewed separately instead of as one attack surface. The response is to re-map the environment around reachable abuse paths and close the ones that lead to sensitive assets.

Technical breakdown

Why static IAM scanning misses reachable attack paths

Static scanners answer whether a configuration matches a known bad pattern. They do not reason through the sequence of actions an attacker can actually take from a low-privilege foothold. In AWS, escalation often depends on relationships between permissions, such as who can pass a role, who can mint an access key, or which function can be overwritten. Those relationships only become dangerous when they are reachable in the live environment. That is why an identity graph matters more than a single misconfiguration flag: the exploit is usually a chain, not a line item.

Practical implication: model IAM as a reachable-path problem and validate escalation chains, not just individual policy statements.

Why contextual enumeration changes cloud privilege escalation

Contextual enumeration means the agent builds knowledge from the environment before choosing the next action. Instead of assuming the answer exists in a policy signature, it inspects identities, roles, and service relationships, then follows the edges that are actually present. This mirrors attacker behaviour in cloud environments, where the critical step is not knowing that PassRole exists, but knowing which identity can use it, in which order, and toward which target. In NHI terms, the same logic applies to service accounts, workload identities, and delegated credentials: standing access becomes exploitable when context reveals a valid next hop.

Practical implication: test whether your controls detect live privilege chains, not just known risky permissions.

What the lab results say about service-specific escalation risk

The longest paths in the article clustered around services such as Cognito Identity and SageMaker, not the simplest role chains. That is a useful signal because it shows where public playbooks and common scanner signatures are weaker. The security issue is not that these services are uniquely insecure in isolation, but that their permissions and control flows can create unusual escalation routes when combined with other AWS capabilities. This is exactly where cloud identity governance and NHI oversight overlap: service identities, cross-account roles, and workload permissions can produce attack paths that are easy to miss if you only audit the obvious.

Practical implication: expand review coverage to service-specific escalation patterns and cross-account identity paths, not only core IAM policies.

Threat narrative

Attacker objective: Reach admin-level control or sensitive bucket access by discovering and traversing a live AWS privilege-escalation path.

1. Entry begins with a low-privilege AWS identity that can call only a minimal set of actions, enough to establish context but not direct control.
2. Credential and privilege discovery then enumerates roles, service permissions, and delegation edges such as PassRole and CreateAccessKey to identify a reachable escalation path.
3. Escalation follows when the agent chains those permissions into administrative reach or access to a sensitive S3 bucket.
4. Impact is successful capture of the target objective without human assistance or prior knowledge of the lab solution.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Autonomous path discovery is now the control problem, not static misconfiguration detection. The article shows that reachable permission chains matter more than isolated policy flaws. IAM governance that only asks whether a bad permission exists will miss the more important question of whether an attacker can walk from one benign entitlement to the next. Practitioners should treat privilege reachability as a primary risk dimension.

Cloud identity risk is becoming graph-shaped. The real exposure sits in relationships between roles, workload permissions, and service-specific actions such as PassRole and access-key creation. That is especially relevant to NHI governance because machine identities often inherit broad service reach without the review pressure applied to human accounts. The practitioner implication is to govern paths, not just accounts.

Autonomous offensive testing exposes where security knowledge is still signature-bound. The hardest labs were not the obvious multi-hop cases but the service-specific ones, which suggests many controls are tuned to common patterns rather than live environment reasoning. That is a warning for teams using posture tooling as a proxy for attack resistance. They need validation that follows real escalation sequences, not just policy linting.

Contextual reasoning will increasingly separate useful attack simulation from vanity automation. The important signal is not that a model can list known AWS primitives, but that it can assemble them into a working chain in an unfamiliar environment. That shifts evaluation toward environment-aware autonomy, where the test is whether the system can discover the path that matters. Practitioners should measure whether their governance can keep up with that same level of reasoning.

Privilege escalation detection needs to align with the actual cloud control plane. This article reinforces a broader industry pattern: the attack surface is the set of permissions that can be composed, not the set that can be named in a checklist. For IAM leads, that means validating delegation, role assumption, and service-to-service trust as first-class governance objects. The field should move from configuration review to path governance.

What this signals

Attack-path governance is becoming the right operating model for cloud IAM. The important shift is from asking whether a permission exists to asking whether it can be combined into a working escalation route. That is especially relevant for NHI programmes, where service accounts and workload identities often inherit trust relationships that are hard to see in conventional reviews.

Pathfinding Labs shows why machine identities need the same reachability discipline as human admin accounts. In cloud environments, a non-human identity can be the first foothold, the delegation bridge, or the escalation vehicle. Practitioners should therefore govern the path an identity can traverse, not just the role name attached to it.

For practitioners

• Map reachable privilege chains Build an access graph for AWS identities, roles, and service permissions so reviewers can see which entitlements can actually be composed into escalation paths.
• Prioritise service-specific escalation testing Create test cases for Cognito Identity, SageMaker, Lambda, ECS, Glue, and other services where escalation depends on behaviour beyond common IAM patterns.
• Review PassRole and key-minting permissions together Treat PassRole, CreateAccessKey, AssumeRole, and similar delegation actions as a connected risk set rather than separate checklist items.
• Validate cross-account trust paths Inspect role trust policies and account boundaries for chains that let a low-privilege identity move from one account to another through delegated access.
• Test posture tools against live attack paths Compare scanner output with attack-path analysis to see whether your tooling can explain how a low-privilege foothold becomes administrative reach.

Key takeaways

• Static IAM scanning is insufficient when privilege escalation depends on reachable sequences of actions rather than single misconfigurations.
• The article's core evidence is that an autonomous agent solved all 122 AWS labs, with the hardest paths taking up to 17 turns, which shows how much context attacker reasoning can uncover.
• IAM and NHI teams should shift from entitlement review to path governance, with special attention to service-specific escalation routes and cross-account trust.

Key terms

• Attack path: A sequence of identities, permissions, systems, and data stores that an attacker can traverse after obtaining trusted access. In practice, attack paths matter more than single accounts because they show how a low-risk identity can become a route to high-value exposure.
• Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
• Reachable Permission: A reachable permission is an entitlement an attacker can actually use from a current foothold, not just one that exists on paper. This concept matters because cloud risk is created by what can be composed and executed in the live environment, especially across identities, roles, and services.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. If your programme now has to govern cloud identities, workload permissions, and delegated access paths, the course gives your team a common security baseline.