> ## 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: Define a service identity
description: >-
  A service identity needs a current human owner, a project, a workflow, its destinations, an
  expiry and a budget. Offboarding a person and transferring an identity are different acts.
route: /docs/compute/access/service-identities
page_id: docs-compute-access-service-identities
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Administrators giving an automation its own Compute credential
voice: D
reader_question: What must be in place before an automation gets its own Compute credential?
primary_action: Invite people to your Compute account
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-access-service-identities-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 administration authority, one automation that has a job to do, and a person willing to own it. A service identity without a named owner is an orphan waiting to happen.

Register the sources and destinations it will use first. An identity is easier to scope once you know exactly what it touches.

## Require all six facts

A service identity is not defined until all six of these are recorded. Missing one is how a credential outlives its purpose.

1. A current human owner, who answers for what this identity does.
2. A project, so its spend and its results belong somewhere.
3. A workflow, so its work is bounded to what it exists to do.
4. Its destinations, named explicitly rather than inherited.
5. An expiry, after which it stops rather than continues.
6. A budget, so it cannot outspend its purpose.

Set the expiry to the period you would actually review, not the longest one you can. A distant expiry is a review you have quietly decided to skip.

## Register it like any other resource

The identity family follows the same lifecycle as everything else. Plan the identity, create it, then read it back before anything uses it.

The plaintext secret is revealed once, during protected setup. Store it immediately; it cannot be retrieved later.

Confirm the read-back shows the owner, project, workflow, destinations, expiry and budget you intended. A missing field here is a missing control in production.

## Keep it narrower than its owner

A service identity can only narrow the authority of the person who owns it. It never holds a grant its owner does not.

That has a consequence people miss. When the owner's own authority is reduced, the identity is reduced with it, and work that relied on the wider grant starts refusing.

A work automation gets a work key. An administration automation gets a management service identity, admitted separately. See [what each grant can hold](/docs/compute/access/scopes-and-roles) before you choose.

## Offboarding is not a transfer

Removing a person and transferring an identity are two different acts with different consequences. Doing one does not do the other.

Removing a member suspends and removes their own grants. It does not reassign the service identities they owned, and it does not stop those identities running.

An identity whose owner has left has no current human owner. Transfer it to a named owner, or revoke it. Do not leave it running while you decide.

Plan the transfer, apply it, then read the identity back and confirm the new owner is recorded. The events should show the change with a time you recognize.

## Confirm success

The identity reads back as `VERIFIED`, with the owner, project, workflow, destinations, expiry and budget you set.

One real submission from the automation succeeds. One submission outside its workflow or its budget refuses. If both succeed, the scope is wider than you think.

## When it expires or refuses

An expired identity refuses with a reason and a next action. That is the control working, not a fault.

Renew it deliberately, as a decision, after checking the automation still needs the same scope. Renewal is a good moment to narrow something.

`CANONICAL_BUDGET_EXHAUSTED` means the identity's budget is used up, not that it lost authority. `CANONICAL_ADMISSION_LIMITED` means it is not authorized to make that request at all, which is a grant problem.

[Invite people to your Compute account](/docs/compute/access/team-invitations)