A list attached to a resource or network object that specifies who can access it and what they can do. ACLs are precise, but at scale they can fragment visibility and make central review harder for security teams.
Expanded Definition
An access control list, or ACL, is a resource-level policy that names which identities can read, write, execute, or administer a file, bucket, queue, API, or network object. In NHI environments, ACLs often sit alongside broader controls such as RBAC and PAM, but they operate at a more granular layer and can be applied directly to service accounts, agents, and application endpoints.
That granularity is useful when a workload needs narrowly scoped access, especially in distributed systems where a single permission change should not affect every identity in a role group. The tradeoff is operational: as ACLs multiply across repositories, storage objects, and cloud services, security teams can lose a clear, central view of effective access. Guidance varies across vendors on how much ACL logic should be used versus inherited from policy engines, and no single standard governs this yet. For a broader NHI governance context, see the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.
The most common misapplication is treating ACLs as a complete identity governance model, which occurs when teams use object permissions without a parallel review process for ownership, rotation, and revocation.
Examples and Use Cases
Implementing ACLs rigorously often introduces administrative overhead, requiring organisations to weigh fine-grained control against review complexity and policy drift.
- A storage bucket grants a build pipeline write access only to a single path, limiting blast radius if the pipeline token is compromised.
- An API gateway ACL allows one agent to call a specific endpoint during an automated workflow, while blocking all other machine identities by default.
- A message queue ACL permits a payment service account to consume events but not publish them, preserving separation of duties.
- A database ACL lets an ETL job read selected tables while preventing ad hoc access from adjacent services that share the same subnet.
- During incident response, analysts compare ACL entries with the identity inventory in the Ultimate Guide to NHIs — Key Challenges and Risks and use the PCI DSS v4.0 documentation to confirm access is limited to the minimum necessary scope.
ACLs are especially useful when a specific resource needs a narrow exception that would be awkward to express in a broad role. They are less effective when the same permission pattern repeats across hundreds of objects, because manual entries become brittle and difficult to audit. The operational pattern in mature environments is to reserve ACLs for exceptional resource-level constraints, then enforce baselines with policy and lifecycle controls supported by the Ultimate Guide to NHIs — Standards.
Why It Matters in NHI Security
ACLs become a security issue when they accumulate faster than teams can review them. In NHI estates, that is common because service accounts, integrations, and agents frequently outnumber human identities and are created for short-lived projects that never fully decommission their permissions. NHIMG research shows that 97% of NHIs carry excessive privileges, which makes resource-level permissions a serious part of the least-privilege problem rather than a side detail. The same pattern appears in breach analysis: access paths that look narrow on paper can still be dangerous when secrets are reused, tokens are long-lived, or ownership is unclear in the first place, as covered in the 52 NHI Breaches Analysis.
For practitioners, ACLs matter because they are often the last line of containment when an NHI token is exposed. They also interact with Zero Trust expectations, where resource access should be explicit, short-lived, and continuously revalidated. That is why Ultimate Guide to NHIs treats access governance as part of the broader lifecycle, not just an authorization setting. Organisations typically encounter ACL sprawl only after a token leak, orphaned integration, or failed audit, at which point the ACL becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses excessive permissions and resource-level access sprawl for NHIs. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit, resource-scoped authorization for every request. | |
| NIST CSF 2.0 | PR.AC-4 | Access permissions management aligns with least-privilege authorization principles. |
Map ACLs to least-privilege reviews and document owners for each protected resource.
