Access Control List (ACL)

The Subject or Principal is the entity requesting access. In an ACL entry, this identifies who the rule applies to.

• Examples: A user ID (e.g., [email protected]), a system process PID, a service account, or a group/role name (e.g., developers).
• Key Point: The subject is distinct from the resource. The ACL answers the question: 'Does this specific subject have permission?'

The Object or Resource is the system entity being protected and accessed. The ACL is attached to this object.

• Examples: A file path (/etc/config.yaml), a database table (customer_records), a network port (TCP/443), or a REST API endpoint (POST /api/v1/users).
• Key Point: ACLs are typically resource-centric. Each object maintains its own list of who can access it, as opposed to user-centric permission lists.

The Operation specifies the exact action the subject is permitted (or denied) to perform on the object. These are the verbs in the access control statement.

• Common Operations: READ, WRITE, EXECUTE, DELETE, LIST. In API contexts: GET, POST, PUT, PATCH, DELETE.
• Granularity: Operations can be coarse (FULL_CONTROL) or fine-grained (read:metadata, write:field.title). Fine-grained operations enable the principle of least privilege.

An Access Control Entry (ACE) is a single rule within an ACL. It is the fundamental tuple that binds a subject, an operation, and an effect for a given object.

• Structure: {Subject, Operation, Effect}
• Effect: The decision, typically ALLOW or DENY. Example: {Subject: "backend-service", Operation: "GET", Effect: "ALLOW"}.
• Composition: A full ACL is an ordered list of ACEs. Evaluation order is critical, as the first matching ACE usually determines the outcome.

The Evaluation Engine is the logic that processes the ACL. Precedence rules define the order in which ACEs are evaluated to reach a final allow/deny decision.

• Default Deny: A core security principle. If no ACE explicitly allows a request, it is implicitly denied.
• Order Matters: ACLs are often evaluated top-down. A DENY ACE for * (everyone) at the top blocks all subsequent ALLOW rules.
• Specificity: More specific ACEs (e.g., for a single user) typically override more general ones (e.g., for a group).

Inheritance allows ACLs defined on a parent object (like a directory) to propagate automatically to new child objects (like files within it). This is crucial for manageable security at scale.

• Propagation Modes: Rules can be inherited and applied as-is, or they can be marked as non-inheritable, affecting only the parent.
• File Systems: Common in NTFS (Windows) and POSIX (Linux/Unix) systems. A directory's ACL defines default permissions for new files.
• Cloud Storage: Bucket-level policies in systems like Amazon S3 can be combined with object-level ACLs.

Role-Based Access Control (RBAC) is an access control model where permissions are assigned to roles, and users (or system identities like AI agents) are assigned to appropriate roles. This abstracts permission management from individual users to job functions.

• Core Concept: Permissions are grouped into roles (e.g., 'Data Analyst', 'API Writer'). Users inherit permissions by being assigned a role.
• Contrast with ACLs: While an ACL answers 'Who can access this resource?', RBAC answers 'What can this role do?' This simplifies management in large systems.
• Use in AI Systems: An AI agent might be assigned a 'Reporting Agent' role, granting it read-only access to specific databases and the ability to call visualization APIs, without listing each permission on every resource.

Attribute-Based Access Control (ABAC) is a dynamic authorization model that grants or denies access based on attributes of the user, resource, action, and environment, evaluated against policies.

• Key Components: Decisions use attributes like user.department, resource.sensitivity, action.type, and environment.time.
• Policy Example: 'Allow access if user.role == "doctor" AND resource.type == "patient_record" AND environment.location == "hospital_network".'
• Advantage for AI: Enables context-aware authorization for agents. An AI's access to a tool can be gated not just on identity, but on the time of day, the sensitivity of the data in its current session, or the security posture of the server it's running on.

These are the core components of a policy-based access control architecture, often used with ABAC or centralized RBAC.

• Policy Decision Point (PDP): The brain. This component evaluates an access request against all applicable policies and rules to render an authorization decision (Allow/Deny).
• Policy Enforcement Point (PEP): The gatekeeper. This component intercepts the access request (e.g., an AI agent's API call), sends it to the PDP, and then enforces the decision by permitting or blocking the call.
• Architectural Flow: 1. AI Agent → PEP ('I want to call this API'). 2. PEP → PDP ('Should I allow this?'). 3. PDP → PEP ('Decision: Allow'). 4. PEP allows the call to proceed to the backend API.

The principle of least privilege is a foundational security mandate that every user, process, or system (including AI agents) should operate using the minimum levels of access necessary to perform its legitimate function.

• Direct Application to ACLs: An ACL should be meticulously crafted to grant only the specific permissions required. For an AI tool-calling agent, this means:
  • Read access only to databases needed for its task.
  • Execute permission only for specific API endpoints.
  • No administrative or write permissions unless absolutely required.
• Security Benefit: Dramatically reduces the attack surface. If an agent's session is compromised, the blast radius of what an attacker can do is strictly limited by its finely-scoped ACLs.

OAuth 2.0 Scopes are permission strings that limit an access token's authority to a defined subset of a resource owner's rights. They are a critical mechanism for credential scoping in API security.

• Function: When an AI agent (client) requests authorization, it specifies the scopes it needs (e.g., files.read, calendar.write). The issued access token is valid only for those scopes.
• Analogy to ACLs: Think of scopes as a dynamically generated, token-bound ACL. The token itself carries the 'list' of what it can access.
• Implementation for AI: An agent's capability to call tools is often gated by possessing a token with the correct scope (e.g., execute:tool_payroll_report). The backend API validates the token's scope before processing the request, enforcing the permission boundary.

Open Policy Agent (OPA) is an open-source, general-purpose policy engine that decouples policy decision-making from application logic. It enables policy-as-code for authorization.

• How it Works: Policies are written in a declarative language called Rego. OPA evaluates queries (e.g., 'Can user X perform action Y on resource Z?') against these policies and data (JSON).
• Unified Control: OPA can enforce policies for API gateways, Kubernetes, microservices, and AI tool-calling layers from a single engine.
• Use Case for Tool Calling: Instead of hardcoding ACL logic, an orchestration layer can query OPA for every tool invocation: input = {"agent": "ai_agent_1", "action": "call", "tool": "customer_db_query"}. OPA evaluates this against centralized Rego policies that may incorporate RBAC, ABAC, and environmental rules, returning a clear allow/deny decision.