AWS privilege changes expose gaps in cloud identity governance

At a glance

What this is: This review tracks newly added AWS permissions that expand control over monitoring and identity tokens, showing how small privilege changes can weaken visibility and widen misuse paths.

Why it matters: It matters because IAM, PAM, NHI, and cloud security teams need to treat privilege changes as attack-surface changes, not just feature releases.

By the numbers:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.

👉 Read Sonrai Security's review of new AWS privileged permissions and services

Context

Cloud permission drift is a governance problem before it is a detection problem. When a platform introduces new actions that can disable logging, alter anomaly detection, or issue identity tokens, existing least-privilege models may no longer describe the real blast radius of the environment.

For NHI and cloud identity teams, this is a reminder that permissions are not neutral metadata. They define what workloads, automation, and service identities can do at runtime, which means new privileges must be evaluated as potential control-plane exposure as soon as they appear.

Key questions

Q: What breaks when cloud permissions can disable logging or anomaly detection?

A: Visibility breaks first, then attribution and containment. If a principal can delete anomaly detectors or reroute scraper logs, the security team may lose the evidence needed to confirm malicious behaviour, reconstruct the sequence, or prove scope. That is why monitoring permissions must be treated as privileged access and reviewed with the same discipline as administrative roles.

Q: Why do short-lived identity tokens still create NHI risk?

A: Short-lived tokens still create NHI risk because they can authenticate a machine identity to downstream services and expand trust beyond the original cloud boundary. Expiration reduces exposure time, but it does not remove the authorization path, the minting right, or the possibility of misuse inside the valid window.

Q: How do security teams know when cloud privilege has become excessive?

A: Excessive cloud privilege shows up when a role can alter control systems, not just access resources. If a principal can suppress logs, weaken detections, or issue tokens for external authentication, it has crossed from operational access into governance-sensitive access. The signal is downstream trust impact, not the size of the permission list.

Q: Who should own review of monitoring and token-issuing privileges?

A: Ownership should sit with the identity and cloud governance functions together, because the permissions affect both access design and visibility design. Security operations can flag the risk, but IAM, PAM, and cloud platform owners must jointly approve the entitlement, define its purpose, and recertify it on a regular basis.

Technical breakdown

How monitoring permissions become defense evasion paths

Observability services are privileged because they protect the control loops that operators depend on. Permissions such as deleting anomaly detectors or changing scraper logging configurations do not directly steal data, but they can reduce or reroute the telemetry that would expose suspicious behaviour. That makes the monitoring plane a target in its own right. In cloud environments, defense evasion often starts with permission changes that look administrative but function as concealment. Once logging is weakened, other malicious actions become harder to prove, triage, or contain.

Practical implication: map every monitoring permission to the telemetry control it can suppress and review it as a high-risk entitlement.

Why short-lived identity tokens still matter for NHI governance

A short-lived token is not low risk simply because it expires quickly. If it can be used to authenticate a workload or external service, it can still extend machine identity beyond the original trust boundary. The key issue is not token lifespan alone but the authorization context attached to it, including who can mint it, where it is accepted, and what downstream systems trust it. In NHI programmes, token issuance rights often become the bridge between cloud-native workloads and external systems, which expands the misuse surface if governance is weak.

Practical implication: treat token-minting permissions as identity issuance controls and scope them with the same care as privileged service accounts.

Cloud privilege expansion is really blast-radius expansion

Each new permission changes the shape of the blast radius even when the underlying service appears unchanged. If a control can disable detection or broaden identity reach, it can also reduce the time available to respond and increase the number of systems that inherit trust from the same principal. That is why permission review must focus on downstream effect, not just action names. A seemingly narrow addition can become a wide governance gap when it touches logging, anomaly detection, or identity federation.

Practical implication: classify new cloud permissions by the control they can undermine, then recertify the affected principals and workflows.

Threat narrative

Attacker objective: The attacker aims to hide malicious activity while expanding the reach of a compromised cloud or machine identity.

1. Entry occurs through newly granted cloud permissions that let a principal interact with monitoring or identity services beyond its intended role.
2. Escalation happens when the principal uses those permissions to weaken logging, alter anomaly detection, or obtain identity tokens for external authentication.
3. Impact follows when visibility drops and machine identity misuse becomes harder to detect, contain, or attribute across cloud and downstream systems.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

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

NHI Mgmt Group analysis

Cloud privilege changes are governance events, not admin updates. When a cloud provider adds permissions that can suppress telemetry or issue identity tokens, it changes the control assumptions behind least privilege and monitoring. The security boundary is no longer just the workload or role, but the set of actions that can reshape visibility and trust. Practitioners should treat every new privileged permission as a blast-radius change, not a routine product note.

Monitoring-plane privilege is a hidden identity risk. Permissions that delete anomaly detectors or redirect scraper logs sit inside the identity layer even when they look like observability controls. That matters because attackers do not need to break the tool if they can turn off the signals it produces. This is a classic governance blind spot for cloud and NHI programmes. The practitioner conclusion is simple: telemetry controls deserve entitlement review, ownership, and recertification.

Identity token issuance is a machine-identity policy decision. A permission that returns a web identity token does more than authenticate a session. It determines whether a machine identity can cross trust boundaries and authenticate to systems outside the original cloud context. That makes token minting part of NHI governance, not a side feature of an IAM service. Teams that ignore issuance paths leave a gap between identity design and actual runtime trust.

Permission sprawl is compounding trust debt across cloud systems. Each new high-risk action creates another point where the security model can be bypassed through legitimate access. Over time, the environment accumulates trust debt: rights that were once narrow become broad enough to alter logging, analytics, and identity exchange. The practitioner implication is to align entitlement review with the downstream trust effect of permissions, not just their service category.

From our research:

• From our research: 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• The same survey reports that 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• For a broader risk lens, review Ultimate Guide to NHIs for how entitlement scope, lifecycle, and trust boundaries should be handled.

What this signals

Monitoring-plane privilege is becoming part of the identity architecture. The practical lesson for cloud and IAM teams is that observability controls now need entitlement governance, ownership, and recertification. When permissions can suppress anomaly detection or redirect logs, security operations inherits an identity problem, not just a telemetry problem.

The governance burden will rise further as machine identities gain broader trust relationships across cloud and external services. Teams that only review access to data and compute will miss the permissions that can reshape detection, evidence, and response. That is why the blast radius of a role must be evaluated by what it can silence as much as what it can reach.

For practitioners

• Inventory new cloud permissions by control impact Classify each newly introduced action by whether it can suppress logging, alter detection logic, mint identity tokens, or expand downstream trust. Review the affected principals before they reach production and map the business owner for each high-risk entitlement.
• Re-certify monitoring and identity permissions together Do not separate observability entitlements from identity entitlements in reviews. A role that can change anomaly detection or log forwarding should be assessed alongside roles that can mint or exchange tokens, because both change how compromise is seen and contained.
• Limit token-minting rights to narrowly defined workloads Restrict permissions that issue web identity tokens to specific workloads, accounts, and federation targets. Where possible, require explicit approval for new trust relationships and remove broad inheritance paths that allow tokens to be reused beyond the original workload purpose.
• Test what happens when logging is removed Run tabletop and detection-engineering exercises that assume anomaly detectors are deleted or scraper logs are redirected. Validate whether your incident response process still has enough evidence to investigate privilege misuse when the telemetry layer is degraded.

Key takeaways

• New AWS permissions can weaken both visibility and identity trust, which makes them a governance issue as much as a technical one.
• A principal that can delete anomaly detectors or issue identity tokens has access that can change the response model, not just the workload state.
• Cloud and NHI teams should recertify high-risk permissions by their downstream effect on logging, federation, and blast radius.

Key terms

• Monitoring-plane privilege: Access that can change how security telemetry is produced, forwarded, or interpreted. In cloud environments, this includes rights to alter logging pipelines, anomaly detectors, and alerting rules. It is privileged because it can hide activity even when the underlying workload remains unchanged.
• Identity token issuance: The act of creating a token that proves a workload's identity to another system. For NHI governance, issuance rights matter as much as token lifespan because they determine who can create trust and where that trust can be used outside the originating platform.
• Blast radius: The amount of damage or reach a compromised identity can create before it is stopped. In cloud and NHI governance, blast radius is shaped by permissions, federation paths, and visibility controls, not only by the number of resources a role can touch.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Sonrai Security: Nov Recap: New AWS Privileged Permissions and Services. Read the original.