Problem

plugins.entries.*.config.* is not in the SecretRef credential surface. Plugins frequently store user-supplied API tokens and passwords in their config blocks — these are credentials that should be SecretRef-eligible.

Examples

{
  "plugins": {
    "entries": {
      "ha-context": {
        "config": {
          "haToken": "eyJhbGci..."  // ← Home Assistant long-lived access token
        }
      },
      "otel-observability": {
        "config": {
          "headers": "x-honeycomb-team=hcaik_..."  // ← Honeycomb ingest key
        }
      }
    }
  }
}

Context

This came up in #28984 (now closed, superseded by #29580). Plugin config is a wildcard surface — any plugin can define any config keys — but the pattern is consistent: plugins.entries.{pluginId}.config.{key}.

Per @joshavant's feedback on #28984, opening this as a standalone issue.

Suggested scope

• secrets audit should flag plaintext values in plugins.entries.*.config.* that look like credentials (tokens, keys, passwords)
• secrets plan + secrets apply should support SecretRef resolution for these paths
• Path matching: 5-segment — plugins.entries.{id}.config.{key}
• Challenge: not all plugin config values are secrets (e.g. ollamaUrl, cacheTtlMs). May need heuristic detection or an opt-in annotation from plugin authors.