# What is an access control list (ACL)?

> An access control list names, on the resource itself, who may use it and how. How ACLs compare with roles, and what signing adds when the server isn't trusted.

URL: https://crunu.com/learn/access-control-list
Language: en
Updated: 2026-10-30

An access control list (ACL) is a list attached to a resource, such as a file, a bucket or a secrets environment, that names every person, group or system allowed to access it and what each of them may do, so that a request is allowed only if the requester appears on the list with the right permission.

## The definition

NIST's glossary, quoting RFC 4949, defines an ACL as "a mechanism that implements access control for a system resource by enumerating the system entities that are permitted to access the resource and stating, either implicitly or explicitly, the access modes granted to each entity" ([NIST glossary](https://csrc.nist.gov/glossary/term/access_control_list)). Unix file permissions, S3 bucket ACLs and network firewall rules are all variations on the idea.

## ACLs and roles

An ACL answers "who can access *this*?" by looking at the resource. [Role-based access control](https://crunu.com/learn/rbac) answers "what can *this person* do?" by looking at their role. Most real systems combine them: the ACL of a resource lists roles or groups rather than individuals, and people get access through membership.

|             | ACL                                      | Roles                                          |
| ----------- | ---------------------------------------- | ---------------------------------------------- |
| Stored with | the resource                             | the person or group                            |
| Good for    | "who can read production?"               | "what can a developer do?"                     |
| Weakness    | many resources, many lists to keep right | roles that grant more than each resource needs |

## Who enforces the list

In most systems the server reads the ACL and decides. That makes the list only as trustworthy as the server: someone who can change the server's data can add themselves to the list, and nobody downstream will notice. Two things change that:

- **Signing the list.** If an administrator signs the ACL with a key the server doesn't have, clients can check it, and a list the server edited fails the check.
- **Binding the list to keys.** If being on the list means receiving a decryption key, and not being on it means not having one, the list is enforced by cryptography as well as by the server.

## Common mistakes

- **Individual entries everywhere.** Lists of named people drift as people move; groups or profiles age better.
- **No review.** An ACL nobody reads collects former staff. See [access review](https://crunu.com/learn/access-review).
- **Trusting a list you can't verify** when the server that serves it may be compromised.

## The access list in Crunu

Every Crunu environment has an access list, written in a document called the environment head and signed by an owner or admin. It names each recipient, person, machine or service token, with their role or delivery method, and commits to the current environment key. A list can hold up to 5,000 entries.

Clients and agents check the signature before trusting anything, so the server can't add itself as a recipient, swap the environment key or rename `prod` to `dev` without breaking it. Recipients also get the environment key, or a sealed copy of their files, only if they are on the list. Clients remember the newest list they have seen and reject older ones, which is [rollback protection](https://crunu.com/learn/rollback-protection); a device that has never seen the newer list can't detect a rollback.

*Figure: A diagram of Crunu’s keys in six levels, with your device on the left and the server on the right. Your password and Secret Key stay on your device and are never sent. Together they make your account key, which never leaves the device either. It decrypts your own X25519 and Ed25519 keys, which the server holds only encrypted. Owners and admins also hold the organization’s signing and recovery keys, sealed to them. The organization’s signing key certifies who may receive each environment key. Every environment has its own key, and the server holds only sealed copies of it. Each version is encrypted with AES-256-GCM, padded to 4 KB and signed by its author, and the server holds only that ciphertext.*

The list has no expiry dates: access stays until someone removes it. How this fits with roles and profiles is in [how to share .env files with your team](https://crunu.com/guides/share-env-files-with-a-team), and the signing details in [how encryption works](https://crunu.com/docs/security/how-encryption-works).

## Sources

- [NIST CSRC glossary: access control list](https://csrc.nist.gov/glossary/term/access_control_list), checked October 30, 2026.