Topic starter
25/06/2026 12:24 am
TL;DR: Newly introduced and newly deniable privileged actions in Google Cloud Platform now span identity remapping, authentication changes, and backup controls, creating fresh paths to escalation, persistence, and data loss, according to Sonrai Security. The governance problem is not volume alone, but the way small permission shifts can outpace static entitlement reviews.
Editorial analysis by NHI Mgmt Group, based on content published by Sonrai Security: “Oct Recap: New and Newly Deniable GCP Privileged Permissions”.
Key questions
Q: What breaks when cloud permissions can change IAM policy or identity mappings?
A: The assumption that access is stable enough to review breaks first.
Q: Why do backup and authentication permissions increase cloud identity risk?
A: Because they protect the mechanisms that preserve or restore trust.
Q: What are the signs that privileged cloud permissions are expanding too fast?
A: Watch for new API actions that alter identity, access or recovery state, especially when they appear in services that are not traditionally treated as IAM tools.
Practitioner guidance
- Map cloud permissions that can rewrite trust Build a separate watchlist for permissions that can set IAM policy, import identity mappings, update certificates or alter backup settings.
- Classify identity-mapping actions as privileged Treat permissions that import or transform identity mappings as privileged even when they sit inside business services such as discovery or analytics.
- Extend PAM governance to backup controls Include backup vault updates, backup-plan association changes and authentication configuration changes in PAM reviews.
Bottom line: Cloud permission changes can create identity risk even when account counts stay flat, because the dangerous change is often in what a principal can do rather than who that principal is.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 9:19 am
Cloud privilege expansion is now an identity governance problem, not just a cloud administration issue. When a platform adds permissions that can rewrite IAM policy, remap identities or change authentication controls, it expands the set of actions that must be governed as privileged. That shifts the control conversation from role hygiene to permission lifecycle management. Practitioners should treat permission growth as a standing identity risk register.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should IAM teams respond when cloud services add denyable privileged actions?
A: Re-baseline the privilege catalog against the new permission set and update approval thresholds for any action that changes trust, persistence or recovery. Denyability is useful, but only if the organisation actually identifies those actions as high-risk and routes them through governance.
👉 Read our full editorial: GCP privileged permissions are widening cloud identity risk