Organizations and roles
Invite-only access, two roles, and what each one can do.
Atlas is invite-only. There is no public registration path and no way to create an organization from inside the product — an Atlas operator creates yours and invites its first owner.
Everything you do is scoped to one organization: your keys, your rate limits, your usage, and your content. Nothing crosses that boundary. See Data handling.
Two roles
Member
An engineer integrating the API. Creates and revokes their own keys, sends traffic, and reads the organization's usage.
Owner
Everything a member can do, plus membership management and authority over every key in the organization.
| Action | Member | Owner |
|---|---|---|
| Send inference requests | Yes | Yes |
| Create an API key | Yes | Yes |
| Revoke a key they created | Yes | Yes |
| Revoke anyone's key | No | Yes |
| See all keys in the organization | Yes | Yes |
| See the organization's usage | Yes | Yes |
| Export usage | Yes | Yes |
| Invite a user | No | Yes |
| Change a user's role | No | Yes |
| Remove a member | No | Yes |
Two roles is the whole model. Finer-grained permissions — per-key scopes
beyond inference and read, per-model access, or per-environment separation
— are not offered. Give a service its own key and read the per-key usage
breakdown; that is the separation the platform supports today.
Inviting people
An owner invites by email and picks the role the invitation confers. The role is
carried on the invitation record, not on the acceptance: a recipient who
sends {"role": "owner"} while accepting a member invitation joins as a member.
Acceptance cannot change what was offered.
Acceptance also checks that the signed-in user's email matches the invited address, so an invitation link forwarded to a colleague does not enrol them.
An owner can revoke a pending invitation before it is accepted.
Changing roles and removing people
Owners can promote a member to owner, demote an owner to member, and remove a member.
The last owner cannot be demoted or removed. The attempt is refused with
409 and the code last_owner, and the response carries the current owner
count.
It is a 409 rather than a 403 deliberately: you do have the permission,
and the refusal stops applying the moment another owner exists. A 403 would
tell you that owners cannot demote people, which is false and would send you
looking in the wrong place.
Other refusals on this surface:
| Code | Status | Meaning |
|---|---|---|
not_a_member | 404 | No such user in this organization. |
last_owner | 409 | The organization would be left with no owner. |
unknown_role | 400 | A role other than owner or member. |
Removing a member does not revoke the keys they created. Revoke those explicitly — as an owner, you can revoke any of them. See API keys.
Rate limits are set by Atlas
Your per-model request and token limits are configured by an Atlas operator, not by an owner. If your limits are throttling legitimate traffic, that is a conversation with your Atlas contact rather than a setting to change. See Rate limits.
Audit
Membership and role changes are recorded with the acting identity and a timestamp, in an append-only log. So is every read of a diagnostic capture.