> ## Documentation Index
> Fetch the complete documentation index at: https://docs.modular.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles and permissions

> Review the different user roles and the permissions scoped to them

Each member of your organization needs to be assigned a role that grants them
some level of permissions. This page describes what roles exist and how to
assign users the appropriate roles.

[Set up roles in the console →](https://console.modular.com/members)

## Manage user roles

Users with the `Owner` or `Admin` role can assign roles from the
[Members](https://console.modular.com/members) page.

You can assign a role in either of the following ways:

* **When inviting a user:** Select a role before sending the invitation.
* **After a user has joined:** Click **Update** for the user's entry and choose
  a new role.

Role changes take effect immediately. Updated permissions apply to the user's
next request, including requests made as part of an existing session.

Every role change is recorded in the
[Activities](https://console.modular.com/activities) log, including the user who
made the change, the affected member, the previous role, the new role, and the
time of the update.

## Roles and permissions matrix

| Permission                                                         | Owner | Admin | Developer | User |
| ------------------------------------------------------------------ | :---: | :---: | :-------: | :--: |
| View deployments, endpoints, models, and usage                     |   ✓   |   ✓   |     ✓     |   ✓  |
| Run inference on any resource                                      |   ✓   |   ✓   |     ✓     |   ✓  |
| Create and manage your own API keys                                |   ✓   |   ✓   |     ✓     |   —  |
| Manage organization API keys and keys owned by other members       |   ✓   |   ✓   |     —     |   —  |
| Invite, change role, and remove members (except the Owner)         |   ✓   |   ✓   |     —     |   —  |
| View and manage billing (payment methods, plan, credits, invoices) |   ✓   |   ✓   |     —     |   —  |
| Accept Terms of Service and legal agreements                       |   ✓   |   —   |     —     |   —  |
| Transfer ownership                                                 |   ✓   |   —   |     —     |   —  |

Each API key also carries its own access scopes, which further limit what the
key can do. For more information, see [API keys](/administration/api-keys).

### Owner

The Owner, also called the Org Admin, has the highest level of access. Each
organization has exactly one Owner. By default, the first person who signs up
for an organization becomes its Owner.

Only the Owner can accept the Terms of Service and other legal agreements for
the organization. The organization can't purchase credits or run production
inference until the Owner accepts these agreements.

The Owner can also manage billing and transfer ownership to another member. When
ownership is transferred, the previous Owner becomes an Admin or receives
another selected role. An Owner can't remove or change their own role without
first transferring ownership.

### Admin

Admins manage the organization's day-to-day operations. They can manage billing,
invite and remove members, assign roles, and manage organization API keys along
with keys owned by other members.

Admins can't remove the Owner or change the Owner's role. Assign this role to
team leads who need broad operational access.

### Developer

Developers can run inference and create, view, and revoke their own API keys.
They can't view or manage organization API keys or keys created by other
members.

Developers can't access billing or manage members and roles. Assign this role to
engineers and machine learning practitioners who build on the platform.

### User

Users can view organization resources and usage data. They can also run
inference.

Users can't create, edit, or revoke API keys, access billing, or manage members
and roles. Assign this role to people who use your inference endpoints but don't
need broader access.