> ## 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: Credentials and short-lived federation description: >- Register a source once so Lithi holds a reference instead of a secret, prefer short-lived authority where your provider offers it, and rotate or revoke safely. route: /docs/compute/security/credentials-and-federation page_id: docs-compute-security-credentials-and-federation page_type: howTo content_layer: guided documentation surface_profile: guided_docs audience: Integrators connecting a source or destination to Compute voice: D reader_question: How does Compute reach my systems without me handing over a secret? primary_action: Register a source source_locale: en-US source_status: APPROVED source_version: docs-compute-security-credentials-and-federation-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 Decide what Compute actually needs: a way to read one source, or a way to write one destination. Both are registered once, as references. Neither is a secret you paste into a request. Registration is management work, so you need a portal session or an admitted management service identity. ## Register the source, do not send the secret 1. Describe registration for your source type, so you know which fields it expects. 2. Plan and register the source. Lithi stores a secret reference, never the secret value. 3. Test the registration, then read it back before you quote any work. Read-back confirms the registration exists and is usable. It never returns the secret, because the secret was never stored in a form that could be returned. ## Reference the credential from your request Your request's `input` object carries `credential_ref`. That field names a registered source. It never carries a key, a token, a password or a signed URL. A request that puts a secret in that field is refused as credential content, not quietly accepted. ## Prefer short-lived authority Delivery already works this way. A destination write obtains authority for that write, and the authority expires. `AUTHORITY_EXPIRED` is a distinct delivery state with its own next action, separate from `WRITE_FAILED`. Uploads follow the same shape. An artifact moves through `UPLOAD_AUTHORIZED` before anything is uploaded, so the authority is granted for one upload rather than held open. Where your own source system can issue short-lived federated access instead of a long-lived secret, register that instead. It limits what a mistake costs you. ## Four places a secret must never appear - a request body, including any field of the task specification - a log line, on your side or ours - a prompt, a parameter value or a rubric - an artifact, a result file or a delivered output Credentials are stripped before any manifest, job or outbox record is written. No scheduling or execution stage receives your credential. ## Rotate and revoke Keys and identities are planned, created, rotated, revoked and read back. Key plaintext is shown once, at creation, so store it in your own secret manager immediately or create a new one. Rotate on your own schedule. Revoke straight away if a credential was exposed, and read the revocation back rather than assuming it applied. ## If a secret was exposed Rotate it first at the system that issued it, because that is the only step that stops its use everywhere. Then revoke the Lithi source or destination registration that referenced it, re-register with the new credential, and test the registration before you resume work. [Register a source](/docs/compute/configure/sources)