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.
Why This Matters for Security Teams
Google Cloud’s IAM v1 and IAM v2 are not interchangeable permission formats, and that distinction matters because access governance fails fastest when teams assume names, scopes, or policy types map cleanly across services. In practice, the risk is not just a misread policy document. It is a permission grant that behaves differently than expected, especially when deny policies, custom roles, or product-specific namespaces are involved. That becomes harder to spot in estates already struggling with NHI sprawl, as highlighted in the 2024 Non-Human Identity Security Report.
Security teams often treat IAM versioning as a documentation issue, but it is really an enforcement issue. A permission that exists in one namespace may not exist in another, and a role that appears equivalent may not be applied the same way across allow and deny logic. Current guidance suggests mapping permissions back to the exact policy engine and service boundary before making change decisions. That approach aligns with the broader warning in the OWASP Non-Human Identity Top 10: identity mistakes become security incidents when automation and service accounts inherit access beyond what operators intended. In practice, many security teams discover the mismatch only after a deny rule blocks production traffic or an allow rule is broader than expected.
How It Works in Practice
IAM v1 is typically the format teams encounter in allow policies and role definitions, where the question is who can do what. IAM v2 is used for deny policies, where the question becomes what must never be allowed, even if another policy would permit it. That shift matters because deny evaluation is not just a mirror image of allow. It introduces a separate policy path, a different resource model, and in some cases different permission naming semantics. Teams should verify whether a service exposes the same permission string in both contexts before assuming policy parity.
Operationally, the safest workflow is to treat permission references as service-scoped facts, not portable abstractions. A practical review process usually includes:
- Checking the exact service documentation for the permission namespace in use.
- Validating whether the permission appears in allow policy, deny policy, or both.
- Testing whether custom roles, predefined roles, and deny rules resolve the same way.
- Confirming that any automation consuming permissions is reading the correct IAM version.
This is especially important for workload identities and other NHI patterns, where one mis-scoped role can cascade through CI/CD, GKE, or serverless automation. The broader NHI governance problem is well illustrated in NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities and the related Ultimate Guide to NHIs — Key Challenges and Risks, because access complexity grows faster than human review capacity. These controls tend to break down when teams bulk-convert policies across many projects without revalidating the permission namespace for each service.
Common Variations and Edge Cases
Tighter permission mapping often increases administrative overhead, requiring organisations to balance consistency against the risk of incorrect translation. That tradeoff becomes more visible in hybrid estates, where some services expose legacy IAM structures while newer services adopt deny-first patterns or alternate permission models.
Current guidance suggests watching for three edge cases. First, some Google Cloud services use different permission namespaces altogether, so a v1-looking name may not behave the same way in a v2 deny rule. Second, custom roles can obscure the underlying permission source, which makes drift harder to detect during reviews. Third, automation that was built to read allow policies may silently mis-handle deny policy logic, especially during migrations or security hardening projects. The Google Firebase misconfiguration breach is a useful reminder that cloud security failures often begin with small configuration assumptions that scale quickly.
For teams applying the question to NHI governance, the practical rule is simple: never assume version equivalence unless the service documentation proves it. Permission names should be tested in context, not copied across policy types. Where the product surface is inconsistent, policy-as-code checks and pre-deployment validation are preferable to manual review. Best practice is evolving here, but the safe stance is to treat IAM v1 and IAM v2 as related systems with different semantics, not as interchangeable labels.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Permission namespace confusion often leads to over-privileged NHI policies. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed consistently across policy versions. |
| NIST AI RMF | GOVERN | Policy translation errors create governance gaps in automated environments. |
Map IAM v1 and v2 permissions to controlled entitlement reviews and change checks.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
