AWS permission sprawl is widening the cloud blast radius

At a glance

What this is: This is Sonrai Security’s review of newly released AWS privileged permissions and the key finding is that cloud privilege is spreading into more service-level actions with outsized blast radius.

Why it matters: It matters because IAM, PAM, and cloud security teams need to treat service actions as governed privilege, not just admin roles, across NHI, autonomous, and human-operated workflows.

👉 Read Sonrai Security's recap of newly released AWS privileged permissions

Context

Cloud privilege now extends well beyond classic administrator roles. In AWS, service-level permissions can alter logs, redirect traffic, change model behaviour, or expand execution rights, which means the security question is no longer only who can log in, but what each identity can do once it is inside the control plane.

For IAM and cloud governance teams, this is a Non-Human Identity problem as much as a platform security problem. The article’s core point is that privilege creep now appears in obscure service actions, so least privilege, monitoring, and recertification have to track service identities and workload permissions as closely as human access.

Key questions

Q: How should security teams govern new cloud service permissions?

A: Security teams should treat new cloud service permissions as privileged access from day one. Review what each action can change, not just what service it belongs to, then assign approval, logging, and recertification based on blast radius. If a permission can alter trust, telemetry, or execution, it needs PAM-grade governance.

Q: Why do service-level permissions increase cloud risk?

A: Service-level permissions increase risk because they can change behaviour inside the control plane without using a traditional administrator path. That means a seemingly small entitlement can redirect logs, loosen trust, or expand execution scope, creating disproportionate impact from ordinary operational access.

Q: What breaks when observability permissions are over-granted?

A: When observability permissions are over-granted, attackers or insiders can disable logging, delete telemetry pipelines, or reroute data before defenders notice. The result is weaker evidence, slower detection, and reduced confidence in the audit trail. In cloud governance, visibility controls are part of the security boundary, not just monitoring.

Q: How do cloud teams decide which permissions need tighter review?

A: Cloud teams should tighten review around permissions that can modify trust stores, model deployments, network paths, log exports, or execution roles. Those are the actions that expand blast radius. If a permission can change the behaviour of a shared service, it belongs in the highest review tier.

Technical breakdown

How new AWS service permissions expand blast radius

AWS keeps adding service actions that look operational but behave like privilege. A permission such as updating a scheduled query, a trust store, or a model deployment can redirect data flow, weaken trust, or change execution outcomes without touching a traditional admin path. That is why these permissions are high risk: they sit in the control plane, yet their effects are often downstream in logs, traffic, or inference. The security problem is not just access to a service, but the ability to change how the service behaves on behalf of the organisation.

Practical implication: inventory service-level permissions as privileged access and review them alongside admin entitlements.

Why AI and agent-based permissions need separate governance

The article shows AWS introducing permissions for Bedrock, Connect, and agent-style services that can associate security profiles, update deployments, or influence workflow execution. These are not generic application permissions. They govern how AI-enabled services act, which means they carry identity and delegation risk even when no human is directly holding the session. In practice, this blurs the line between infrastructure administration and runtime authority, so the governance model has to understand the identity behind the action and the blast radius of the service it controls.

Practical implication: classify AI-adjacent cloud permissions separately and bind them to explicit approval, logging, and review controls.

How exfiltration and defence evasion hide inside ordinary cloud operations

Several of the new permissions described in the article can export logs, disable deletion protection, or delete telemetry pipelines. Those actions are easy to miss because they read like routine platform management, but they can be used to conceal activity or move data out of view. In cloud environments, visibility controls are part of the trust model. Once an identity can reroute or remove observability, the organisation loses both evidence and detection depth. That makes observability permissions a core security boundary, not an afterthought.

Practical implication: protect observability permissions with the same scrutiny you apply to data access and key management.

Threat narrative

Attacker objective: The objective is to gain high-leverage control over cloud services so access, execution, and visibility can be expanded or concealed without traditional admin compromise.

1. Entry occurs through newly granted or overlooked service permissions that appear operational but can modify trust, logging, or execution pathways.
2. Escalation happens when those permissions are used to widen access, redirect outputs, or alter service behaviour beyond the original scope of the identity.
3. Impact follows when logs are exfiltrated, protections are disabled, or workloads are executed with expanded authority, reducing visibility and increasing blast radius.

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

Service-level privilege is now the real cloud governance boundary. The article shows AWS permissions that do not look administrative on paper but still change logging, execution, trust, and network paths. That is the current failure mode for cloud programmes: privilege is being expressed through services, not just roles. Practitioners should stop treating service actions as low-risk by default and govern them as blast-radius controls.

Identity blast radius: the meaningful unit of cloud risk is no longer the account, but the service action. When a permission can redirect logs, alter deployments, or loosen trust stores, the security question becomes how far one identity can move the system. That framing aligns with OWASP-NHI and NIST CSF thinking because the control objective is containment, not just authentication. The practitioner conclusion is to measure privilege by effect, not by label.

Cloud observability is part of identity governance, not a separate monitoring problem. The article’s log and telemetry permissions show that hiding evidence can be accomplished through authorised service actions. That means review cycles must include the permissions that shape auditability itself. The implication is clear: if visibility can be modified by the same identities being monitored, governance has to include observability controls in the entitlement model.

Agent-linked cloud permissions are a warning that autonomy is entering infrastructure privilege. Even where the article is still describing AWS service permissions rather than fully autonomous agents, the governance pattern is converging toward delegated execution with broad operational reach. That is why AI-adjacent permissions deserve separate scrutiny under NIST AI RMF and OWASP Agentic AI Top 10 concepts. Practitioners should prepare for a control model where execution authority, not just access, is the core risk.

Continuous privilege review has to move faster than cloud service innovation. The article demonstrates that AWS can introduce multiple new privileged actions in a single monthly cycle across identity, observability, AI, and orchestration. Static review cadences will always lag this pace. The practical conclusion is to build entitlement monitoring that treats new service permissions as security events, not just release notes.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• For a broader governance lens, see Ultimate Guide to NHIs for lifecycle controls that can be applied across service accounts, workload identities, and emerging AI agents.

What this signals

Identity blast radius is becoming the practical unit of cloud governance. As cloud vendors add more service-level permissions, teams need to measure what each entitlement can change in the system, not just whether it is attached to an account. The practical shift is toward effect-based review, where logging, trust, and execution are governed as one entitlement surface.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the control gap is already visible in adjacent identity programmes. Cloud teams should expect the same mistake to repeat in service permissions unless entitlement review becomes continuous and service-aware, using the OWASP NHI Top 10 as a design reference.

The next programme risk is not just privilege sprawl, but review lag. When new service permissions appear monthly, static access recertification cannot keep up, so practitioners need a model that flags newly introduced actions as governance events. That approach aligns with NIST AI Risk Management Framework thinking where delegated action and oversight must be explicit.

For practitioners

• Classify service actions as privileged access Review newly introduced cloud permissions for their effect on logs, trust, execution, and network paths, then place them into the same governance queue as admin entitlements.
• Separate observability from routine operations Treat permissions that create, update, delete, or reroute telemetry as high-risk controls because they can remove evidence while the system remains technically functional.
• Review AI-adjacent permissions independently Isolate permissions tied to Bedrock, agent services, and workflow execution so they require explicit approval, tighter logging, and separate access recertification.
• Map cloud privilege to blast radius Rank each permission by the systems and data it can influence, then prioritise review for actions that can alter trust stores, model deployments, or cross-account outputs.
• Monitor for new privileged permissions monthly Build a repeatable review process for vendor release notes so new service permissions are assessed before they become standing access in production.

Key takeaways

• Cloud privilege is spreading into service actions that can alter logging, trust, execution, and network paths without using classic administrator roles.
• The evidence points to a wider blast radius, especially where observability and AI-adjacent permissions can hide activity or change behaviour at runtime.
• Practitioners should govern new service permissions as privileged access, with separate review for observability, AI, and trust-changing actions.

Key terms

• Service-level privilege: Access that changes how a cloud service behaves rather than simply allowing a user to view or edit a record. In identity governance, service-level privilege often carries outsized blast radius because one action can affect logging, trust, execution, or data movement across many workloads.
• Blast radius: The amount of damage or exposure an identity can create if its access is misused. In cloud and NHI governance, blast radius is measured by what an entitlement can change, not by the title of the role or whether the access looks routine on paper.
• Observability permission: A permission that can create, modify, delete, or reroute telemetry, logs, or monitoring pipelines. These permissions matter because they affect whether defenders can see, prove, or investigate activity, making them part of the security boundary rather than a separate operations function.
• Agent-adjacent permission: A cloud entitlement tied to AI-enabled, workflow, or autonomous service behaviour. These permissions deserve separate review because they often govern delegated execution, data access, and side effects that are harder to reason about than conventional application permissions.

Deepen your knowledge

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

This post draws on content published by Sonrai Security: Dec Recap on new AWS privileged permissions and services. Read the original.