Access Control (RBAC)
ANTS Platform controls access with roles. Each member holds a role in the organization and can hold a different role in a project. A role is a set of access levels across the product's modules. The platform turns those levels into permissions and checks them on every request.
Roles are managed in the app, not through an SDK. Assign them under Organization Settings → Members and Project Settings → Members. Build your own under Organization Settings → Custom Roles (Enterprise).
The model
| Concept | What it is |
|---|---|
| Membership | A person's link to an organization (organization role) and, optionally, to a project (project role). |
| Role | One of eight built-in roles (Owner, Department Admin, Security & Compliance, Cost Analyst, Manager Viewer, End User, Auditor, None) or an organization-defined custom role. |
| Module | An area of the product: Discover AI, AI TrailMaps, Gauge AI, Governance, Budget AI, Audit & Export, PII / raw-prompt content, Data export, User data export, AI Agent data export, User & role management, Custom-role authoring, Integrations & service accounts, Tenant security & data retention, Billing & subscription, Ants Assist. |
| Sub-module | A page or settings surface inside a module, for example Risk Dashboard inside Governance or Keys inside Budget AI. |
| Access level | No access, Read, Read & Write or Admin. Each module and sub-module offers only the levels that apply to it. |
A sub-module inherits its module's level unless a custom role sets it explicitly. Built-in roles set module levels only, so every page in a module follows the module.
Organization and project scope
- The organization role grants organization-wide settings and the default access to every project.
- A project role replaces the organization role inside that project, in either direction.
- A member whose organization role is None sees only the projects where they hold a project role. This is how you give an external auditor access to one project.
- Organization-level views that span projects, such as Audit Logs, show a member only the projects they can access.
Project roles need the rbac-project-roles entitlement. See Members & Roles.
Built-in roles at a glance
| Module | Owner | Department Admin | Security & Compliance | Cost Analyst | Auditor |
|---|---|---|---|---|---|
| Discover AI | Full | Read & Write | Read | Read | - |
| Gauge AI | Full | Read & Write | Read | Read & Write | - |
| Governance | Full | Read | Admin | - | Read |
| Budget AI | Full | Admin | Read | Read | Read |
| Audit & Export | Full | - | Read & Write | - | Read |
| PII / raw-prompt content | Read | - | Read | - | - |
| User & role management | Full | Read & Write | - | - | - |
| Tenant security | Admin | - | Admin | - | - |
Manager Viewer and End User have no module access. The full matrix, including settings tabs, is on Members & Roles.
Agent ownership
Ownership of an AI agent adds access on top of a role, for that agent only. A member who owns an agent but whose role does not include AI Agent Center, Tracing & Sessions or the Gauge AI dashboards, such as End User, sees those pages with data from their own agents only, including their agents' prompt and response content. Ownership never narrows a role: a member whose role already includes a page keeps the full view.
Assigning owners is member management: it needs userRoleManagement.projectMembers:write and the content permission, so among the built-in roles only Owner can do it. Nobody can grant ownership that gives more access than they hold, and only an Owner can make themselves an owner. Owner changes are written to the audit log. See Agent owners.
Agent tool governance
An agent's tool permissions, approvals and behaviour settings follow the Agent Profiles & Drift permission under Governance: Read to view them, Read & Write to change them and to approve or deny tool calls. Among the built-in roles, Owner and Security & Compliance can change them. Nobody can decide an approval request made for themselves.
Prompt and response content
The text of prompts and responses is protected by its own gated permission, PII / raw-prompt content. It covers trace and session input and output, observation bodies, and the flagged content behind AI Violations. Dashboards, counts, trace lists and violation summaries do not need it.
Among the built-in roles only Owner and Security & Compliance hold it. In a custom role it is marked Sensitive, and it cannot be combined with data export.
Separately, the Trace input and output feature switch under Organization Settings → Features hides prompts and replies for everyone in the organization or in selected projects. See Data Privacy.
Separation of duties
The platform prevents one person from holding duties that are meant to check each other:
- Custom roles cannot combine user and role management with audit log access, user and role management with tenant security administration, or prompt content with data export. The role editor explains the conflict and refuses to save.
- No self-escalation: nobody can grant a role that includes permissions they do not hold, and only an Owner can change their own role.
- Custom-role authoring is Owner-only and can never be granted through a custom role.
- The built-in roles follow the same split: Department Admin manages people but has no audit log, prompt content or tenant security access. Security & Compliance administers security but cannot manage members.
Enforcement and audit
- The sidebar and settings tabs only show what a role grants, but the decision is made on the server. Every API call checks the caller's permissions, and a refused call is logged.
- Sensitive changes (changing roles, creating or editing custom roles) require step-up verification.
- Membership changes, invitations, role changes, custom role changes and access to sensitive settings pages are written to Audit Logs.
- Some pages also need a plan entitlement or a feature to be enabled, whatever the role. See Billing & Plans.