fabro/docs
Bryan Helmkamp 6dfc96d3fd
Resolve provider secrets through lithos conventional credentials
lithos-llm now owns which named secrets each provider reads and how they
shape into its auth scheme, including a derived `<PROVIDER>_API_KEY` for
operator-defined providers. Fabro's job shrinks to supplying the store:
`VaultCredentialSource` hands lithos a lookup that reads the process
environment, then the vault, under the same conventional names.

What Fabro still adds on top: the Codex OAuth credential in the vault,
refreshed and persisted when it expires; `{{ secrets.NAME }}` tokens in a
provider's `default_headers`, resolved against the vault and re-sent as
credential headers; and OpenAI organization and project headers from the
environment.

Deleted with the `metadata.fabro.credentials` list: `CredentialRef`,
`CredentialResolver`, `EnvCredentialSource` (now
`VaultCredentialSource::environment_only`), and the `env_var_names` /
`expected_vault_secret_name` helpers, replaced by `secret_names` and
`expected_secret_name` over the lithos table. `openai-codex` joins the
first-party provider id constants.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-09 23:00:08 -06:00
..
brainstorms Remove nonfunctional run agent permissions setting 2026-07-29 10:23:00 -04:00
ideation docs 2026-04-09 17:24:30 -04:00
internal Resolve provider secrets through lithos conventional credentials 2026-09-09 23:00:08 -06:00
plans Reuse PermissionLevel and fix stale run spec snapshots 2026-08-01 10:09:44 -04:00
public Resolve provider secrets through lithos conventional credentials 2026-09-09 23:00:08 -06:00
superpowers Reuse PermissionLevel and fix stale run spec snapshots 2026-08-01 10:09:44 -04:00