Feature: Allow LLM nodes to bind Secret environment variables to model provider credentials

No files, tests, or entry points are named in the issue, so first map the LLM node configuration and credential-resolution paths in Dify Core. Done should preserve only a Secret selector, resolve it at runtime, replace the selected credential field without exposing the value, and fail closed when resolution is invalid.

Self Checks

• I have read the Contributing Guide and Language Policy.
• I have searched for existing issues, including closed ones.
• I confirm that I am using English to submit this request.
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Yes.

I need different LLM nodes/workflows to use different API keys while keeping the same model provider, model, endpoint, and other provider settings.

A concrete example is:

• OpenAI / same endpoint / GPT model / API Key A
• OpenAI / same endpoint / GPT model / API Key B
• Anthropic / same endpoint / Claude model / API Key A
• Anthropic / same endpoint / Claude model / API Key B

In my current setup, the official provider integration does not let an LLM node select an API key dynamically from the workflow. I therefore have to duplicate/fork provider integrations just to configure another API key for the same endpoint. This increases maintenance cost because duplicated providers need to be kept in sync with upstream provider-plugin updates.

I found several related requests:

• #24491 — Allow credential set choice during model selection
• #28815 — Workflow-Level Credential Override for Model Providers
• #29313 — Dynamically provide the API key for the LLM node
• #32965 — Model credentials selector
• #35440 — Dynamic model provider API key selection per workflow run / per client
• #37078 — Dynamic credential overrides PR

Those requests cover selecting pre-registered credentials or providing per-request credential overrides. This proposal is intentionally narrower and uses an existing Dify security primitive: Secret environment variables.

Proposal

Allow an LLM node to optionally bind a Dify Secret environment variable to a provider credential field at runtime.

For example:

Workflow Secret environment variables

OPENAI_API_KEY_TEAM_A      (Secret)
OPENAI_API_KEY_TEAM_B      (Secret)
ANTHROPIC_API_KEY_TEAM_A   (Secret)

Then an LLM node could be configured as:

Provider: OpenAI
Model: GPT model
API key override: OPENAI_API_KEY_TEAM_A

or:

Provider: Anthropic
Model: Claude model
API key override: ANTHROPIC_API_KEY_TEAM_A

The workflow definition should persist only the Secret variable selector/reference, not the resolved secret value.

Conceptually:

Secret environment variable
        ↓
LLM node credential binding
        ↓
runtime effective credentials
        ↓
existing provider plugin

For OpenAI, the resolved Secret would replace only the effective openai_api_key.

For Anthropic, it would replace only the effective anthropic_api_key.

Other provider configuration such as API base URL, organization, protocol, model settings, etc. would continue to come from the existing provider/model configuration.

This could later be generalized to provider credential fields instead of being OpenAI/Anthropic-specific.

Desired behavior

1. If no credential override is configured, use the existing provider/model credential exactly as today.
2. If an override is configured and the Secret resolves successfully, copy the normal credentials and replace only the selected credential field in the runtime copy.
3. If an override is configured but the Secret is missing, empty, invalid, or not a Secret variable, fail closed before provider invocation.
4. Do not silently fall back to the default credential when an explicitly configured override cannot be resolved.

Fail-closed behavior is important because silent fallback can send usage to the wrong billing account or quota.

Security boundary

The Secret value should remain in the credential path and should not be converted into a normal LLM completion/model parameter.

In particular, the resolved Secret should:

• never be persisted into the workflow DSL
• never be exposed through completion_params / model_parameters
• never be included in LLM invocation parameters or tracing metadata
• never be returned to the frontend
• never be written to logs or error messages
• exist only in the runtime effective credential object for the provider invocation

This is the main difference from simply adding an api_key model parameter. Model parameters may participate in normal workflow configuration and observability paths, while API keys should retain Secret/credential semantics.

UI idea

The LLM node could expose a small optional credential source selector next to the model configuration:

Model
  GPT model

API Key
  [ Use provider default                ]
  [ OPENAI_API_KEY_TEAM_A (Secret)      ]
  [ OPENAI_API_KEY_TEAM_B (Secret)      ]

Reasoning effort
  High

Only Secret environment variables should be selectable for this field.

Why Secret environment variables?

Dify already has Secret environment variables as a workflow-scoped mechanism for storing sensitive values. Reusing that mechanism would avoid introducing raw API keys into request payloads or normal LLM parameters, while allowing workflows to remain portable and keeping provider plugins unmodified.

This would also remove the need to clone provider integrations purely to use multiple API keys against the same provider endpoint.

2. Additional context or comments

This proposal is complementary to #37078 rather than a replacement for it.

#37078 targets per-request credential overrides / BYOK-style execution. This proposal targets a different scope: workflow-managed Secret values selected at the LLM-node level.

A possible implementation boundary would be:

LLM node Secret selector
        ↓
workflow variable pool
        ↓
credential resolver
        ↓
copy existing provider credentials
        ↓
override one credential field
        ↓
existing OpenAI / Anthropic provider plugin

Keeping the override in Dify Core's credential resolution path would allow official provider plugins to continue consuming their existing credential fields without requiring provider-specific forks.

3. Can you help us with this feature?

• I am interested in helping clarify the use case, expected behavior, and security requirements.