Credentials — the auth bridge

Credential modes

At compile time, each tool derives a credential_mode from your spec's security requirements:

The mode is enforced at every stage: eval, release, and invoke.

The API-key broker

Attach a key per project (B2B APIs are sold one key per integration). The broker:

• Stores the secret with KMS envelope encryption — ciphertext in the

database, data keys unwrapped only at call time.

• Captures, lists, rotates, and revokes keys from the console. Rotation

is non-disruptive; revocation takes effect immediately.

• Injects the key at call time — after release/signature resolution, before

URL construction — for both eval probes and invoke. The injected credential wins over any spec-declared value, so your real key is always the one on the wire.

• Keeps secrets out of release artifacts, manifests, and logs (the

cf_live_ gateway-key shape and key material are redacted everywhere, including telemetry).

Until the vault is configured, credential endpoints answer an honest 503 credential_storage_not_configured — the feature never pretends to work.

What happens without a key

No ambiguity, no silent 401s:

• Eval records a failed credential_configured auth result

(CREDENTIAL_REQUIRED) — the run fails, nothing promotes.

• Release refuses with release_credential_required, naming the tools

and their modes.

• Invoke refuses with CREDENTIAL_REQUIRED ("Connect an account…")

before any upstream call.

Attach the key, re-run eval, and the gates open.