Cloud Auth and Access

ByteOr Cloud uses distinct credentials for different actors. Enrollment tokens, agent runtime keys, user access, and approval credentials should not be treated as interchangeable.

Actor Classes

Cloud uses separate credential families because the actors are different.

ActorCredentialScopeNotes
Human operatorBrowser session or API bearer tokenOrganization and project membershipBacked by the configured login flow and normal RBAC checks
Automation at the control-plane edgeOrganization API keyOrganizationUsed for automation that should not impersonate an enrolled agent
Agent bootstrapEnrollment tokenEnvironmentSingle-purpose credential used to register one agent into one environment
Enrolled agentRuntime API keyAgentUsed for heartbeats, deployment fetch, artifact upload, and signing-key refresh
Governed actionApproval credentialEnvironment + spec hash + capability scopeRequired when deployment or replay posture demands explicit approval

The important rule is separation, not convenience. Enrollment tokens are not long-lived agent secrets. Organization API keys are not substitutes for human RBAC. Approval credentials are not general API credentials.

Enrollment And Runtime Split

Agent enrollment is intentionally two-step:

  1. An environment enrollment token authorizes a one-time registration.
  2. The control plane returns a per-agent runtime API key.
  3. The agent uses that runtime key for steady-state operations.

That split lets operators revoke bootstrap access without rotating every long-lived agent secret and keeps artifact upload authorization bound to an actual enrolled node.

Approval-Aware Access

Approval-sensitive operations add another layer on top of normal RBAC. A user may be allowed to request a deployment or replay and still be blocked until the request carries a credential that matches the target environment, the relevant spec hash, and the required capability scope.

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.