Access in AI Grid is always a grant on a specific thing: this organization, this team, this project. There is no role that silently reaches downward — an organization role does not open every project inside it, and team membership grants no project rights of its own.
The shape of it#
| Level | Roles | What they govern |
|---|---|---|
| Organization | Owner, Administrator, Viewer, Finance Administrator | membership, structure, settings, funding, assignments |
| Team | Team Owner, Team Member | the team itself and the projects it owns |
| Project | Project Owner, Project Consumer, Project Viewer | building, calling and watching one project |
The set is fixed — there are no custom roles. Alongside these sits one platform-level role, Platform Administrator, held by the AI Grid operator. It manages organizations, identity and the product review queue; it is not an organization role and never appears in your member list.
Organization roles#
| Role | Can |
|---|---|
| Owner | everything an Administrator can, plus funding project wallets (top-ups). The founding and ultimate authority |
| Administrator | day-to-day administration: members and invitations, teams and projects, product assignments and consumer grants |
| Viewer | read-only on the organization |
| Finance Administrator | read access plus commercial requests tied to supplier settlement |
Two boundaries are deliberate and catch people out:
- Funding and spend policy are Owner-only. An Administrator can manage members, teams, projects and assignments — but cannot top up a project wallet, and cannot create or edit invocation policies (the organization-wide spend and guardrail ceilings). Both belong to the Owner. See Wallets and credits.
- Administration is not consumption. An Owner or Administrator who holds no project grant cannot call a model. Management authority never substitutes for a consumption grant.
Ownership is never handed out by invitation: an invitation can carry any other organization role, and an existing Owner promotes a member after they have joined.
Team roles#
| Role | Can |
|---|---|
| Team Owner | administer the team: its members and the projects it owns. A team keeps exactly one owner — promoting a member transfers ownership and steps the previous owner down to member |
| Team Member | belong to the team and see its projects. Nothing more |
A project belongs to exactly one team (its owning team), and that ownership matters: it is provenance, and it is a precondition for issuing API keys. But it is not access — a Team Member of the owning team can see the project listed, and cannot call anything, until a project grant says otherwise.
Project roles#
Project access is an explicit grant on one project, recorded with a reason, and added or removed by an organization Owner or Administrator. Each grant names one member and one role:
| Role | Carries project.invoke? |
Can |
|---|---|---|
| Project Owner | yes | build and administer the project, and call its assigned products |
| Project Consumer | yes | call the products assigned to the project |
| Project Viewer | no | read-only on the project |
Only roles carrying project.invoke can spend. A Viewer, or a member of the owning team with no
project grant, sees the project and cannot invoke. Removing a grant refuses the member's next
call at once; their other projects are untouched.
Who may issue an API key#
Issuing a durable credential is a stronger act than spending through your own session, so the rule is stricter than the consumption rule. To create a key for a project you must hold, all at once:
- an active membership of the organization,
- an active grant on the project's owning team (Team Owner or Team Member), and
- an active project grant carrying
project.invoke(Project Owner or Project Consumer),
confirmed by the platform's authorization adapter. Anything less is refused with
403 key_issuer_denied. Organization administration does not substitute, and a project that has
no owning team cannot have keys until one is assigned.
The same rule is re-evaluated on every use of the key — revoking the creator's team or project grant, or suspending the person, the organization or the project, stops the next call. The details are on API keys.
What is deliberately absent#
- No custom roles. The set above is the set.
- No downward inheritance. An organization role never becomes project access; a team grant never becomes a consumption right.
- No nested teams. Teams contain people; projects belong to exactly one team.
Next#
- API keys — project-scoped credentials and their limits
- Tenancy and isolation — the boundary these grants live inside
- Organizations, teams and projects — the structure itself