feat(permissions): folder rbac

[adilsitos]

Context

This introduces a new permission into the system, the RBAC for folders. More info on the design doc.

Screenshots

Steps to verify the change

There are several scenarios, so my recommendation is to create a folder with: secrets, dynamic secrets, rotations, imports and (if you want) honey tokens. Use an account which is project admin and another account that you can keep changing their permissions, so it is easier to validate how the permissions are being evaluated.

Scenario 1: The user has folder RBAC permission in two different folders

• expected: the permissions from one folder don't modify the permissions of another folder

Scenario 2: Check the cache is working correctly

• To do this it is recommended to enable the debug mode on knex, so you sure the cache is happening correctly (you can add DEBUG=knex:query on the .env)
• expected: if the marker is still up (15 seconds) the cache should responde directly. If the marker is not valid, we need to just compute the fingerprint

Scenario 3: Delete folders with RBAC as a member user

• Define your test user to have the role member
• Define permissions to a folder to a specific user (it can be any user)
• expected: the member user cannot remove the folder, because the folder has RBAC permissions, so only project admins or full access users can delete it.

Scenario 4: Move folders with RBAC as a member user

• Define your test user to have the role member
• Define permissions to a folder to a specific user (it can be any user)
• expected: the member user cannot move the folder, because the folder has RBAC permissions, so only project admins or full access users can delete it.

Scenario 5: Project admins don't show on the rbac sheet

• expected: when opening the RBAC sheet, make sure that project admins (identities or users) don't appear there.

Scenario 6: Check all the defined permissions defined

• Keep changing the permission using the project admin to validate that the targeted user is getting the desired permissions (this is the most exhaustive one)

Type

• Fix
• Feature
• Improvement
• Breaking
• Docs
• Chore

Checklist

• Title follows the conventional commit format: type(scope): short description (scope is optional, e.g., fix: prevent crash on sync or fix(api): handle null response).
• Tested locally
• Updated docs (if needed)
• Updated CLAUDE.md files (if needed)
• Read the contributing guide

[linear]

ENG-5532

[infisical-review-police]

💬 Discussion in Slack: #pr-review-infisical-7762-feat-permissions-folder-rbac

Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
9387832	Triggered	Generic Password	e1776a6	backend/scripts/dev-folder-rbac.ts	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

[greptile-apps]

Greptile Summary

This PR introduces folder-scoped RBAC for Secret Manager projects, allowing administrators and full-access folder grantees to assign tiered, optionally temporary access to users and machine identities.

• Adds folder-grant persistence, migrations, permission-rule construction, fingerprint caching, and invalidation across folder mutations.
• Adds authenticated APIs for granting, updating, revoking, listing, and auditing folder access.
• Updates secret, folder, dynamic-secret, reminder, approval-policy, and move operations to evaluate path-aware permissions.
• Adds the folder-access management UI, frontend API hooks, and extensive unit and end-to-end coverage.

Confidence Score: 5/5

The PR appears safe to merge; no concrete blocking or independently actionable non-blocking defect was identified.

Folder RBAC operations consistently resolve resources within the authorized project, enforce exact-path Manage Access checks, validate grant targets, and coordinate permission-cache version updates with grant mutations.

Important Files Changed

Filename	Overview
backend/src/services/folder-permission/folder-permission-service.ts	Implements folder-grant CRUD and actor listings with project-scoped folder resolution, Manage Access checks, target eligibility checks, and transactional cache-version invalidation.
backend/src/services/folder-permission/folder-permission-dal.ts	Adds project- and organization-scoped user and identity roster queries, including group-derived access and active administrator exclusion.
backend/src/ee/services/permission/permission-service.ts	Integrates cached folder-scoped grants into project ability construction and adds project-wide fingerprint invalidation.
backend/src/ee/services/permission/folder-roles.ts	Defines cumulative folder access tiers and exact-path deny rules that replace relevant base-role permissions.
backend/src/ee/services/permission/permission-fns.ts	Adds folder-grant fetching, active-grant filtering, fingerprinting, and path-conditioned CASL rule construction.
backend/src/db/migrations/20260817120000_folder-scoped-additional-privileges.ts	Extends additional privileges with folder and role fields, referential integrity, and actor-per-folder uniqueness constraints.
backend/src/server/routes/v1/project-membership-router.ts	Exposes validated JWT-only user folder-access CRUD and listing endpoints.
backend/src/server/routes/v1/identity-project-membership-router.ts	Exposes validated user and identity-token APIs for machine-identity folder-access CRUD and listing.
frontend/src/pages/secret-manager/OverviewPage/components/FolderAccessSheet/FolderAccessSheet.tsx	Adds the primary folder-access roster UI with searching, actor-type merging, tier editing, temporary access, and revocation.
frontend/src/hooks/api/folderAccess/mutations.tsx	Implements folder-grant mutations and invalidates roster, secret, dashboard, and project-permission queries after successful changes.

_{Reviews (1): Last reviewed commit: "fix: add manage-access check on folder m..." | Re-trigger Greptile}

[veria-ai]

PR overview

This pull request introduces folder-level role-based access control, including folder permission handling for users whose project access is derived through groups.

Three security issues have been addressed, with one remaining. Folder grants can persist after a user loses their final group-derived project access, allowing those permissions to reactivate if the user is later re-added to the project without a new folder grant. Exploitation depends on the user subsequently regaining project membership.

Open issues (1)

• Low: Group-derived grants reactivate after project re-entry — backend/src/services/folder-permission/folder-permission-fns.ts:100

Fixed/addressed: 3 · PR risk: 4/10

[github-actions]

API changes

The breaking changes reported earlier are resolved as of 0ebb2a2.

[veria-ai]

Low: Group-derived grants reactivate after project re-entry

This permits grants to actors whose only project access comes through a group, but those grants are stored against the actor and project rather than a membership. The group-removal flows do not delete these rows, so an attacker removed from their final project group can regain the old folder access automatically if they are later added back to the project, without an administrator granting that folder access again. When group removal eliminates an actor's final direct or group-derived access to a project, delete their folder-scoped grants and invalidate the folder-permission cache.

[adilsitos]

veria-ai this was fixed