The unit is more than a logged-in account
A subject requests an operation on a protected object. Objects include files, records, services and devices, and permissions can vary by both object and action. Being allowed into a system therefore does not describe its complete boundary.
Policy may also consider context: department, resource category and current conditions can jointly determine access. The objective is controlled sharing rather than either exposing everything to every account or forbidding all cooperation through complete isolation.
References: [1]
Policy, decision and enforcement
A model specifies relationships and rules for expressing policy; a mechanism receives and mediates requests. NIST distinguishes a policy decision point from a policy enforcement point: one evaluates permission and the other applies it. They need not be one process.
ACLs associate objects with permitted subjects and rights, RBAC connects permissions to roles, and ABAC evaluates attributes against policy. Implementations can combine them, but naming a model does not establish that every entry point enforces its policy.
References: [1]
Authority changes affect reusable decisions
Authority can change after account creation: departure, role changes or resource reclassification can alter permission. Administration therefore includes assignment, revocation and propagation rather than only an initial allow list.
Caching reduces network attribute requests, but stale attributes or decisions can outlive revoked access. Complete mediation does not equate previously allowed with allowed forever. Cache refresh, accepted staleness and disconnected operation require explicit policy and mechanisms.