Work keys and management access

Two families, one account

Compute exposes two API families. They share your account and share nothing else.

Why a work key cannot administer anything

A work key holds six work scopes. Management scopes are never mintable on one, so no setting turns a work key into an administrative one.

The practical effect is worth stating plainly. A key that leaks, or an agent that goes further than you meant, can spend inside bounds you already approved. It cannot register a destination, mint another key, change spend authority, or touch an invoice.

Finance, destination, and identity administration stay disjoint from work submission by design. That separation is the reason a work key is safe to hand to an automated caller in the first place.

The five work tools

An agent connected over MCP gets exactly five tools. There is never a sixth.

• lithi.quote — price a task. It authorizes nothing.
• lithi.run — submit one approved task.
• lithi.batch — submit many items as a single unit.
• lithi.status — read the current state of a job.
• lithi.result — fetch the finished result bundle.

lithi.plan() and lithi.recommend() are local helpers. They neither quote, admit, nor run paid work, and they are not part of that set.

The management lifecycle

Every management resource family follows the same steps, from your organization record through to audit and receipts.

1. Describe — read what the resource type supports.
2. Inspect — read the current state.
3. Plan — produce the change as a reviewable plan with a digest.
4. Approve — where your organization requires approval for that change.
5. Apply — execute the approved plan.
6. Read back — confirm the applied state from the record, not from the response.
7. Events — follow what happened afterwards.
8. Revoke — withdraw the grant once it is no longer needed.

Re-applying an identical change returns its earlier verified result rather than doing the work twice. The exact operations each family supports are listed in the management API reference.

"Rollback" means applying a new plan. It never means undoing an invitation that was sent, an external write that landed, or a payment that moved.

Where the boundary shows in the namespace

lithi.work.quote/run/batch/status/result
lithi.identities/api_keys/approvals/spend
lithi.data.sources/destinations
lithi.finance.mappings/cost_allocation/statements/invoices/payments/reconciliation

Only the first line is reachable with a work key. The invoice and payment family has no debit operation at all. It lists, exports, opens a hosted payment action, and reads status back.

Check your own key

Roles decide what a person can plan and approve; scopes decide what a key can submit: scopes and roles.