> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Authenticate a Compute client
description: >-
  Compute releases work keys, human portal sessions and management service identities. Learn
  which one your client needs, how to store it safely, and how to confirm the account it
  resolved to.
route: /docs/compute/access/authentication
page_id: docs-compute-access-authentication
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Developers and agent operators connecting a client to Compute
voice: D
reader_question: Which credential does my client use, and how do I know it resolved to the right account?
primary_action: Create, rotate and revoke API keys
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-access-authentication-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## Before you start

You need an account, a member role, and a decision about what this client will do. That last part chooses your credential for you.

If the client submits work, it needs a work key. If it changes configuration, it needs management authority, and those are never the same credential.

## Choose the released credential

Four credential kinds are released today. Each authenticates a different actor.

| Credential | Who or what it authenticates | What it can never do |
|---|---|---|
| Personal work key | One named person's own submissions | Administer accounts, identities, destinations or finance |
| Service or automation work key | One agent, script or scheduled automation | Anything outside its six work scopes |
| Human portal session | A signed-in member, in the portal | Expand the work tool set or bypass an approval |
| Management service identity | One automation doing administration | Hold more authority than the person who owns it |

A work key holds six work scopes and nothing else. Management scopes are never mintable on a work key, so no rotation, no re-issue and no support request converts one into the other.

## Set up your credential store

Store the secret in your operating system credential store or your team's secret manager. Give the client a reference to it.

Never place a secret on a command line, in a committed file, in a log line, or in a message to support. Support will never ask you for one.

Your base URL and current API version appear in the portal under developer settings, and in the OpenAPI description you download. Do not hard-code values copied from an example.

## Confirm the selected account

A credential that works is not proof it is the credential you meant. Check which account it resolved to before your first real submission.

```bash
lithi doctor
```

Then read the response envelope on any call. It carries a `request_id`, the operation, the contract release, the typed state, an evidence class, an `observed_at` time and a `valid_until` time.

If `valid_until` has passed, the read is stale. Read again rather than trusting it.

## Know how each surface differs

The three surfaces authenticate the same identity in three different shapes.

A REST call is stateless. Every request carries the credential, and nothing is remembered between calls.

An MCP session authenticates once, then stays open. It exposes exactly five work tools: `lithi.quote`, `lithi.run`, `lithi.batch`, `lithi.status` and `lithi.result`.

Local helpers such as `lithi.plan()` and `lithi.recommend()` run beside those five. They neither quote, admit nor run paid work, so they never spend anything. Check [what a work key can hold](/docs/compute/access/scopes-and-roles) if you expected a sixth tool.

A portal session authenticates a person, in a browser, for management work. It never gains work tools, and a work key never gains portal authority.

## Confirm success

`lithi doctor` reports the account you expected. One small status call returns an envelope naming that account and a current `valid_until`.

If the account is wrong, your client picked up a different stored credential. Fix the reference rather than issuing a new key.

## When authentication refuses

A refusal names a safe reason and a concrete next action, and the two belong together.

An expired or revoked credential needs a new one; issue it deliberately rather than reusing an old secret. A credential that is valid but lacks the scope refuses on authority, and the fix is a grant, not a retry.

`CANONICAL_ADMISSION_LIMITED` means the key or account is not authorized to make that request. Check the scope before you assume a service problem.

[Create, rotate and revoke API keys](/docs/compute/access/api-keys)