A security model that grants or denies access to systems and data based on a combination of attributes: who is asking, what they are asking for, and the context of the request. For agencies running AI tools across teams with different data clearances, ABAC is how you enforce those distinctions without rebuilding permissions for every new project.
Also known as ABAC, policy-based access control
Attribute-based access control (ABAC) evaluates access requests against a policy that considers multiple factors at once: the user’s role, department, and clearance level; the resource’s classification and sensitivity; the environment (corporate network or remote?); and the action being requested. If the combination of attributes satisfies the policy, access is granted. If not, it is denied.
The contrast with simpler access control models is meaningful. Role-based access control (RBAC) assigns permissions to roles, which works well when roles are stable and permissions are coarse. ABAC handles finer distinctions: the same person might have access to a client’s campaign data but not their CRM, in the office but not on a personal device, during business hours but not at night.
As agencies deploy AI tools that can access, process, and generate content using sensitive data, ABAC frameworks become the mechanism for ensuring those tools operate within appropriate boundaries rather than reaching wherever they technically can.
Agencies operate with multiple clients, multiple team members at different clearance levels, and increasingly powerful AI tools that can reach into connected data stores. Access control is the layer that keeps client data from crossing client boundaries and sensitive information from reaching unauthorized parties.
AI tools expand the access surface. When an AI tool has read access to an account’s shared file drive, it effectively has access to everything in that drive. ABAC policies should define what AI systems are permitted to access, not just what people are, because in practice the two are increasingly the same thing.
Client data segregation is a contractual requirement. Most agency-client agreements include provisions about data handling and isolation. ABAC is one of the technical mechanisms that makes those provisions real rather than theoretical when an audit or incident occurs.
Audit trails matter for compliance. ABAC systems log what was accessed, by whom, under what attributes, and when. When a compliance question or data incident investigation arises, that log is the answer to “who had access to what.” Agencies handling regulated client data need this record.
An agency deploying an AI research tool needs to ensure that team members working on one client account cannot access campaign data or audience files from other clients through the tool. The IT team configures ABAC policies that tie data access to client-project attributes in each user’s profile: a team member can only query data sources tagged to their active client assignments. When someone is reassigned, their access updates automatically. There is no manual permissions audit required each quarter. The policy enforces itself.
The governance and disclosure module of the workshop covers the internal standards your agency needs to use AI without losing client trust or the integrity of the work.