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 and which capabilities may be requested. Permissions and policies define what is allowed.
AI has no authority of its own. Every action runs on behalf of an identified person, within that person’s existing organisational authority. Without role context, AI would act as a generic system user — unsafe for enterprise work.
There is one Role catalog in the Controller. AI Fabrix platform roles and enterprise business roles (Sales Manager, Finance Controller, and roles you add) appear together. Groups bind to roles; roles hold permissions. Prefer a minimal seed, then extend — quality over quantity. See AI Fabrix roles.
Why it matters
Enterprise AI must know who is acting and which business role is active. A Sales Manager, Project Manager, and Finance Approver may recommend, prepare, or perform different work, with different approvals and evidence.
Roles grant capabilities — not data. Which records fall in scope is managed through dimensions and protection. Do not invent a role for every data slice.
How it works
Users → Groups → Roles → Permissions → Policies → Access decisions → Governed capabilities
- Users — identified people authenticated through enterprise identity
- Groups — organisational membership (team, department, region) or platform groups
- Roles — catalog entries that shape capabilities, approvals, and Role Assistant packaging
- Permissions and policies — rules that allow, deny, or require approval
- Dimensions — which records are in scope (separate from the role itself)
The active role is the operating boundary for Role Assistants: it bounds what work may be requested, which approvals apply, and what must be evidenced. Record visibility follows dimensions and protection under that role.
One catalog — business work and platform access
| Concern | Where to read |
|---|---|
| What AI Fabrix roles give on the platform | AI Fabrix roles |
| How integrators get CLI / publish access | Platform developer access |
| How Connected Systems map capabilities under roles | Configure roles and permissions |
Do not treat “business roles” and “platform roles” as two catalogs. Domain and taxonomy metadata on a role are filters — not a second list.
After install, the Role catalog is already seeded — see First session checklist. You extend the catalog; you do not invent it from empty. Roles referenced on deploy must exist in the catalog or publish fails closed — Deployment and upload.
Governance subjects
Protection and governance certification uses subject-scoped tests: a real user in a defined role. This proves boundaries for that person — not merely that an admin can connect APIs.
Common mistakes
| Mistake | Risk |
|---|---|
| Using Platform Admin for all governance tests | Certification misrepresents Role Assistant scope |
| Confusing groups with roles | Membership without business responsibility |
| Using roles to encode every data slice | Role explosion — use dimensions instead |
| Skipping active role in Role Assistant design | AI acts with ambiguous authority |
| Referencing a role on deploy that is missing from the catalog | Upload/deploy fails closed |
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 — not from API permission names. Each role should answer: what decisions can this person make, what capabilities may they request, 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. Manage the live list in the Controller Role catalog.
Example
When a Sales Manager asks a Sales Assistant to review a pipeline, AI Fabrix checks that the person is known, the Sales Manager role is active, and pipeline-related capabilities are allowed for that role — before any governed action is requested. Which deals appear still depends on dimensions and protection.
Business value
Role-based context reduces unsafe automation, aligns AI work with how the business actually operates, and makes access decisions explainable — under existing organisational authority.