Description

In talk.config when includeSecrets=false, the gateway still computes a providerInputConfig that prefers runtimeResolved provider config, which is described as “already-substituted secrets”, and passes it into speechProvider.resolveTalkConfig.

This creates a confused-deputy secret exposure / secret-usage issue:

• Input: a client with only operator.read can call talk.config (per method scopes and tests).
• Secret resolution: runtimeConfig/runtimeResolved may contain the provider apiKey as a resolved string (e.g., from env/secret store).
• Sink: that resolved apiKey is handed to third-party/bundled provider plugins via speechProvider.resolveTalkConfig({ talkProviderConfig: providerInputConfig, ... }).
• Even if the response is later redacted, the secret has already crossed the trust boundary into plugin code. A plugin could log/exfiltrate the key, or perform network calls using it, purely because a read-scope client invoked talk.config.

Vulnerable flow (simplified):

• read-scope caller → talk.config → resolveTalkResponseFromConfig(includeSecrets=false) → runtimeResolved.config (resolved secrets) → resolveTalkConfig(talkProviderConfig=...) (plugin-controlled code).

Vulnerable code:

const runtimeProviderConfig = runtimeResolved?.config ?? {};
​// Prefer runtime-resolved provider config (already-substituted secrets)
const providerInputConfig = stripUnresolvedSecretApiKey(
  Object.keys(runtimeProviderConfig).length > 0 ? runtimeProviderConfig : sourceProviderConfig,
);
const resolvedConfig =
  speechProvider?.resolveTalkConfig?.({
    ...,
    talkProviderConfig: providerInputConfig,
  }) ?? providerInputConfig;

Although stripUnresolvedSecretApiKey removes wrapper SecretRef values, it explicitly allows string api keys through; so resolved secrets will still be passed to plugins.

Recommendation

Avoid passing resolved secrets to provider plugins when servicing talk.config requests from clients that lack secret scope.

Options (choose based on intended trust model):

1. Best isolation: when includeSecrets=false, always pass a provider config with apiKey removed/undefined to resolveTalkConfig:

const providerInputConfig = {
  ...(Object.keys(runtimeProviderConfig).length > 0 ? runtimeProviderConfig : sourceProviderConfig),
  apiKey: undefined,
};

2. If plugins need SecretRef context but not material: pass the source config (SecretRef wrapper) and update strict helpers/providers to tolerate wrappers in discovery paths (do not require resolved secret for config discovery).

3. If calling resolveTalkConfig can trigger outbound calls: consider skipping resolveTalkConfig entirely unless the client has operator.talk.secrets, or ensure resolveTalkConfig is pure (no network/logging) and enforce this contract.

In all cases, keep redaction for responses, but also prevent secret propagation into plugin code on unprivileged requests.