Access Control List (ACL)

ACLs are fundamentally attached to the resource being protected, not the user. Each file, directory, or database record maintains its own list of authorized subjects. This contrasts with Role-Based Access Control (RBAC), which assigns permissions to roles. In an ACL model, a document's security descriptor directly lists User_A: Read, Write and User_B: Read. This makes it simple to audit 'who can access this specific asset?' but can become complex to manage when updating a user's permissions across thousands of objects.

An ACL is a collection of Access Control Entries (ACEs). Each ACE is a discrete rule containing three components:

• Subject: The security principal (user, group, or process) granted or denied access.
• Access Mask: A bitmask defining the specific operations allowed (e.g., Read, Write, Execute, Delete).
• Type: Typically Allow or Deny. Deny ACEs always take precedence, a critical security principle to explicitly block a specific user even if they belong to an allowed group.

There are two primary types of ACLs:

• Discretionary ACL (DACL) : Controls standard access to an object. It is managed by the object's owner, who can grant permissions at their discretion. This is the primary mechanism for data security.
• System ACL (SACL) : Controls audit policy. It specifies which access attempts by which users should be logged in the security event log. A SACL does not grant or deny access; it only generates audit records for successful or failed access attempts.

When a user attempts to access a resource, the system evaluates the ACL in a strict order of precedence:

1. Explicit Deny: If any ACE explicitly denies the user the requested access, access is immediately blocked. No further evaluation occurs.
2. Explicit Allow: If no deny ACE matches, the system looks for an ACE that explicitly grants the user the requested access.
3. Implicit Deny: If no ACE of any type matches the user's identity or group memberships, access is denied by default. This ensures a secure, closed system where access must be explicitly granted.

In modern Answer Engine Architecture, ACLs are critical for enforcing Document-Level Security during retrieval. Before a language model can ground an answer on a source document, the retrieval pipeline must perform Security Trimming. This involves:

• Pre-Retrieval Filtering: Injecting the user's identity and group memberships as a filter into the vector database query to exclude unauthorized chunks from the similarity search entirely.
• Post-Retrieval Filtering: Re-validating the ACL of each retrieved document chunk before it is passed to the generation context window, ensuring no data leakage occurs.

While conceptually simple, ACLs suffer from scalability issues:

• Permission Explosion: As users change roles, their individual ACEs must be updated on every object they could access, leading to orphaned permissions.
• Lack of Centralized Policy: It is difficult to answer 'What can User X access across the entire system?' without scanning every object's ACL.
• Role Explosion: To mitigate this, groups are often used in ACEs, but this can lead to an unmanageable proliferation of security groups, effectively recreating a poorly governed RBAC model.