Automation Credentials

Create the credential from an owner device and grant only the environments and roles the job needs:

$ ghostable access create --name github-actions --kind ci --grant staging:reader
$ ghostable access create --name production-deploy --kind deploy --grant production:reader
 

Kinds are ci, deploy, and access. They label intended use; effective access comes from the environment grants. Automation grants accept only reader or writer.

The command returns a credential token and writes its public device and grant records under .ghostable/. The token embeds that automation identity's private keys, is shown only once, cannot be recovered from the committed records, and has no built-in expiration. Store it immediately in the CI or deployment platform's encrypted secret store as GHOSTABLE_CI_TOKEN, then commit the repository changes.

Ghostable automatically loads the token from the environment:

$ export GHOSTABLE_CI_TOKEN="<secret supplied by platform>"
$ ghostable validate --env staging --json
$ ghostable deploy production --dry-run --json
 

$ $env:GHOSTABLE_CI_TOKEN = "<secret supplied by platform>"
$ ghostable validate --env staging --json
$ ghostable deploy production --dry-run --json
 

Automation credentials bypass local biometric or user-presence prompts because no user session exists. Their security therefore depends on token storage, runner isolation, and narrow grants.

• Use reader for validation, tests, process injection, and deployments that only read Ghostable state.
• Use writer only when the job must commit new encrypted values or metadata.
• Create separate credentials for CI and production deployment so either one can be revoked independently.
• Do not grant production to preview or pull-request jobs.