Operational Trust starts with people and business roles — not technical endpoints. Users and groups define who belongs to the organization. Roles define how work is performed. Permissions and policies define what is allowed.
Why it matters
Enterprise AI must know who is acting and which business role is active. A Sales Manager, Project Manager, and Finance Approver see different information, actions, approvals, and evidence requirements. Without role context, AI operates as a generic system user — unsafe for enterprise work.
How it works
Users → Groups → Roles → Permissions → Policies → Access decisions
- Users — individuals authenticated through enterprise identity
- Groups — organizational membership (team, department, region)
- Roles — business responsibilities that shape available work and capabilities
- Permissions and policies — rules that allow, deny, or require approval
The active role is the operating boundary for Role Assistants: it determines visible data, allowed capabilities, approval requirements, and audit context.
Roles vs platform permissions
Business roles (Sales Manager, Legal Counsel) express how work is done. Platform permissions control who may administer integrations, upload protection rules, or run certification. Architects define both: business roles for Role Assistant scope, platform roles for who may change trust configuration.
Groups often mirror org structure but should not replace role checks — a user in “Sales EMEA” still needs an active Sales Manager role to request pipeline capabilities.
Governance subjects
Protection and governance certification uses subject-scoped tests: a real user in a defined business role. This proves ABAC boundaries, not merely that an admin can connect APIs.
Common mistakes
| Mistake | Risk |
|---|---|
| Using platform admin for all tests | Governance certification misrepresents Role Assistant scope |
| Confusing groups with roles | Users see data without business responsibility |
| Skipping active role in Role Assistant design | AI acts with ambiguous authority |
Architects document role catalogs alongside capability matrices so certification and Role Assistant design use the same vocabulary.
Designing role catalogs
Start from roles the business already uses in HR, CRM, or IT service management — not from API permission names. Each role should answer: what decisions can this person make, what data categories do they touch, and which Role Assistant tasks run under their authority?
Document role-to-capability matrices at the architecture level before integrators bind technical permissions. When the same person holds multiple roles, define how active role is chosen at login or task start so AI never merges incompatible authorities.
Review role catalogs when org structure changes, when new regulated data classes appear, or when you add Role Assistants that span departments.
Example
When a Sales Manager asks a Sales Assistant to review a pipeline, AI Fabrix checks that the user is known, the Sales Manager role is active, and pipeline-related capabilities are allowed for that role — before any governed action is requested.
Business value
Role-based context reduces unsafe automation, aligns AI work with how the business actually operates, and makes access decisions explainable.