> ## Documentation Index
> Fetch the complete documentation index at: https://infisical.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Folder-level access controls
> Grant users and machine identities a specific role inside a single folder.
Folder-level access controls assign a role to a user or machine identity on a single [folder](/docs/documentation/platform/folder). Inside that folder, the grant replaces whatever their project roles would otherwise allow, so it can widen access or narrow it.
Folder-level access controls are a paid feature.
If you're using Infisical Cloud, then they're available under the **Pro plan**.
If you're self-hosting Infisical, contact [sales@infisical.com](mailto:sales@infisical.com) to purchase a license.
## How folder access works
When you give a single user or machine identity a role on a folder, that role takes precedence over their [project role](./role-based-access-controls). You can use folder access to:
* Give someone access to a single folder their project role doesn't reach.
* Hold someone to a lower role inside a sensitive folder.
* Hand out short-lived access for an incident or a one-off task.
A folder role only applies to the exact folder you set it on.
Folder access isn't recursive. If you have a certain role on `/payments`, the same role doesn't automatically apply to `/payments/keys`. Inside a subfolder, the user or identity falls back to
whatever their project roles allow.
## Folder access roles
There are five different folder access roles, listed here from least to most privileged. Each role includes everything the roles before it allow.
| Role | What it allows |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **List** | See secret names and metadata without their values. Read secret imports, tags, and the configuration of secret syncs, secret rotations, and honey tokens. |
| **Read** | Everything in List, plus reading secret values, viewing commit history, generating dynamic secret leases, and subscribing to secret events. |
| **Edit** | Everything in Read, plus creating, editing, and deleting secrets and secret imports. |
| **Manage** | Everything in Edit, plus managing secret rotations, dynamic secret root credentials, honey tokens, and secret syncs, including reading the credentials they generate. |
| **Full Access** | Everything in Manage, plus deleting subfolders of this folder and granting or revoking access to it. This role doesn't grant access to delete the folder itself, because deleting a folder is authorized on its parent. |
If you move or rename a folder, it keeps the same role. Deleting the folder removes the role permanently.
## Granting folder access
Navigate to your project's **Secrets** page and select an environment. You can set access on the folder you're currently viewing, or on any folder in the list. To set access on the current folder, select the members icon next to the environment selector.
To set access on a folder in the list, hover over its row and select the members icon that appears.
The **Manage Permissions** sheet lists everyone who can already reach this folder through their project roles. Anyone whose access comes from a project role rather than a grant shows an **Access from project role** selector, and hovering over it names their roles.
Use the dropdown on any row to set their folder role. The same menu lets you add temporary access or remove access. Project admins appear as having full access on all folders and cannot be given a folder grant.
Select **Add Access** and pick the user or machine identity you want to assign a role to. This list includes project identities who have no access to this folder at all. Choose a role, optionally set a duration under **Temporary access**, then select **Add Access** to save.
If a user/identity's usual project permissions would change after being granted the folder access role, that user/identity is marked with **Overrides project role**:
Each row now shows their role in a dropdown, which you can use to change or remove it later.
## Setting temporary access
Access can be time-bound so you can choose a duration when you add it, or open the role dropdown on an existing row and set one there. The row then shows how long is left, and once the window elapses the access stops applying immediately and the user or identity falls back to their project roles.
Full Access can't be temporary. A Full Access holder can grant folder
access to other people, and those accesses would outlive their own expiration.
Grant Full Access permanently, or use Manage for time-bound access.
## Reviewing folder access
To see every folder a user or machine identity has been granted access to, go to your project's **Access Control** page and open that user/identity. The Folder Access lists each grant with its folder, environment, role, and duration, and lets you change or revoke it.
