Cloud Settings

Settings in Cloud should be understood as posture controls, not arbitrary toggles. They shape how environments behave, what approvals are required, and how operators interact with the control plane.

Central editorial page

This page is intentionally high level. Exact setting keys and implementation-specific behavior should defer to the synced Cloud docs as those surfaces stabilize.

Settings Categories

Cloud settings are split by responsibility rather than hidden behind one generic preferences page.

Surface	What it controls	Why it matters
Members	Organization and project membership	Determines who can see and operate workspace resources
Auth	Login and identity-provider integration	Controls who can enter the workspace and how sessions are issued
Signing keys	Trusted verification material	Governs approval validation and agent signing-key refresh
API keys	Organization automation credentials	Separates control-plane automation from human sessions and agent runtime keys
Environment posture	Approval sensitivity, deployment posture, replay expectations	Shapes which actions require explicit governance

The key idea is that settings are mostly posture and trust controls, not UI cosmetics. If a setting changes how credentials are issued, which approvals are valid, or how environments behave during rollout, it belongs in this part of the product.

Operational Reading Order

Start with membership and auth so the right people can reach the workspace.
Establish signing keys and API-key boundaries.
Set environment posture before enabling rollout or replay-sensitive flows.
Review deployment and incident behavior after posture is in place.

That order prevents a common failure mode where teams configure deployment automation before they have finished defining who is trusted to approve or operate it.