TL;DR: May’s new AWS permissions create a consistent infrastructure hijacking pattern, where permissions can redirect workloads, extend attacker-controlled networks, or destroy operational resources across ECS, Omics, and external AI services, according to Sonrai Security. The security model is shifting from individual permission review to controlling permission combinations that can seize fleet-wide execution.
At a glance
What this is: Sonrai Security maps a set of new AWS permissions to an infrastructure hijacking pattern that can redirect workloads, extend network reach, and destroy resources across multiple services.
Why it matters: IAM and cloud security teams need to assess permission combinations, not just individual actions, because a single identity can now gain fleet-level control across orchestration, networking, and AI workspace resources.
Context
AWS added or exposed a cluster of privileged permissions in May across compute, networking, genomics pipelines, container orchestration, and an external AI platform. The article argues that the shared problem is not the service category but the way these permissions can be combined to take over infrastructure.
In identity terms, this is an IAM and cloud privilege design problem rather than a service-specific configuration issue. The practical question is how to stop identities from accumulating combinations that can redirect traffic, run arbitrary workloads, or permanently remove operational resources.
Key questions
Q: What breaks when cloud permissions can be chained into full infrastructure control?
A: The usual assumption that each permission is low risk on its own breaks down. When one identity can register, create, update, and delete in the same control plane, it can deploy arbitrary workloads, redirect trusted execution, and erase evidence. That is a privilege combination problem, not a single-permission problem.
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 teams know whether cloud privilege controls are working?
A: Look for whether privileged changes are reviewable, short-lived, and distinguishable from normal operations. If certificate additions, permission grants, and token-related changes blend into routine logs, then the control set is not detecting the events that matter most.
Q: What should IAM teams do when a cloud permission can destroy operational resources?
A: Treat it as a privileged destructive action, not an administrative convenience. Workspace archive, fleet deletion, and similar controls should be isolated from day-to-day roles, reviewed as high-impact access, and mapped to business loss scenarios. If a permission can remove agents, vaults, or sessions, it needs PAM-level scrutiny.
Technical breakdown
Permission combinations create infrastructure hijack paths
The article’s core technical point is that individual permissions can look ordinary in isolation while becoming dangerous in combination. In ECS, register, create, update, and delete together define a full control loop over cluster-wide workload execution. In cloud IAM, the real risk is not just action scope but how multiple allowed actions compose into a takeover path that spans deployment, redirection, and cleanup. That changes review from single-permission approval to combination-aware privilege analysis.
Practical implication: review cloud entitlements as executable chains, not isolated grants.
Secondary networks and redirected configurations expand blast radius
A secondary network permission can let traffic move outside established monitoring boundaries, while a new configuration name in Omics can redirect automated runs into an attacker-controlled VPC without modifying the original job definition. These are infrastructure hijack patterns because they preserve the surface of legitimate operation while changing the underlying path or destination. The failure mode is not obvious misuse of a single API, but silent redirection of trusted execution paths.
Practical implication: control who can alter network attachment and run-target configuration, not just who can start workloads.
External AI workspace permissions can become destructive controls
The external AI platform permission described in the article is framed as archive, but Sonrai Security notes that it effectively destroys workspace-scoped resources such as agents, credential vaults, skills, and sessions. That matters because identity governance often treats AI workspace lifecycle actions as administrative hygiene rather than high-impact destructive operations. In practice, the permission model must reflect the operational impact of the action, not the label attached to it.
Practical implication: classify workspace archive and deletion-equivalent actions as high-risk privileged access.
Threat narrative
Attacker objective: The attacker wants fleet-level infrastructure control, hidden workload execution, and destructive cleanup that outlasts detection.
- Entry occurs when an identity holds a privileged AWS permission set that appears service-specific but is actually composable into broader control of compute, networking, or workspace resources.
- Escalation follows when the attacker combines create, register, and update permissions to run arbitrary workloads, redirect traffic, or replace trusted configurations with attacker-controlled ones.
- Impact occurs when the attacker uses delete or archive-equivalent permissions to erase monitoring components, destroy workspace-scoped assets, or permanently remove operational resources.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
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
Infrastructure hijack is the right concept for this AWS permission pattern: the danger is not isolated privilege creep, but the ability of one identity to redirect, replace, and erase infrastructure control paths. Sonrai Security’s examples show that cloud privilege review has to move from action-by-action approval to composition-aware governance. The practitioner conclusion is simple: if permissions can be chained into execution control, they are already beyond routine admin scope.
Combining privileged actions is now the decisive cloud governance problem: ECS register, create, update, and delete permissions become materially different when held together. That combination gives one identity a full lifecycle over cluster execution, which is a stronger control issue than any single permission suggests. IAM programmes should treat these chains as a distinct class of fleet-control risk.
Infrastructure hijack surface: this is the named concept this article surfaces. It describes the point where benign-looking cloud permissions can be composed into network redirection, workload substitution, or resource destruction. The implication for governance teams is that least privilege must be evaluated at the level of action combinations, not just entitlement counts.
Action labels can obscure privilege severity: archive, configuration, and create can all carry destructive or takeover semantics in cloud control planes. The article shows that the label on a permission is less important than what that permission can do in the presence of other privileges. The practitioner conclusion is to classify by effective control impact, not by naming convention.
Cloud privilege reviews need to account for service-class drift: this pattern spans compute, data pipelines, container orchestration, and external AI platforms, which means privilege governance cannot remain siloed by service team. Sonrai Security’s mapping shows the same control logic appearing in different operational layers. The result is a governance problem that is enterprise-wide, not product-specific.
From our research library:
- 49% of IT professionals would prioritise improving privileged access management if the decision were theirs alone, according to Netwrix's 2023 Hybrid Security Trends Report.
- Read next: AI Agent Authorisation Guide
What this signals
Infrastructure hijack surface: cloud programmes need a control model that evaluates what an identity can compose, not just what it can call. The article’s pattern shows that redirection, workload injection, and destructive cleanup can all emerge from standard privileged actions when they coexist in one role.
The practical shift for IAM and cloud teams is to review privilege by effective outcome. If an identity can alter routing, redefine execution, and delete traces, then least privilege has already failed at the governance layer, even if each permission looked acceptable in isolation.
For practitioners
- Review privilege combinations, not single permissions Identify identities that hold create, register, update, and delete actions across the same operational domain, then evaluate whether those grants create a full control chain.
- Treat configuration redirection as privileged access Map permissions that can change network attachments or run-target definitions, because those actions can move workloads outside monitored boundaries without changing the workload itself.
- Reclassify archive-equivalent workspace actions Place workspace archive, session destruction, and vault removal actions into the same review path as destructive privileged access, not routine administration.
- Hunt for cluster-wide workload control paths Look for identities that can deploy arbitrary containers across a fleet, especially where task-definition registration and daemon management coexist in the same role.
Key takeaways
- New AWS permissions can be chained into cluster-wide workload control, traffic redirection, or resource destruction, so single-permission review is no longer enough.
- The article’s risk pattern is consistent across ECS, Omics, and an external AI workspace because the underlying issue is permission composition, not service type.
- IAM teams should classify destructive or redirection-capable cloud actions as privileged access and review them for combination risk, not just individual scope.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centers on identities that can accumulate excessive cloud permissions into takeover paths. |
| NHI-06 — Insecure Cloud Deployment Configurations | Redirected runs and secondary networks are cloud deployment control failures, not isolated app bugs. | |
| Recommendation — Review cloud roles for overprivileged combinations and remove actions that together create fleet control. Lock down configuration and network-change permissions that can redirect trusted cloud execution. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article’s central point is that least privilege must account for privilege combinations, not just single entitlements. |
| Recommendation — Apply least-privilege review to combined AWS actions that can create, modify, and delete the same resource path. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | This article is about authorisations that expand into infrastructure control across services. |
| Recommendation — Validate that entitlements cannot be combined into privileged control of workloads, routing, or destructive actions. | ||
| MITRE ATT&CK | TA0004;TA0008;TA0040 — Privilege Escalation; Lateral Movement; Impact | The permissions enable escalation, broader movement across infrastructure, and destructive outcomes. |
| Recommendation — Map risky cloud permission chains to privilege escalation, lateral movement, and impact tactics in your detections. | ||
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 Combination Risk: The security risk created when separate permissions are benign in isolation but dangerous when held together by one identity. For cloud and NHI programmes, the unit of review is the operational chain the role can assemble, not the individual entitlement list.
- Cloud Privilege: Cloud privilege is the set of actions an identity can perform through permissions in a cloud environment. It is defined by role assignments, policies, and inherited entitlements rather than by a single administrator account, which makes governance dependent on continuous review of effective access.
- Destructive Workspace Action: A control that appears administrative but can permanently remove agents, sessions, vaults, or other operational resources. In identity governance, these actions should be treated as high-risk privileged operations because the practical effect can match deletion even when the label sounds routine.
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.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org