TL;DR: Folder-based RBAC for secrets management shows that simple-looking authorization changes often require layered permission logic, cache invalidation discipline, and support for both human and machine identities, according to Infisical. The governance lesson is that access models fail when they cannot reconcile intuitive delegation with existing identity complexity and operational reliability.
NHIMG editorial — based on content published by Infisical: folder-based RBAC for secrets access
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should teams handle scoped access when role-based access is too broad?
A: Treat scoped access as a policy-resolution problem, not a role-editing shortcut.
Q: Why do folder-level permissions often break in real identity systems?
A: They break when the policy model assumes a folder path is stable, but the operational system allows renames, moves, and multiple grant paths to the same resource.
Q: What signs show that authorization caching is no longer reliable?
A: Watch for permissions that change correctly in the database but not at request time, especially after folder renames, moves, or hierarchy edits.
Practitioner guidance
- Map inherited and scoped entitlements separately Inventory where roles, groups, temporary grants, and machine memberships can all reach the same secret so you can see which path actually determines effective access.
- Use stable object identifiers for scoped grants Anchor folder-level authorization to immutable IDs rather than renameable paths so moves and refactors do not silently alter effective permissions.
- Define explicit precedence for override rules Document how deny and allow layers interact before you add folder-scoped exceptions, then test that inherited access is always reduced in the intended order.
What's in the full article
Infisical's full article covers the engineering detail this post intentionally leaves at the governance level:
- The exact permission tier model used to represent list, read, edit, manage, and full access for folder-scoped grants
- The deny-then-allow CASL pattern that makes folder access override inherited roles and group membership
- The additional privilege table changes that preserve legacy access while introducing folderID-based grants
- The version-counter cache invalidation approach used when folder renames and moves change effective policy
👉 Read Infisical's article on folder-based RBAC for secrets access →
Folder-based RBAC for secrets: what changes for IAM teams?
Explore further
Folder-scoped authorization exposes an identity governance truth: access that is easy to grant is not necessarily easy to govern. The article shows why per-object exceptions quickly collide with inherited role logic, especially once human users, machine identities, and temporary grants all coexist. That is not just an implementation inconvenience. It is a governance signal that entitlement expression and entitlement enforcement are drifting apart.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- Another finding from the same research shows that 97% of NHIs carry excessive privileges, which is why entitlement scope must be treated as a primary control problem.
A question worth separating out:
Q: How do machine identities complicate folder-based RBAC?
A: Machine identities make access harder because they share the same entitlement surface as people but often need different scoping and offboarding discipline. A folder rule that is intuitive for a human user may be too broad, too narrow, or too brittle for a service account that is tied to deployments, integrations, or automation.
👉 Read our full editorial: Folder-based RBAC changes how secrets access should be governed