Resource Hierarchy And Roles
AI Cloud is organized so access, cost, ownership, support, and cleanup can be understood from the product without direct operator help.
Hierarchy
Some environments show department or billing-unit fields only to admins. Even when that field is hidden from a user, every runtime should still belong to a project with a clear owner and billing or quota policy.
What Each Layer Owns
| Layer | Owns | User-visible impact |
|---|---|---|
| Platform | Regions, capacity pools, runtime families, shared services, security boundary. | What can be launched and where. |
| Tenant | Workspace, tenant admins, policy defaults, billing posture. | Who can administer the workspace. |
| Department or billing group | Cost-center or organizational attribution when enabled. | How spend is reported internally. |
| Project | Workload ownership, project members, service accounts, quota, storage references. | Where users launch and where usage lands. |
| Runtime | Compute, app, notebook, scheduler, or endpoint instance. | What the user connects to and pays for while active. |
| Storage | Buckets, project data, model cache, workspace mounts. | What data a workload can read or write. |
| Identity | Users, service accounts, SSH keys, API keys, sessions. | Who can access or automate work. |
Project Context Rule
Before launching or mutating anything, verify the selected project. Project context decides:
- who can see the resource;
- who can connect to it;
- where spend is attributed;
- which quota and entitlement apply;
- which service accounts and storage references are available;
- which admin should help if the flow is blocked.
Roles
Role names can vary by environment, but the operating model is consistent.
| Role posture | Typical authority | Common tasks |
|---|---|---|
| Viewer | Read-only project or tenant visibility. | Inspect workloads, usage, catalog, or handoff state. |
| Member | Normal project user. | Launch allowed work, connect to owned runtimes, release work. |
| Project admin | Project-level ownership. | Manage project members, service accounts, quota requests, and handoff. |
| Tenant admin | Tenant-wide administration. | Manage projects, tenant members, policy posture, stale access, recovery. |
| Platform operator | Platform and provider operations. | Capacity, node enrollment, release repair, deploy, provider-backed incidents. |
Use the narrowest role that can finish the task.
Service Accounts
Service accounts are for automation. They should have:
- a project or tenant owner;
- a named purpose;
- only the required role;
- credential rotation;
- last-used review;
- a cleanup owner.
Do not use shared human accounts for automation.
Resource Ownership Checklist
Before a project is handed to users:
- Tenant name is correct.
- Project name describes the work.
- Project owner is known.
- Members and roles are reviewed.
- Service accounts are scoped.
- Billing group or cost attribution is correct where enabled.
- Quota and entitlement match the intended workload.
- Storage ownership is clear.
- Support owner and escalation path are known.
What To Do When Access Looks Wrong
| Symptom | Likely owner | First action |
|---|---|---|
| Tenant missing after sign-in | Tenant admin | Confirm membership or invitation. |
| Project missing | Tenant admin or project owner | Grant project membership. |
| Launch button disabled | Tenant admin | Check role, quota, entitlement, and billing posture. |
| Connect action missing | Project owner or support | Confirm runtime state and role. |
| Service account cannot act | Tenant admin | Review scope, role, credential age, and project context. |
| Cost appears in wrong place | Tenant admin or billing owner | Confirm selected project and billing group mapping. |
For blocked states and evidence packets, use Troubleshooting Playbook.