Topic starter
14/09/2026 10:09 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Infisical: “There is no 10x RBAC”.
Key questions
Q: How should teams govern folder-scoped access when roles already exist?
A: They should treat folder-scoped access as an override layer with explicit precedence over inherited roles, groups, and temporary grants.
Q: Why do secrets teams need immutable identifiers for access grants?
A: Because folder names and paths change over time, while access intent usually does not.
Q: What do security teams get wrong about least privilege in RBAC?
A: They often treat RBAC as a set-and-forget structure, when roles actually degrade over time through exceptions, inherited access, and convenience-driven expansion.
Practitioner guidance
- Define precedence for folder-scoped overrides Document exactly when folder-level grants should supersede inherited role, group, and temporary permissions, then enforce that order consistently across all checks.
- Bind grants to immutable object IDs Use stable folder identifiers for access rules so renames and moves do not detach policy from the secret hierarchy it was meant to protect.
- Treat exception paths as security debt Inventory per-person grants and other override mechanisms that sit outside normal roles, then review whether they create parallel access paths or excessive reach.
Bottom line: Folder-based secrets access is not a cosmetic RBAC change. It forces teams to reconcile role inheritance, exceptions, and object lifecycle in one authorisation path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/09/2026 10:10 am
Folder-scoped RBAC is really a governance overlay, not a convenience feature: Once access can be granted at the folder level, the system is no longer only mapping roles to permissions. It is reconciling inherited access, per-person exceptions, and mixed human and machine identities in one authorisation decision. The practitioner lesson is that simple-looking delegation features often create the hardest policy precedence problems.
A question worth separating out:
Q: How do you know folder-based access controls are actually working?
A: You know they are working when renames, moves, and permission updates do not change access decisions unexpectedly and when the deny baseline reliably blocks inherited access before any folder-specific allow is restored. If cache refresh or policy precedence is wrong, the control is not trustworthy.
👉 Read our full editorial: Folder-based RBAC changes how secrets access should be governed