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.

Access Boundaries

Cloud access is intentionally hierarchical.

ScopeOwnsTypical decisions
OrganizationMembers, auth posture, signing keys, API keys, projectsWho can enter the workspace and which automation roots are trusted
ProjectEnvironments, drafts, versions, bundles, deploymentsWhich teams operate a product or service area
EnvironmentAgents, approvals, artifacts, replay postureWhere a deployment may run and what governance it requires

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.

Canonical Surfaces

Provenance
Need the canonical source?
Use the public hub to orient yourself, then jump to repo-owned docs or rustdoc when you need contract-level detail.