AWS privileged permissions are widening the cloud hijack surface

At a glance

What this is: Sonrai Security’s May recap shows that new AWS privileged permissions can be chained to hijack infrastructure, redirect workloads, or erase operational evidence.

Why it matters: IAM, PAM, and cloud security teams need to treat permission combinations as a workload control problem, not just a review exercise, because the same pattern now spans NHI, DevOps, and AI platform identities.

👉 Read Sonrai Security's recap of May AWS privileged permissions and infrastructure hijacking

Context

AWS privilege expansion becomes a governance problem when individual permissions are designed to control infrastructure components but can be combined into broader control of workloads, networks, and observability. In cloud environments, that creates a familiar identity issue: the access itself may look legitimate, but the combined effect can exceed the intended trust boundary.

For NHI programmes, the risk is not only who can call a permission, but which identities can hold multiple privileged permissions at once. When workload identities, service roles, and platform automation can each accumulate control over deployment, routing, or deletion functions, least privilege has to be enforced at the combination level, not just the single-permission level.

Key questions

Q: What breaks when cloud identities can create, update, and delete the same workload service?

A: When one identity can create, update, and delete the same workload service, least privilege stops being a meaningful control. The identity can deploy arbitrary code, redirect running workloads, and remove the evidence or monitoring agents that would normally expose the abuse. That combination turns a normal service role into a fleet-control mechanism.

Q: Why do privileged cloud permissions increase infrastructure hijacking risk?

A: Privileged cloud permissions increase infrastructure hijacking risk because they can change where workloads run, how traffic moves, and which runtime is trusted. The risk is not only direct compromise. It is that a legitimate identity can alter the environment so the attacker controls execution without needing to bypass the application itself.

Q: How do security teams decide which cloud permissions need extra control?

A: Security teams should prioritise permissions that can redirect execution, expand network reach, or destroy operational state. If a permission can move a workload into a different boundary, alter a daemon across a cluster, or remove the telemetry that tracks activity, it deserves stronger approval, segregation, and review than ordinary read or tagging access.

Q: What is the difference between destructive cloud actions and routine administrative actions?

A: Destructive cloud actions change or remove the operational state that other controls depend on, including sessions, agents, tasks, logs, and workspaces. Routine administrative actions adjust configuration without eliminating the control plane itself. The practical difference is blast radius, not wording, and identity governance should classify permissions accordingly.

Technical breakdown

How chained ECS daemon permissions create fleet-wide workload control

The ECS daemon permissions Sonrai describes work as a sequence, not as isolated actions. Registering a daemon task definition establishes the container payload, creating the daemon deploys it across instances, updating it swaps the workload in place, and deleting it removes the daemon and can erase security tooling. That sequence matters because a single identity holding all four permissions can control execution across the cluster lifecycle. In practice, the security boundary is not one API call but the set of actions that together produce arbitrary code execution at scale.

Practical implication: Separate daemon creation, update, and deletion privileges so no single identity can deploy, redirect, and erase cluster workloads.

Why secondary network and configuration permissions expand the attack path

Permissions such as creating secondary networks or redefining named configurations are privileged because they alter where workloads run and what infrastructure they trust. A secondary network interface can create a new traffic path outside existing monitoring assumptions, while a reused configuration name can redirect automated runs into an attacker-controlled environment without changing the higher-level job reference. This is a classic cloud identity problem: the permission does not need to look destructive to be dangerous if it can quietly change execution context or network locality.

Practical implication: Review permissions that change execution context, not just obvious delete actions, because redirection can be more damaging than direct modification.

Why an archive action on an AI workspace is really an impact control

Sonrai’s example of an external AI platform permission labelled archive shows a common governance trap: a benign-sounding action can still be irreversible and destructive. In this case, archiving a workspace can remove agents, credential vaults, skills, and sessions, which means the control is effectively a delete operation at workspace scope. For identity teams, this is a reminder that action names are not sufficient for authorization design. The real issue is whether the permission can terminate operational state or destroy evidence, regardless of its label.

Practical implication: Classify destructive platform actions by operational effect, not by name, and apply tighter approval and segregation controls to them.

Breaches seen in the wild

• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Infrastructure hijacking is the right lens for this permission pattern. Sonrai’s recap shows that modern cloud privilege is no longer only about data access. Permissions can now redirect compute, alter network paths, and terminate observability across a fleet, which means the attack surface is the infrastructure itself. The practitioner implication is that cloud identity controls must be designed around control-plane consequences, not just resource access.

Permission adjacency is the new privilege creep problem. The breach condition here is not a single excessive permission, but a set of individually plausible permissions that become dangerous when co-resident in one identity. That is a governance failure in entitlement design, not just a review lapse. Security teams need to treat co-occurrence of create, update, and delete operations as a material risk signal.

Workspace archive semantics expose a naming assumption that no longer holds. The assumption that an action called archive is reversible or low impact was designed for administrative cleanup, not for agentic or platform-scale destructive control. That assumption fails when the permission permanently removes agents, vaults, and sessions. The implication is that authorization models must classify actions by blast radius, not label.

Least privilege in cloud now depends on lifecycle sequencing, not static assignment. The most dangerous identities are the ones that can progress from provisioning to execution to teardown inside one permission set. That matters across NHI, DevOps, and emerging AI platform identities because the same executor can now carry the whole control loop. Practitioners should regard chained lifecycle authority as a first-class identity risk.

The market signal is clear: cloud identity governance is converging with workload control. As privileged permissions spread into orchestration, data pipelines, and AI platforms, the old split between identity management and infrastructure security is collapsing. The field needs governance models that can reason over execution authority, not just human-readable roles. The practitioner implication is to align entitlement review with real operational blast radius.

From our research:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to The 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• That gap makes governance redesign urgent, and our Ultimate Guide to NHIs is the clearest next step for building the access model behind it.

What this signals

Infrastructure hijacking is becoming an identity governance pattern, not just a cloud abuse pattern. When permissions can redirect workloads, alter network paths, and erase operational evidence, the control point moves from the workload to the identity that governs it. Teams should expect cloud privilege reviews to converge with NHI lifecycle and PAM controls, especially where create, update, and delete actions coexist in one principal.

Permission adjacency is the named concept teams should start using internally. It describes the risk created when individually plausible cloud permissions become dangerous in combination. That matters because the review unit is no longer the single permission, but the effect of holding adjacent control-plane rights in one execution path.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per The 2026 Infrastructure Identity Survey, the cloud identity problem is already broader than traditional workload roles. Security teams should watch for the same privilege pattern emerging in AI platform and automation accounts, where operational scope can outrun governance.

For practitioners

• Map permission combinations, not just individual permissions. Build reviews that identify identities holding create, update, and delete rights over the same service or cluster, because the dangerous state is often the combination. Prioritise ECS, network, and AI workspace permissions where one principal can change execution and then remove evidence.
• Separate deployment, modification, and teardown authority. Ensure no single NHI or service role can register workloads, alter them in place, and delete the supporting daemon or workspace. Enforce segregation of duties for cloud control-plane actions that can deploy arbitrary code or permanently remove operational state.
• Classify destructive actions by effect, not by label. Treat actions such as archive, reset, reconfigure, or recreate as potentially destructive until you confirm whether they can remove sessions, vaults, agents, or logs. That is especially important in AI platforms and orchestration layers where labels can understate blast radius.
• Review redirection permissions as quietly privileged. Prioritise permissions that can change network attachments, configuration names, or execution targets without touching the original workload definition. These are often the easiest way to move legitimate automation into attacker-controlled infrastructure while avoiding obvious change events.

Key takeaways

• Sonrai’s recap shows that cloud privilege abuse now centers on infrastructure control, not just data access.
• The riskiest permissions are the ones that can be chained to deploy, redirect, and remove workloads or evidence at scale.
• Practitioners should classify cloud permissions by blast radius and sequence, then separate the rights that create, modify, and destroy runtime state.

Key terms

• Infrastructure Hijacking: A cloud abuse pattern where an identity can redirect, replace, or destroy the systems that run workloads rather than merely reading data. The risk is control-plane takeover, where permissions let an attacker alter execution paths, network boundaries, or observability layers at runtime.
• Permission Adjacency: The dangerous condition where several individually reasonable permissions become high risk when held by the same identity. In cloud governance, adjacency matters because create, update, and delete actions can combine into full lifecycle control over workloads, clusters, or AI workspaces.
• Blast Radius: The practical extent of damage an identity can cause if misused or compromised. For cloud and NHI governance, blast radius includes how far a principal can move, what runtime state it can alter, and whether it can destroy logs, agents, or sessions that would expose the abuse.
• Control-Plane Privilege: Access that changes how infrastructure behaves rather than what data it merely exposes. This kind of privilege is especially sensitive because it can move workloads, redefine execution targets, or remove the tools security teams use to detect abuse.

Deepen your knowledge

Cloud privilege adjacency and infrastructure hijacking are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for cloud workloads, AI platforms, or service identities, it is worth exploring.

This post draws on content published by Sonrai Security: May recap on new AWS privileged permissions and infrastructure hijacking. Read the original.