Personal access tokens

A Sharkly personal access token lets the CLI, a script, or another trusted client act as your user account. Personal access tokens begin with shk_ and carry the permissions available to that user.

Treat every personal access token like a password. Anyone who obtains it may be able to read or change Sharkly data that your account can access.

Choose the correct credential

Personal access tokens are for human and user-owned automation contexts. They are not used to register a computer for the local service.

Credential	Prefix	Use
Personal access token	`shk_`	Human CLI login, trusted scripts, CI jobs, and direct API requests.
Computer install token	`sit_`	One-time computer registration with `sharkly computer register --install-token`.
Agent execution credential	Supplied by Sharkly	Scoped access during an active Agent run; do not replace it with a personal access token.

A computer install token expires after 30 minutes and can be used only once. It exchanges registration authorization for an independent local-service session; it does not create a personal access token or a human CLI profile.

Create a personal access token

Open https://app.sharkly.ai/settings/tokens, or open Settings → Personal access tokens in Sharkly.

Select Create token.

Enter a name that identifies one purpose, such as Release reporting or Personal CLI.

Choose an expiration: 30 days, 90 days, 1 year, or no expiry.

Create the token and copy the full value immediately.

Store it in a password manager, secret manager, or protected CI secret.

The full value is returned when the token is created. After the creation dialog closes, the token list shows only its display prefix, creation time, last-used time, and expiration. If the full value is lost, create a replacement and revoke the old token.

The current token model does not provide token-specific scope selection. Access is limited by the permissions of the user represented by the token.

Log in to the CLI

Use the prompt-based flow so the token is not placed directly in shell history:

The CLI validates the shk_ token and saves it in the selected profile. Verify the result with:

Use a named profile when separate human CLI contexts are needed:

A profile isolates the saved token, endpoint settings, and default organization. It does not create a separate local-service instance.

Use a token in scripts

The Sharkly CLI reads SHARKLY_TOKEN. It also accepts the product-neutral APP_TOKEN fallback. An environment value takes precedence over the token saved in the active profile.

Have the shell, CI platform, or secret provider populate the variable without printing the token:

For cross-product operator scripts, use APP_TOKEN instead of a product-specific variable. Keep the organization explicit with --organization-id when the script must not depend on a profile default.

Do not enable shell tracing while a token is being injected. Commands such as set -x can copy secret values into CI logs or terminal output.

Use a token with the API

Send a personal access token as a bearer token over HTTPS:

Read the token from a protected environment variable or secret provider. Do not embed it in source code, checked-in configuration, URLs, request logs, or generated artifacts.

Store tokens safely

Create a separate token for each person, service, or automation purpose.

Prefer a defined expiration instead of no expiry.

Store tokens only in a password manager, secret manager, protected CI secret, or the CLI profile created by sharkly login --token.

Never commit tokens to Git, including test fixtures, example environment files, or past commits.

Never paste tokens into tasks, comments, Agent prompts, support messages, screenshots, or public documentation.

Do not share one personal token between users.

Avoid passing the full token as a command-line argument, where it can remain in shell history.

Use --output json for scripts, but ensure logs and error reports do not print environment variables or request headers.

Review existing tokens

Open Settings → Personal access tokens to review:

the token name and display prefix;

when it was created;

when it was last used;

when it expires;

its source, when Sharkly records one.

Last-used time is an authentication record, not a live activity signal. Use it to identify forgotten credentials, then confirm the owner before revoking a token that may still support automation.

Local logout versus server revocation

These actions are intentionally different.

Remove the token from one local profile

This clears the saved personal access token from the current profile. The server token remains valid, so another profile, script, or service that holds the same token can continue using it.

Revoke the token on the server

Open Settings → Personal access tokens, find the token by name and display prefix, and delete it. Server revocation invalidates that token for CLI, API, and automation requests wherever it is used.

Revoking a personal access token does not stop an independently registered computer's local-service session. Computer registration and human CLI authentication use separate credentials.

Rotate a token

Create a new token with a clear name and suitable expiration.

Update every approved CLI profile, CI secret, script environment, or trusted client that uses the old token.

Verify the new token with sharkly auth status or a low-impact read command using --output json.

Revoke the old token in Settings → Personal access tokens.

Confirm that expected automation continues and that the old token no longer authenticates.

Do not revoke the old token before dependent automation has received the replacement unless the old token is suspected to be compromised.

Respond to a leaked token

Revoke the token immediately in Settings → Personal access tokens.

Create a replacement only if the affected workflow still needs access.

Update all approved secret stores and CLI profiles.

Remove the token from logs, artifacts, messages, and local files where possible.

If it entered Git history, treat it as permanently exposed even after rewriting history.

Review the token's last-used time and relevant Sharkly activity for unexpected access.

Revocation is the security boundary. Deleting a local file, clearing shell history, or running sharkly auth logout is not a substitute for server revocation.

Choose the correct credential#

Create a personal access token#

Log in to the CLI#

Use a token in scripts#

Use a token with the API#

Store tokens safely#

Review existing tokens#

Local logout versus server revocation#

Remove the token from one local profile#

Revoke the token on the server#

Rotate a token#

Respond to a leaked token#