Account and access
Which account and key to use for Compute work, and how to check what each key can and cannot do before your agent starts.
Identify the account and grant
Start with the account that owns the customer work and the identity assigned to it. If you work alone, use your approved personal account. If you work on a team, use your current membership and grant. Providers use the separate Lithi Connect path; provider authority does not become customer Compute authority.
You choose the account and identity your agent may use. Before work starts, confirm that the current membership or grant permits the action you want to take.
Keep the account owner, administrator, person, service identity, customer principal and provider identity distinct. A display name, email domain, project label or key name helps you check the context, but it does not create ownership or authority.
Confirm that the person or service has the grant needed for the next action. Compute separates permission to submit work from permission to administer an account. A work credential can be allowed to quote, run or read work, but it cannot:
- invite teammates;
- rotate somebody else's key;
- change billing settings;
- increase spending limits;
- enroll provider Macs;
- make a payment.
See Scopes and roles for the exact permission model and Authentication for the released credential paths.
Review the current limits
Review the current account, key, member, batch and per-job limits together. The narrowest applicable boundary controls.
A quote still defines the exact work and maximum charge. An account limit is not a quote, a quote is not approval, approval is not execution, and execution is not payment.
If a limit read is unavailable, leave it unresolved. An empty view does not mean zero usage or permission to submit without a confirmed capacity limit.
Use a credential with only the scopes needed for the task.
For example:
- A client that only reads status does not need write scopes.
- A reporting automation can use reporting authority without gaining job execution authority.
- A billing reader does not need customer-work permission.
Keep secrets in the supported protected store. Never put raw keys, sign-in codes, private paths or account tokens in a prompt, issue, screenshot or support message.
Review team access separately
Team membership and work-key scopes are separate systems. Review each person or service through its actual current grant.
When a teammate leaves or a service changes owner, revoke the affected access and read back the result. Revoking a key does not erase accepted work, delete a result or cancel an invoice.
Connect after these checks
Once you know the account, identity, grant and applicable limits, set up Compute or connect a client. If a credential is missing or rejected, use Account or API key help.
What if I don't have a key yet?
If you don't have approved access, apply for Compute API access. Once access is approved, an account administrator can help you use the offered API key creation flow. Choose the permissions needed for your client, then confirm it can make a permitted read. A key doesn't fund or approve paid work; review invoices and payment when you're ready to fund the account.