GCP privileged permissions are widening cloud identity risk

At a glance

What this is: This analysis tracks newly privileged and newly denyable GCP permissions and shows how they expand attack paths across identity, authentication, and backup controls.

Why it matters: It matters because IAM, PAM, and cloud security teams need to detect when platform changes quietly expand privilege scope before those changes become escalation or persistence opportunities.

By the numbers:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Sonrai Security's analysis of newly privileged GCP permissions and cloud risk

Context

Google Cloud Platform keeps adding permissions that can change identity policy, authentication posture, and backup protection in a single action. For cloud security and IAM teams, the problem is not just whether a permission exists, but whether it can now be explicitly denied, audited, and governed before it becomes a privilege escalation path.

Sonrai Security’s analysis is useful because it treats permissions as a moving control surface rather than a fixed inventory. That matters for least privilege, PAM, and cloud governance programmes, where a new API action can quietly redefine what an identity is able to do across projects and services.

Key questions

Q: How should security teams handle newly privileged cloud permissions in access reviews?

A: They should treat any permission that can change IAM policy, authentication records, certificates, or backup protections as a privileged control, not a routine operational right. Review those permissions separately from standard application access, require explicit approval for grants, and re-evaluate them whenever the provider adds new API actions or deny capabilities.

Q: Why do cloud permissions that affect identity policy create more risk than ordinary execution rights?

A: Because they can change who is trusted and what access paths exist, not just what work a service can perform. Once a role can remap identities or rewrite authentication settings, it can expand access, preserve trust, or make later compromise much harder to detect and contain.

Q: What breaks when backup configuration permissions are over-granted?

A: Recovery breaks first. If an identity can alter backup vaults, delete backup associations, or change retention and encryption settings, an attacker can remove the ability to restore systems after compromise. That turns a containable incident into a resilience failure and raises the cost of every security event.

Q: Which governance framework is most relevant to cloud permission drift?

A: Zero Trust and least-privilege governance are the right starting points, because both assume access should be narrowly scoped and continuously verified. In cloud environments, those controls must extend to control-plane permissions, backup rights, and authentication changes, not just user-facing application access.

Technical breakdown

Newly privileged permissions and why they matter

A permission becomes privileged when it can materially alter control over identities, data, or security posture rather than merely read state. In this case, actions such as setting IAM policy, updating authentication configurations, or sharing integration templates can turn an otherwise ordinary platform account into a route for escalation or persistence. The technical issue is that cloud platforms increasingly expose fine-grained administrative capabilities through service APIs, and those capabilities may not be visible in older entitlement models. Practical mapping between permission sets and threat tactics is now part of cloud governance, not an optional extra.

Practical implication: continuously classify new cloud permissions by control impact, not by service name alone.

Deny policies as a governance control

The introduction of V2 deny support changes the governance conversation from discovery to enforceability. If an organisation can explicitly deny newly exposed high-risk permissions, it can prevent identities from using capabilities that were previously only visible in documentation or logs. That only works if security teams maintain current permission-to-control mappings, because deny is effective only when the risky action is identified fast enough to block. In practice, deny policy becomes a compensating control for the speed at which cloud platforms expand privilege surfaces.

Practical implication: maintain a deny-listing process for newly surfaced administrative permissions before they are broadly granted.

Identity remapping and backup control are high-risk primitives

Identity remapping, auth config changes, certificate updates, and backup vault modifications are not ordinary operational tasks. They can redirect access, preserve malicious trust, or destroy recovery paths. These capabilities create compound risk because they sit at the intersection of identity governance, operational continuity, and incident recovery. When a permission can both affect authentication and undermine recovery, the control failure is no longer just privilege creep. It is a loss of resilience across the full identity and recovery stack.

Practical implication: treat identity remapping and backup configuration permissions as tier-1 privileged actions in cloud reviews.

Threat narrative

Attacker objective: The attacker aims to turn cloud control-plane permissions into durable access, weakened recovery, and greater reach across connected services.

1. Entry occurs when a cloud identity gains access to newly exposed or newly controllable administrative permissions through a legitimate entitlement or over-broad role.
2. Escalation follows when that identity modifies IAM policy, authentication records, certificates, or integration templates to extend access or preserve trust.
3. Impact occurs when the attacker uses those permissions to maintain persistence, disrupt backup recovery, or enable data loss and unauthorized system changes.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• 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

Cloud privilege drift is now a governance problem, not a service-management detail. When a platform adds new administrative actions faster than teams update entitlement models, least privilege becomes stale by default. The security issue is not that GCP is unusual, but that cloud control planes now evolve faster than many access review cycles can absorb. Practitioners need to treat permission expansion as an active governance event, not a periodic audit finding.

Identity policy manipulation should be classified as a privileged outcome, not just a permission type. Permissions that alter IAM policy, remap external identities, or rewrite authentication settings change the meaning of access itself. That is more dangerous than routine execution rights because it can alter who is trusted, what is authenticated, and which paths remain visible to defenders. IAM and PAM teams should evaluate these actions as control-plane authorities with direct blast-radius implications.

Backup and recovery permissions belong in the same risk tier as identity administration. If an attacker can modify backup vaults, delete backup associations, or alter protection settings, they can convert a compromise into lasting damage. This is a classic resilience failure: recovery becomes dependent on the same platform controls that the attacker has already reached. Security programmes should stop separating identity governance from restore integrity when the same role can affect both.

Privilege escalation in cloud environments increasingly depends on control adjacency. The new risk is not one dramatic exploit chain, but a sequence of adjacent permissions that connect identity, integration, and recovery. That pattern makes traditional service-by-service review insufficient. The practitioner conclusion is straightforward: review permission clusters by attack consequence, not by product taxonomy.

Newly deniable permissions change the operating model for cloud governance. Deny support gives teams a chance to close exposure faster, but only if they have a process for identifying newly risky permissions as the platform changes. The field is moving toward dynamic privilege governance, where the timing of detection matters as much as the content of the policy. Security teams should expect this to become a standard control expectation across cloud programmes.

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.
• Static credential dependence is not just a hygiene issue. In the same survey, 69% of security leaders said identity management must fundamentally shift to address agentic AI systems.
• For a broader governance lens, see Ultimate Guide to NHIs for how access scope, rotation, and offboarding should be structured across machine identities.

What this signals

Cloud teams should expect permission discovery to become a continuous control requirement rather than a quarterly review activity. As providers expand administrative APIs, the practical boundary of least privilege moves underneath existing roles, which means entitlement hygiene must now track platform change velocity, not just organisational change.

Identity blast radius: permissions that can rewrite identity policy, certificates, or backup posture should be governed together because they collapse separate risk domains into one control plane. That concept matters for IAM, PAM, and cloud security teams that still review access by service instead of by outcome.

With 69% of security leaders already saying identity management must fundamentally shift to address agentic AI systems, the cloud permission problem is part of a wider programme reset, not a one-off GCP issue.

For practitioners

• Classify new permissions by control impact Review each newly surfaced cloud permission for whether it can alter IAM policy, authentication state, certificates, or backup protection. Put those actions into a privileged category that requires explicit approval and tighter monitoring.
• Extend deny policies to high-risk administrative actions Use deny rules to block newly controllable privileges that can enable escalation, persistence, or recovery disruption. Refresh those rules whenever the cloud provider expands an API or adds a new privileged action.
• Review identity remapping as a privileged governance event Treat identity mapping imports and similar control-plane changes as access model changes, not routine data updates. Require separate review for any permission that can reassign external identities or alter how access is resolved.
• Pull backup controls into privileged access review Include backup vault updates, backup association changes, and recovery configuration permissions in PAM and access recertification cycles. These rights can determine whether a compromise is recoverable or irreversible.

Key takeaways

• GCP permission drift creates real privilege risk when identity, authentication, and backup controls are exposed through the same API surface.
• The issue is measurable in control impact, not service count. Permissions that can remap identities or alter recovery settings materially increase blast radius.
• Security teams should expand privilege governance to include newly surfaced control-plane actions, deny policies, and recovery-adjacent permissions.

Key terms

• Control-plane permission: A control-plane permission is an action that changes how a cloud platform governs access, identity, or resilience rather than just reading data. These permissions matter because they can alter policy, authentication, or recovery behavior, creating outsized security impact if granted too broadly.
• Privilege escalation: Privilege escalation is the movement from ordinary access to higher authority that enables broader control over systems or data. In cloud environments, it often happens through administrative APIs, policy edits, or identity changes that let one account behave like a more trusted one.
• Backup protection: Backup protection is the set of controls that keeps backup data, retention, and restore paths intact during an incident. When attackers can modify these settings, they can prevent recovery, destroy evidence, or weaken resilience even if production systems are restored later.

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

This post draws on content published by Sonrai Security: Oct Recap: New and Newly Deniable GCP Privileged Permissions. Read the original.