Credentials and short-lived federation

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