Access & Automation | Ghostable Desktop

Devices, not accounts

Human access is attached to a project-scoped cryptographic device identity, not a Ghostable cloud login. The Access page lists known devices, status, environment roles, pending requests, and grants carried by the repository.

A license seat and a project device are different concepts. Licensing controls who may use the paid Desktop client; project access controls which encrypted environments a specific identity may read or change.

Human device grants and scoped Agents / Machines credentials are managed separately.

Permission model

reader: Read and decrypt values for the granted environment.
writer: Reader permissions plus environment value changes.
grantor: Reader permissions plus access-grant authority for the environment.
owner: Read, write, grant, and owner authority across the project.

Grantor and writer are intentionally separate. Give each device the smallest useful role and scope production separately from development.

Requests and grants

A new device can create a signed request for an environment and role. An authorized device reviews the request details, requested scope, device identity, and reason before approving or denying it.

Direct grants are appropriate when an approver has already verified the target identity through a trusted channel. Never grant access based only on a copied device name; verify the full device identifier or fingerprint when the risk warrants it.

Revoke and maintain access

Revocation removes a device's environment access in new repository state. Access maintenance also exposes operations for a device to leave a project and for administrators to remove public records that are already revoked.

The last owner cannot leave, preserving a path to project administration.

Agents and machines

The Agents / Machines area creates scoped automation credentials for CI, deploy systems, and other non-human runtimes. Choose the narrowest environment, role, and automation kind that can complete the job.

The returned credential is a secret. Capture it once, store it in the target platform's protected secret store, and pass it as GHOSTABLE_CI_TOKEN. Do not commit it, paste it into tickets, or reuse a human device identity in CI.

See Automation Credentials, Continuous Integration, and Deployments for engine-level examples.

Commit access changes

Requests, approvals, grants, revocations, and public device records are repository changes. Inspect the Access page and Git diff, then commit and distribute the resulting .ghostable/ state through the normal review path. Other clones do not see the new policy until they receive that commit.