GCP IAM v1 and v2 permissions create hidden deny-policy gaps

At a glance

What this is: This analysis explains how Google Cloud IAM v1 and v2 permission formats diverge across allow policies, deny policies, and logs, creating blind spots in enforcement and troubleshooting.

Why it matters: IAM, cloud security, and platform teams need to understand the version split because a permission can be grantable, denyable, and logged under different names, which complicates least-privilege governance.

By the numbers:

• Currently, there are ~12k total permissions in GCP that can be granted, but only ~5k permissions that have an IAM V2 representation.
• There are nearly 2,000 Google-managed pre-defined roles available for use.
• 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 why GCP IAM v1 and v2 permissions matter

Context

Google Cloud IAM is a permissions model built on roles, bindings, and hierarchical policy inheritance. This matters because the same permission can appear in different forms depending on whether it is being granted, denied, or surfaced in an audit log, and that creates operational friction for cloud IAM and platform teams.

The governance gap is not the existence of permissions itself, but the mismatch between policy evaluation surfaces. When deny controls reference one permission namespace and logs report another, troubleshooting becomes slower, policy design becomes error-prone, and least-privilege enforcement becomes harder to prove in practice.

Key questions

Q: How should teams manage Google Cloud IAM permissions when allow and deny policies use different formats?

A: Treat permission names as a governed mapping layer, not a simple string value. Maintain a translation table between allow-policy names, deny-policy names, and audit-log output, then validate that table whenever new services or exceptions appear. That makes policy authoring and troubleshooting consistent across IAM layers.

Q: Why do GCP deny policies create coverage gaps for least privilege?

A: Because deny policies only work for permissions that have an IAM v2 representation, while many grantable permissions still do not. A team can think it has central denial in place and still leave large parts of the permission set controlled only by allow policies and inherited access.

Q: What do security teams get wrong about GCP IAM audit logs?

A: They often assume the permission in the log will match the policy entry that caused the denial. In this model, logs report the v1 permission name even when the blocking control is a v2 deny policy, so investigators need both names and the policy hierarchy to diagnose the issue accurately.

Q: What is the difference between IAM v1 and IAM v2 permissions in Google Cloud?

A: IAM v1 is the format used in allow policies and role definitions, while IAM v2 is the format used by deny policies. The two often map closely, but not always, and some services or permissions use different namespaces altogether, which is why teams must not treat them as interchangeable.

Technical breakdown

IAM v1 and v2 permission names are not interchangeable

Google Cloud IAM uses a v1-style permission format for allow policies and role definitions, while deny policies use a v2 fully qualified format. In most cases, the mapping is mechanical, but the article shows that some services use different namespaces entirely. That means a permission can be syntactically valid in one policy layer and unusable in another, even when the intended access decision is the same. This is a policy-language problem, not a role-design problem, and it affects how teams reason about central enforcement.

Practical implication: build a permission mapping process before you rely on deny policies for central control.

Deny-policy coverage is narrower than grant coverage

The article states that GCP has roughly 12,000 grantable permissions, but only about 5,000 have an IAM v2 representation. Because deny policies depend on v2 permissions, more than half of grantable permissions cannot be centrally denied in that form. That creates a structural coverage gap: an organisation may believe it has a complete deny model when in fact large parts of the permission set remain outside that control path. This is especially relevant where inherited access is broad and role sprawl is already a concern.

Practical implication: identify which permissions in your estate cannot be expressed in deny policy and treat them as separate risk items.

Audit logs report v1 permissions even when deny policies block v2

When access is denied, Google Cloud audit logging still reports the v1 permission name. The result is that the visible error often does not match the deny-policy entry that caused it. For practitioners, this means investigation spans at least two representations of the same permission, plus the policy hierarchy that inherited the denial. In cloud operations, that extra translation step can delay root cause analysis and make developer-facing permissions issues look inconsistent.

Practical implication: align logging, policy review, and support runbooks around both permission formats, not just one.

NHI Mgmt Group analysis

Permission namespace drift is a governance failure, not a documentation nuisance. The article shows that Google Cloud can represent the same access intent in different ways across allow policies, deny policies, and logs. That creates an identity governance problem because the control plane is no longer speaking one stable language. Teams that treat the mapping as a cosmetic difference will misread enforcement outcomes and overestimate policy certainty.

Centralised deny control is only as complete as its permission vocabulary. If only about 5,000 of roughly 12,000 grantable permissions can be denied in v2 form, then deny policy is partial by design. The practical implication is that organisations must stop assuming deny controls provide universal backstop coverage across all cloud permissions.

Policy evaluation and incident investigation now require translation work. The article makes clear that logs show v1 names even when a deny policy was written in v2. That means operations teams need a repeatable way to connect errors, inherited policies, and permission aliases. Without that, the IAM programme cannot reliably explain why access failed or prove where enforcement occurred.

Named concept: permission representation mismatch. This is the gap between how a cloud provider names a permission in different IAM surfaces and how teams expect one permission to behave consistently. It matters because governance assumes stable identifiers, but the article shows identity control can fragment across syntax layers. Practitioners need to treat permission identity as a managed data problem, not just a policy-authoring task.

From our research:

• 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, according to the 2026 Infrastructure Identity Survey.
• A separate finding from the same survey shows that systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems.
• For a broader view of identity failure patterns, see 52 NHI Breaches Analysis for recurring control breakdowns and root causes.

What this signals

Permission representation mismatch: cloud IAM programmes should assume that the same access decision may appear under different names in policy and logging. That means entitlement review, deny-policy design, and incident triage need a shared translation layer, otherwise enforcement can be technically correct but operationally opaque.

With 44% of organisations having policies for AI agents despite 92% calling governance critical, identity teams are already operating in a control-lag environment. The lesson here is that governance often trails the system model, so cloud programmes need to normalise the management of permission namespaces before complexity spreads further.

Teams that are extending Zero Trust thinking into cloud IAM should map this problem to policy evaluation boundaries, not just authentication. The practical next step is to align permission naming, inherited policy logic, and audit evidence around a single internal control model, then validate it against the Ultimate Guide to NHIs for lifecycle and access governance patterns.

For practitioners

• Map v1 and v2 permission aliases Create an internal translation table for grant, deny, and log representations of the permissions you actively use. Include service-wide exceptions and permission-specific exceptions so engineers can trace a log entry back to the exact deny-policy token without guessing.
• Inventory permissions outside deny-policy coverage Identify the permissions in your cloud estate that can be granted but do not have a v2 deny representation. Prioritise the services with inherited access, broad role bindings, or high-impact administrative actions, because those gaps are the hardest to compensate for later.
• Update troubleshooting runbooks for both namespaces Teach cloud operations and platform support teams to search for both the v1 error string and the v2 policy entry during incident triage. Add a step for checking inherited policies at organisation, folder, and project levels before concluding that a role binding is missing.

Key takeaways

• Google Cloud IAM can represent the same permission differently across allow policies, deny policies, and audit logs, which makes enforcement harder to interpret.
• Because only about 5,000 of roughly 12,000 grantable permissions have a v2 deny-policy form, central denial is incomplete by design.
• Teams need a permission translation layer, not just better policy writing, if they want least privilege to be explainable and auditable.

Key terms

• Permission Representation Mismatch: A permission representation mismatch occurs when the same access control appears under different names or syntax in different IAM surfaces. In Google Cloud, that can mean allow policies, deny policies, and audit logs do not speak the same permission language, which complicates governance and troubleshooting.
• Deny Policy Coverage: Deny policy coverage is the portion of a cloud provider's permission set that can be centrally blocked using explicit denial rules. If coverage is incomplete, some permissions can still be granted but cannot be denied through the same control path, leaving gaps in least-privilege enforcement.
• Inherited Access: Inherited access is permission that flows from a higher level in the resource hierarchy to lower-level resources without being re-granted. In cloud identity governance, inheritance can widen blast radius because a single binding or denial can affect many child resources, sometimes in ways that are hard to trace.

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: Why GCP’s Two IAM APIs Matter More Than You Think. Read the original.