Folder-based RBAC changes how secrets access should be governed

At a glance

What this is: Infisical describes folder-based RBAC for secrets as a way to make access grants more intuitive while preserving existing role, group, and machine-identity permission paths.

Why it matters: For IAM and NHI teams, the key issue is not just cleaner authorization syntax but whether access control can remain correct when roles, folders, service identities, and cache state all interact.

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.

👉 Read Infisical's article on folder-based RBAC for secrets access

Context

Folder-based access control matters because secrets systems sit at the point where authorization errors become either credential exposure or operational outage. When the same secret can be reached through roles, groups, temporary grants, and machine identities, the governance problem is not whether access exists but whether it can be expressed, audited, and changed without collateral damage.

The article is about a secrets-management authorization model, but the underlying identity lesson is broader: RBAC that works for static team roles often becomes awkward when applied to per-folder scoping, contractor exceptions, and machine identities. That puts the issue squarely in NHI governance and identity lifecycle design, not just application engineering.

Key questions

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. Keep inherited roles intact, then apply a narrower object-level rule that can safely override broader access without creating duplicate custom roles. The key is deterministic precedence so the intended restriction always wins for the target folder or resource.

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. If the grant is tied to a mutable path instead of a stable identifier, the effective permission can drift or fail after routine administration.

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. If the same identity sees different results before and after a tree change, the cache boundary is too narrow and the fingerprint does not cover the full authorization context.

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.

Technical breakdown

Why folder-scoped RBAC is harder than role-based access

Folder-scoped permissions are deceptively simple because the user thinks in terms of a named container, while the system still has to reconcile roles, groups, temporary grants, and machine memberships underneath. In the article, Infisical keeps the underlying role model but adds folder-specific privilege tiers that can override inherited access. That works only if the authorization engine can resolve precedence cleanly and consistently across human and machine identities.

Practical implication: teams should treat scoped access as a policy design problem, not a UI convenience feature.

Why deny-and-reallow logic is necessary for inherited access

A path-scoped grant cannot safely rely on additive permissions alone when the same identity already has broader access through another route. The article’s solution uses a deny layer followed by a limited allow layer so folder access supersedes inherited permissions from roles or groups. This is a classic access-resolution pattern: the system must negate broader entitlements before reintroducing the narrower one, or the effective policy remains ambiguous.

Practical implication: implement deterministic precedence rules before introducing scoped overrides into an existing RBAC model.

Why permission caching breaks when folders can move or rename

Cached authorization decisions depend on stable inputs, but folder-based access is tied to a hierarchy that can change when folders are renamed, moved, or deleted. Infisical found that fingerprinting the grant row or the immediate folder was insufficient because the effective path changes as ancestors change. Their version-counter approach captures write activity at the project level, which is the real invalidation boundary for path-based authorization state.

Practical implication: cache invalidation must follow the full authorization tree, not just the local object being changed.

Threat narrative

Attacker objective: The objective is to reach secrets that should have remained out of scope or to disrupt access to secrets needed for production work.

1. Entry occurs when an identity receives broader inherited access than its task actually requires, creating an authorization path that can reach sensitive secrets through roles, groups, or legacy grants.
2. Escalation occurs when the system cannot cleanly subtract privileges for a folder-scoped exception, so the user either gets too much access or the policy becomes too hard to use and gets broadened.
3. Impact occurs when secret access is either overexposed to the wrong identity or broken for the right one, causing credential exposure or production outages.

Breaches seen in the wild

• Palo Alto Networks Key Breach — Supply chain breach compromises Palo Alto Networks and exposes customer credentials and information.
• SAP Breach — Breach of SAP systems exposes enterprise credentials and sensitive business data.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Machine identities make scoped access harder because they reduce the usefulness of human team metaphors. A contractor, service identity, or project-specific machine actor may need access that is narrower than its parent role or group, and RBAC alone does not model subtraction well. This is where NHI governance becomes more than secret inventory. Practitioners need access structures that reflect task scope, not organisational convenience.

Path-based grants create a new form of identity blast radius. Once authorization depends on folder location, rename and move operations become security-relevant changes, not just administrative housekeeping. That means lifecycle events can silently change effective access if the system does not anchor grants to stable object identifiers. The practitioner conclusion is straightforward: access governance must survive object refactoring without changing meaning.

Cache correctness is now an authorization control, not a performance detail. When permission checks happen on every request, stale cached state can become a security failure mode as quickly as a bug in the policy engine. The article’s version-counter approach shows that authorization freshness is part of the trust boundary. Teams should treat invalidation as a governance requirement, not a tuning exercise.

From our research:

• 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.
• For a deeper lifecycle view, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding discipline.

What this signals

Folder-based access will keep exposing the same enterprise pattern: the more intuitive the authorization layer becomes for users, the more important it is to preserve strict object identity, precedence, and invalidation rules behind the scenes. That matters for NHI programmes because service accounts and automated integrations rarely fail at the point of assignment alone. They fail when entitlement state becomes stale, ambiguous, or impossible to audit cleanly.

Scoped secrets access is an identity lifecycle issue, not just a permissions issue. If a contractor, integration, or machine actor can be granted narrower access today and broader inheritance tomorrow, the programme needs lifecycle-aware controls that survive refactors and project churn. The NHI Lifecycle Management Guide is the right mental model here: treat entitlement changes as lifecycle events, not one-off admin clicks.

The practical signal for IAM leaders is that folder-level RBAC only helps if it reduces configuration ambiguity without creating hidden exceptions. The moment scoped grants become harder to reason about than the old role they were meant to replace, governance debt grows faster than control maturity.

For practitioners

• 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.
• Treat permission cache invalidation as security logic Tie authorization fingerprints to the full project-level change boundary so folder renames, moves, and deletes always force a fresh access decision.

Key takeaways

• Folder-scoped RBAC solves a real governance gap, but only if it can override inherited access without creating ambiguous entitlement paths.
• Secrets access models that mix roles, groups, machine identities, and temporary grants need stable identifiers and deterministic precedence to stay trustworthy.
• For IAM and NHI teams, the real control question is whether scoped access survives lifecycle change, cache refresh, and object refactoring without changing meaning.

Key terms

• Organization-scoped RBAC: Organization-scoped RBAC assigns roles and permissions within a specific tenant or membership, not globally across the whole product. The same user may hold different access in different organisations, so authorization must resolve the active tenant before deciding what the user can do.
• Authorization precedence: The rule that determines which permission wins when multiple access paths apply to the same identity and resource. In secrets systems, precedence must be explicit so folder-level restrictions can override inherited roles, groups, or legacy grants without creating ambiguity or accidental overexposure.
• Permission fingerprint: A cached summary of the state used to evaluate access, such as grant rows, hierarchy changes, or version counters. It lets a system avoid recalculating authorization on every request, but only works when the fingerprint covers every change that can alter effective access.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

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

👉 Infisical's full post covers the permission model, override logic, and cache invalidation details behind folder-based access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.