Glossary
Access Control List (ACL)
A per-resource list of who may do what. ACLs are the oldest and most direct form of authorisation, and they still sit underneath file systems, cloud storage, networks and chat rooms.
General definition
Access Control List (ACL) is a security mechanism in which each protected object carries its own list of entries, and each entry pairs a subject (a user, a group, a role or a system) with the operations that subject is allowed or denied. When a request arrives, the system looks up the object’s ACL, finds the matching entry and grants or refuses the operation. The object owner, or an administrator, edits the list to change access.
ACLs appear at several layers of a modern stack:
- File systems: POSIX ACLs on Linux and NTFS permissions on Windows extend the basic owner, group and other model with per-user entries
- Cloud storage and identity: object ACLs and policies on buckets, plus fine-grained permission sets in admin consoles
- Networks: router and firewall ACLs filter traffic by source, destination, port and protocol, and cloud network ACLs do the same for subnets
- Applications: per-room, per-document or per-feature lists that decide which members can read, write, invite or administer
The strength of an ACL is precision: you can say exactly who may touch exactly this object. The weakness is scale. With thousands of users and objects, per-object lists become hard to review, and it is difficult to answer the question an auditor cares about most, which is everything a given person can access. That is why ACLs are usually paired with role-based access control (RBAC): roles carry the broad job-function permissions, and ACLs handle the exceptions on individual resources.
Good ACL design follows a few habits: deny by default, put groups or roles in entries rather than individual users where possible, keep an explicit owner for every object, and log every change to the list so that the audit log shows who widened access and when.
In the Ethora ecosystem
In Ethora, ACL settings live in the admin panel. The app owner invites team members and, for each one, chooses which areas of the App they may view or manage: users, rooms and channels, AI agents and the other administrative settings of the App. This lets a clinic, a bank or an agency give a support agent, a compliance officer and a developer different views of the same App without sharing credentials.
The same idea applies inside the chat. Each room or channel has admins and members, and membership gates what a person can read and which attachments they can open, so a file shared in a private room is not reachable by someone outside it. Administrative actions and permission changes are written to the compliance audit trail, and on a dedicated or self-hosted server your own infrastructure ACLs (network, storage, database) sit around the platform as a second layer.
