Problem
models.providers.*.headers.* is not in the SecretRef credential surface. Users running proxied/gateway providers (Cloudflare AI Gateway, LiteLLM, custom reverse proxies) pass auth tokens as custom headers — these are user-supplied credentials that should be SecretRef-eligible.
Example
{
"models": {
"providers": {
"cloudflare-ai-gateway": {
"headers": {
"cf-aig-authorization": "Bearer <token>" // ← plaintext credential, no SecretRef support
}
}
}
}
}
Context
This came up in #28984 (now closed, superseded by #29580). The wildcard nature of header keys makes static enumeration harder, but the pattern is consistent: models.providers.{providerId}.headers.{headerName}.
Per @joshavant's feedback on #28984, opening this as a standalone issue.
Suggested scope
secrets audit should flag plaintext values in models.providers.*.headers.*
secrets plan + secrets apply should support SecretRef resolution for these paths
- Path matching: 5-segment —
models.providers.{id}.headers.{key}
Problem
models.providers.*.headers.*is not in the SecretRef credential surface. Users running proxied/gateway providers (Cloudflare AI Gateway, LiteLLM, custom reverse proxies) pass auth tokens as custom headers — these are user-supplied credentials that should be SecretRef-eligible.Example
{ "models": { "providers": { "cloudflare-ai-gateway": { "headers": { "cf-aig-authorization": "Bearer <token>" // ← plaintext credential, no SecretRef support } } } } }Context
This came up in #28984 (now closed, superseded by #29580). The wildcard nature of header keys makes static enumeration harder, but the pattern is consistent:
models.providers.{providerId}.headers.{headerName}.Per @joshavant's feedback on #28984, opening this as a standalone issue.
Suggested scope
secrets auditshould flag plaintext values inmodels.providers.*.headers.*secrets plan+secrets applyshould support SecretRef resolution for these pathsmodels.providers.{id}.headers.{key}