An access control list (ACL) attaches permissions directly to a protected resource. Each entry names a principal—an individual, group, or sometimes wildcard—and the actions it may perform. When a request arrives, the resource checks its own list and allows or blocks the requested action. ACLs commonly protect files, database records, network shares, cloud storage objects, and API endpoints. section 5.1 section 5.1.1
Shared campaign folder
A marketing folder can carry entries such as Alice: read/write, Marketing team: read/write, Bob: read, and everyone else: no access. A team member can be authorized through group membership without appearing by name; a request for an action not granted by the matching entry is denied. section 5.1 section 5.1.1
Figure 5.1 An ACL attached to a shared resource. The ACL specifies which principals—such as Alice, Bob, and the Marketing group—are authorized to access the “Marketing Campaign Plans” folder and outlines the actions they are allowed to perform.
View the resource and its attached entries together: the list identifies principals and the actions each may take. section 5.1
ACLs are static authorization: decisions use the principal, group membership, and permissions stored on the resource, rather than runtime signals such as time, device posture, or network zone. They are fast, predictable, local, and easy to understand for stable, clearly owned resources with few principals and low policy complexity. section 5.1.3 section 5.1.4
ACL administration becomes difficult when access must span many resources or change frequently:
- Each resource needs its own list, so a single access change may require many updates. section 1.2.4 section 5.1.5
- Distributed lists and nested group memberships obscure who can access what and make policy effects hard to predict. section 1.2.7
- Entries state what access exists, not the business reason for it; exceptions and compliance reviews therefore become harder to govern. section 5.1.5
- Inheritance can reduce repeated entries for nested resources, but local, tightly coupled enforcement remains hard to centralize across distributed systems. section 5.1.1 section 5.1.2
In an ACL-based architecture, the application or resource commonly enforces the request and contains the decision logic and locally managed list. Identity or group membership supplies the main runtime information. As organizational needs become broader or more contextual, Role-Based Access Control (RBAC), relationship-based access control (ReBAC), attribute-based access control (ABAC), or policy-based access control (PBAC) provide other ways to express and manage policy. section 5.1.2 section 6.4
