Access keys and API keys

Aether has two kinds of credentials. Both go into the same Authorization: Bearer header; the server tells them apart by format.

Access keys: session credentials

aether login authorizes your machine through the browser and creates an access key tied to your account session. It expires after 60 days and carries full access to everything your account can do, including billing. Machines authorized this way are listed under Account → CLI & Devices in the dashboard, where each one can be revoked on its own.

Additional named access keys, with a lifetime you choose, are created in the dashboard under Account → CLI access keys; the default lifetime is 60 days. From the CLI you can list, rename and revoke them:

aether access-key ls
aether access-key rm ci-fallback

aether access-key add and aether access-key patch --ttl are refused from a CLI credential with 403 and code dashboard_session_required. A credential that could mint or extend credentials would outlive its own revocation, which is exactly what revoking a lost machine is supposed to prevent. aether session ls shows your active login sessions, and aether session rm revokes the sessions from a given address.

If a machine or its credentials file is lost

Revoke the machine under Account → CLI & Devices in the dashboard. aether session rm does not reach machines authorized by aether login; those are grouped by device and revoked from the dashboard only.

Revoking ends the credential’s access, and the rule above means it cannot have created another access key or API key, or extended the lifetime of one, so no second credential is waiting behind it. A credential from aether login (the browser flow) or a named key cannot have added a passkey or an authenticator app to your account, or authorized another machine, either: both take a browser sign-in session, the kind the dashboard creates. The exception is a credentials file written by the deprecated aether login --password, which holds that kind of session and, on an account without a second factor, can do both; if that is how the machine signed in, check your passkeys and authenticator app too. Any credential could still have done other things while it was valid: added a collaborator to an app, transferred an app, or read your deployment keys. Collaborator and ownership changes are recorded on the server with the IP address they came from, when it is known, so an incident can be reconstructed later; changes made before this record existed are not covered. After revoking, check your apps’ collaborators and rotate deployment keys you cannot account for.

Resetting your password is still the broadest single action: it deletes every access key on the account, sessions and named keys alike. It does not remove an enrolled passkey, so check those separately.

One caveat for keys that predate the rule. Named access keys created from the terminal before it existed carry no origin, and a stolen credential could have minted one then. They still work until they expire or you revoke them, and the server cannot tell them apart from ones you made yourself. If you ever ran aether access-key add before the rule, look through Account → CLI access keys once and revoke anything you do not recognize.

API keys: tenant credentials for automation

API keys are made for CI/CD. They start with aether_sk_live_, are shown in full exactly once at creation, and are stored server-side only as a SHA-256 hash. Listings show just the visible prefix.

Create one in the dashboard, under API Keys. From the CLI you can list and revoke:

aether api-key ls
aether api-key rm <id>

They never expire unless you give them one, and you can revoke one at any time. Fields in API responses use snake_case (key_prefix, expires_at, revoked_at).

Scopes

An API key carries one or more scopes: deploy, apps, read. All three are enforced: a key without the scope a route requires is refused.

A fourth scope, keys, used to open the API key endpoints. That is what let a leaked key mint its own replacements, so those endpoints no longer accept API keys at all and the scope grants nothing. Keys that still carry it work normally for everything else.

Assign the narrowest set that does the job.

What API keys cannot do

Billing endpoints accept only login sessions. API keys and named access keys get a 403: Billing operations require a login session. API keys and named access keys cannot access billing endpoints.

API keys cannot manage API keys, on any route. Handing out capability additionally requires a dashboard login session rather than a CLI one: creating a key, extending its expiry, or adding a scope it does not hold. Anything else, including renaming and narrowing, works from the CLI. A refusal answers 403 with code dashboard_session_required. Listing and revoking stay open to any login session, because revoking is what you reach for when a key leaks.

Which one to use

• On your machine: aether login, which authorizes the machine in your browser and manages its access key for you. Multi-factor authentication changes nothing about the command; the browser handles it.
• In CI: an API key with the deploy scope, passed as aether login --accessKey $AETHER_API_KEY. The CI/CD prerequisites page walks through it.