Cloud Workspace Access
Cloud access begins with the tenancy model. Organizations, projects, and environments define where people, agents, versions, bundles, and deployments are allowed to operate.
This page explains the public control-plane model. Use the synced Cloud docs and RBAC reference when you need the canonical operator-facing details.
Access Boundaries
Cloud access is intentionally hierarchical.
Organizations are the tenancy boundary. Cross-project access is resolved there first, which is why org admins can see and manage every nested resource.
Projects exist to separate product or team ownership without fragmenting the organization. A project admin can manage that project's environments and deployments without inheriting organization-wide security control.
Environments are where operational boundaries become real. Approval posture, deployment history, replay eligibility, and enrolled agents all resolve at the environment level. An agent enrolled into one environment does not float across sibling environments.
Practical Operator Model
- Members and identity providers are usually managed at organization scope.
- Pipeline drafts, versions, and deployments are usually managed at project scope.
- Approval-sensitive actions, enrolled agents, and incident artifacts are usually managed at environment scope.
That split is what keeps Cloud usable for multi-team organizations: broad identity and billing decisions stay high in the tree, while deployment and incident handling remain narrow and local.