Upstream credentials

The credential vault stores encrypted bearer credentials for direct upstream routing and MCP relays. The admin API never returns secret values; the proxy injects a credential immediately before forwarding and redacts it from request logs.

Bindings can either set an outbound header automatically or replace a namespaced placeholder like {{llama-dash:credential:<slug>}}. The vault warns before deleting a credential still referenced by a routing rule or relay.

Vault status

The vault is ready only when CREDENTIAL_ENCRYPTION_KEY is set to at least 32 characters. Stored secrets are encrypted with AES-256-GCM using a key derived from that value.

If the key is missing or too short, llama-dash can list non-secret metadata but cannot create, update, decrypt, or inject stored credentials.

Credential records

Each credential has:

• Name.
• Slug, used by placeholder templates.
• Type. The current credential type is bearer.
• Created and updated timestamps.
• Last-used timestamp.

Secret values are write-only through the admin API. Listing credentials returns metadata, not decrypted tokens.

Injection modes

Credential bindings support two modes:

• set_header sets an outbound header from a stored credential.
• replace_placeholder replaces {{llama-dash:credential:<slug>}} inside a header value template.

For bearer credentials, direct upstream targets can also use a credential as the upstream Authorization value.

Safety model

Credential-bearing routes and relays require a valid llama-dash API key before injection. Passthrough routes can preserve a caller's own Authorization header, but stored vault credentials are not injected into unauthenticated passthrough traffic.

Request logs record credential-injection audit metadata such as count, names, locations, and modes. Secret values are redacted.