Roles and permissions#

Look up the roles in ATLAS and what each one can do. For how roles fit together, see Identity and access concepts and Organisations.

At a glance

Roles exist at three levels: the organisation, a space and a project.
Roles stack. A person's permissions are everything every role they hold allows.
Each person has one base role in the organisation (Owner, Admin or Member). They can hold extra roles (Account Manager, Auditor) on top.
Owners and Admins can manage every space and project in the organisation without being members of them. An API key is the exception: its acting context needs explicit membership.
Roles are managed in ATLAS or taken from your identity provider's groups.

Roles#

Level	Role	Description
Organisation	Owner	Everything an Admin can do, plus assigning roles and transferring ownership. Every organisation has exactly one.
Organisation	Admin	Runs the organisation: people, settings, providers, models, spaces, projects, budgets and API key oversight.
Organisation	Member	Base role. Uses the models that spaces and projects give access to.
Organisation	Account Manager	Additional role. Administers all projects, their funding and keys, and reads usage and billing. Manages project members, not organisation members.
Organisation	Auditor	Additional role. Reads the audit log, prompt and response payloads, and usage, but not billing.
Space	space manager	Manages that space and everything below it.
Space	space member	Uses the space's models and budget. Can point a personal key at the space (Team spaces only).
Project	project manager	Manages the project's members, settings, keys and statements.
Project	project member	Uses the project's models. Can point a personal key at the project.

Rules that apply to every role:

A person belongs to one organisation only.
Owners and Admins count as managers of every space and project in their organisation. This stops at the organisation boundary.
The last Owner of an organisation and the last manager of a space cannot be removed or demoted.
Projects have no last-manager rule. A project's only manager can be demoted or removed, and Admins, Owners and Account Managers can still manage the project.
The root Organisation space has no members of its own and cannot be deleted.
A person with the Owner or Admin base role also has everything a Member can do.
When your organisation takes roles from ATLAS and the person's email domain is registered, a first sign-in makes them a Member.

What each role can do#

Organisation roles#

Role	Can do
Member	View the organisation's providers, models and members. See the projects they belong to. Use spaces they are a member of.
Admin	Everything a Member can do. Manage members and organisation settings. Add and configure providers and models. See and revoke any API key. View usage and billing. Create, edit, fund and delete any project, and manage its members, models, settings and keys.
Owner	Everything an Admin can do, plus: assign roles and transfer ownership.
Auditor	Search the audit log, read prompt and response payloads, and view organisation usage.
Account Manager	Create and edit projects, manage their members, models, settings and keys, fund projects and read statements, and view usage and billing. Cannot delete projects or reveal a project key.

Space roles#

Role	Can do
space member	View the space, its members, environment variables, budget and their own keys acting in it. Admins and Owners see every key.
space manager	Everything a space member can do, plus: create child spaces, edit or delete the space, manage its members and environment variables, view its usage, and set the budget and model restrictions of the spaces below it.

Project roles#

Role	Can do
project member	View the project, its members, model list, settings, funding, usage and keys.
project manager	Everything a project member can do, plus: manage members, edit the project and its AI settings, create and revoke project keys, and read statements.

Funding a project, changing its model list, deleting it and revealing a project key stay with Admins, Owners and (for funding and models) Account Managers. Project managers cannot do these.

A space's own budget and model restrictions are set from above, by a manager of a higher-level space or by an Admin or Owner. A space manager cannot change their own space's limits.

Everyone#

Every signed-in person can:

Edit their own profile.
Create and revoke their own API keys.
View their own usage and audit entries.
Choose which space or project their key acts under.

Where roles come from#

Each organisation chooses a role source.

Role source	How roles are set
ATLAS (default)	Owners and Admins assign roles in the web app.
Identity provider groups	Roles follow the groups a person belongs to in your identity provider. Roles are locked in ATLAS while this is on.

When roles come from groups, you map group IDs to ATLAS roles. For the steps, see Map Entra groups to roles.

Rule	Detail
Required mappings	Map at least one group to Admin and one to Member.
Optional mappings	Account Manager and Auditor can be mapped too.
Owner	Cannot be mapped. Group membership never changes the Owner.
Several matches	Admin wins over Member.
Group IDs	Use the identifier your provider issues. IDs are case-sensitive. Renaming a group changes nothing.
Nested groups	Not evaluated. Add people to the mapped group directly.
No mapped group	The person is suspended with the reason shown below. A new person cannot sign in.
Too many groups	If your provider omits the group list because the person is in too many groups, the person is suspended until the list can be read.
When changes apply	At the person's next sign-in. When you switch to groups, people see "Sign in again to apply your roles" until they do.
Recovery	A suspension for a missing mapped group lifts automatically once a mapped group returns.

Suspended members#

A suspended member keeps their data, but cannot sign in, and their personal API keys stop working. Project keys keep working because they belong to the project. Audit, usage and billing history do not change.

Reason shown	Cause
Violation of terms, Security concern, Offboarding, Other	An Admin or ilionx suspended the person. A reason is required.
Domain removed	The person's email domain was removed from the organisation. Adding exactly that domain again restores them.
No upstream role	Roles come from your identity provider and none of the person's groups is mapped.
Group overage (identity provider sent too many groups)	The provider omitted the group list because the person is in too many groups.
Deactivated in identity provider	Your directory deactivated the person (SCIM). Reactivating them there lifts it.
Not provisioned by the organisation's identity provider	Sign-in is limited to provisioned people and your directory did not provision this person.
Seat limit exceeded	The organisation went over its seat limit. Free a seat, or ask your ilionx contact to raise the limit.

The Owner cannot be suspended. Transfer ownership first.
Admins cannot suspend themselves.
Resuming a person is refused while your seat limit is full.
When provisioning from your directory is on, Admins cannot resume members whose suspension came from the directory.

Provisioning from your directory (SCIM)#

If your organisation uses System for Cross-domain Identity Management (SCIM), your identity provider creates, updates and removes people in ATLAS automatically. Ask your ilionx contact to turn it on for your organisation. Then configure your provider with the values ATLAS gives you. For the steps, see Provision members with SCIM.

Item	Detail
Who is provisioned	Only people with an email on a verified organisation domain, while seats last.
Owner	Cannot be deactivated or deleted through SCIM.
Directory-only	You can limit sign-in to people your directory provisioned.
Departing people	Project keys they created keep working. Revoke or reassign them.
Supported provider	Tested with Microsoft Entra ID.