AskRAI's access control model determines who can access which knowledge and what safety rules apply to their interactions. The model is built on four layers — users, roles, groups, and tenants — that combine to provide fine-grained, scalable access management without per-user configuration.
Two kinds of access
AskRAI separates administering the tenant from using its content, and the word "role" means something different on each side. Keep them apart:
| Tenant role | Resource-access role | |
|---|---|---|
| Question it answers | Who may change how AskRAI is configured? | Which knowledge and guardrails apply to this interaction? |
| Values | Platform Admin, Member | Roles you define, e.g. Employee, Public Kiosk |
| Granted to | A directory user or group, on the Access page | Groups, via mapping rules |
| Effect | Unlocks Settings | Grants knowledge packs and guardrails |
A Platform Admin can open Settings and reconfigure the tenant. A Member cannot, but still uses the console and their projects normally. This is a separate question from what content anyone can see — that is decided by groups and resource-access roles, described below, and applies to admins and members alike.
The Access Hierarchy
| Layer | What it represents | How it's managed |
|---|---|---|
| Users | Real people synced from your identity provider over SCIM 2.0, or pulled from Google Workspace | Automatic sync — admins can block/unblock |
| Roles | Usage patterns that classify interactions by channel, location, time, or device | Defined by admins with automatic mapping rules |
| Groups | Permission containers that bundle users and roles together | Created by admins, members added manually or automatically |
| Knowledge Packs | Content collections a group can search | Assigned to groups |
| Guardrails | Safety rules applied to a group's interactions | Assigned to groups |
Users
Users are real people in your organization. They are synced automatically from your identity provider — you do not create user accounts manually in AskRAI. Every synced user is a Member until an admin grants them a tenant role on the Access page — with one exception: the very first user to sign in to a brand-new tenant is automatically promoted to Platform Admin, so there is always someone who can open Settings and grant roles to everyone else. Administrators can:
- View user details (name, department, job title, contact info)
- Monitor activity (last login, active sessions, online status)
- Block or unblock user accounts
Users gain access to knowledge and guardrails through their group memberships, never directly.
Roles
The roles in this section are resource-access roles — the ones that decide which knowledge and guardrails an interaction gets. They are unrelated to the tenant roles (Platform Admin / Member) that unlock Settings.
Roles represent usage patterns rather than individual people. Each role defines mapping rules — conditions that automatically classify incoming interactions based on properties like:
| Rule type | Example |
|---|---|
| Channel | Teams, Web Chat, Mobile App |
| Location | Country, state, city, or IP range |
| Time | Business hours, after hours, weekends |
| Device | Desktop, mobile, tablet |
| Auth status | Authenticated vs. Unauthenticated |
When a user sends a message, the system evaluates mapping rules to determine which roles apply. Roles are assigned to groups, so matching a role automatically grants the user access to that group's knowledge packs and guardrails.
Roles enable dynamic access control without per-user configuration. For example, you can create a "Public Kiosk" role that matches unauthenticated web chat requests, and a separate "Employee" role that matches authenticated Teams messages — each with different knowledge packs and safety rules.
Groups
Groups are the central connection point in the access model. A group bundles together:
- Members — users and roles that belong to the group
- Knowledge packs — content collections the group can access
- Guardrails — safety rules that apply to the group's interactions
A user's effective access is the union of all knowledge packs and guardrails from every group they belong to. If a user belongs to Group A (with packs 1 and 2) and Group B (with packs 2 and 3), they can search packs 1, 2, and 3.
Group Types
| Type | How members are assigned |
|---|---|
| Manual | Administrators add and remove users and roles individually |
| Automatic | Members are assigned based on rules (e.g., by department or role category) |
Multi-Tenant Isolation
AskRAI is a multi-tenant platform. Each tenant operates in complete isolation — data, configuration, users, knowledge, and guardrails are fully separated between tenants.
From a product perspective, this means:
- Each organization gets its own independent AskRAI environment
- Users in one tenant can never see or search content from another tenant
- Configuration changes in one tenant have no effect on others
- Administrative actions (creating groups, editing guardrails, managing users) are scoped entirely to the current tenant
Tenant isolation is enforced at every layer of the platform. No tenant administrator can see or reach another tenant's data or configuration, and no configuration option shares content between tenants — every stored record and every query is scoped to a single tenant.
Multi-Channel Support
AskRAI supports multiple communication channels through the same access control model. Roles with channel-based mapping rules allow you to:
- Serve different content to different channels (e.g., public FAQ on web chat, internal policies on Teams)
- Apply stricter guardrails to public-facing channels
- Track usage and confidence metrics per channel in the Dashboard
Next Steps
- Access — grant the Platform Admin and Member tenant roles that decide who can reach Settings
- Users, Roles & Groups — manage users, create roles, and configure groups
- Knowledge Packs — create content collections to assign to groups
- Guardrails — create safety rules to assign to groups
- Governance & Audit — learn how access control ties into audit and compliance