What is an access control list (ACL)?

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). 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 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.

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.
• 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; a device that has never seen the newer list can't detect a rollback.

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, and the signing details in how encryption works.

Sources

• NIST CSRC glossary: access control list, checked October 30, 2026.