> ## 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: Compute scopes and roles
description: >-
  What each Compute credential can hold, and what it can never hold. Work,
  configuration, delivery, identity and finance grants stay separate on every
  role.
route: /docs/compute/access/scopes-and-roles
page_id: docs-compute-access-scopes-and-roles
page_type: reference
content_layer: technical reference
surface_profile: technical_reference
audience: Administrators and integrators mapping Compute grants to their own roles
voice: D
reader_question: Which grants does each Compute credential hold?
primary_action: Define a service identity
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-access-scopes-and-roles-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"
---

## The two grant families

| Family | What it covers | How it authenticates | Where it is available |
|---|---|---|---|
| Work | quote, run, batch, status, result | A bounded personal, service or automation work key | REST, SDK, CLI and exactly five MCP tools |
| Management | Organization and projects, members and roles, identities and keys, sources and destinations, profiles and rubrics, schedules and webhooks, finance and invoices, audit and receipts | A human portal session, or a separately admitted management service identity | REST, SDK, CLI and the portal, with no MCP work-tool expansion |

A work key holds six work scopes. Management scopes are never mintable on a work key.

## Credential to grant matrix

Your organization names its own roles. This table describes what a credential can carry, not what you called it.

| Grant area | Work key | Portal session with administration authority | Management service identity |
|---|---|---|---|
| Work submission | Yes, within its six scopes | No | No |
| Configuration and profiles | No | Yes | Only where explicitly granted |
| Sources and destinations | No | Yes | Only where explicitly granted |
| Identities and keys | No | Yes | Only where explicitly granted |
| Spend and approvals | No | Yes | Decide only where explicitly granted |
| Finance, statements and invoices | No | Yes, with no debit operation | Only where explicitly granted, with no debit operation |
| Audit and receipts | Reads its own results only | Yes | Only where explicitly granted |

A management service identity can only narrow the authority of its current human owner. It can never hold a grant that owner does not.

## Management resource families and their operations

| Family | Minimum operations |
|---|---|
| Organization and account | describe, get, plan/update, read-back |
| Projects and subaccounts | list, get, plan, create, update, archive, read-back |
| Members, invitations and grants | list, get, plan, invite, grant, suspend, remove, read-back, events |
| Identity sync and role mappings | describe, plan, apply, pause, revoke, read-back, events |
| Personal, service and automation identities and keys | plan, create, rotate, revoke, read-back; plaintext once only |
| Spend and approval | get, plan, apply, request, decide, expire, read-back |
| Sources and credentials | describe, list, get, plan, register, test, revoke, read-back; secret reference only |
| Destinations and delivery | describe, list, get, plan, register, test, revoke, read-back, events |
| Workflow profiles and rubrics | describe, list, get, plan, create, version, retire, read-back |
| Schedules and webhooks | describe, list, get, plan, apply, pause, resume, replay, revoke, read-back, events |
| Finance and cost allocation | describe, list, get, inspect, plan, apply, export, reconcile, read-back |
| Statements, invoices and payment | list, get, export, open-hosted-action, read-status, reconcile; no debit operation |
| Audit and receipts | list, get, with stable cursors and content-free projections |

## Separation rules

- Finance, destination and identity administration stay disjoint from work submission.
- No management family carries a debit operation. Compute never takes money from an account.
- A profile may narrow a ceiling, a deadline, a data profile or an output scope. It may never widen one.
- An override that would widen a higher grant is refused with a reason and a next action.
- Approving spend permits work to be admitted. It never authorizes a payment.

## The shared lifecycle

Every management family follows the same sequence:

```text
describe -> inspect -> plan -> approve as required -> apply -> read back -> events -> revoke
```

Rollback never implies undoing an invitation, an external write or a payment. Those are reversed, where they can be, by a forward act with its own record.

## Reading a grant back

Every response carries an envelope. It names a `request_id`, the operation, the contract release, the typed state, an evidence class, an `observed_at` time and a `valid_until` time.

A read older than its `valid_until` is stale. Read it again rather than treating it as current.

Per-resource apply states are `PLANNED`, `WAITING_APPROVAL`, `READY`, `APPLYING`, `APPLIED_UNVERIFIED`, `VERIFIED`, `ALREADY_MATCHED`, `REFUSED`, `CONFLICT`, `RETRYABLE`, `REVOKED` and `ROLLED_BACK`. The change as a whole returns `COMPLETE`, `PARTIAL_WITH_NEXT_ACTION`, `REFUSED` or `EXPIRED`.

## Where the exact names live

Scope names, role names and per-operation error schemas are generated per release. There is no single global error-code table; every operation carries its own `error_schema`.

Read the current names on the key when you create it, in the portal, and in the OpenAPI description you download. See [the management API reference](/docs/compute/reference/management-api) for the operation shapes.

[Define a service identity](/docs/compute/access/service-identities)