Instance-level allow-list for LLM / model providers usable in AI nodes

Feature Requests
1

The idea is:

An instance-level allow-list of LLM / model providers that AI nodes (AI Agent, Chat Model, Vector Store, LLM Chain, MCP Client, etc.) are permitted to use. Configured via env or a settings-page section, in the shape of:

N8N_AI_PROVIDER_ALLOWLIST=openai-compatible:https://gateway.example.com/*,azure-openai:mytenant.openai.azure.com

Behaviour when the allow-list is set:

  • Credential create/edit for a disallowed provider fails validation with a clear message (e.g. "Provider openai is not on this instance's approved list; use openai-compatible pointing at the approved gateway.").
  • Workflow save referencing a disallowed credential surfaces a warning banner and marks the workflow as non-executable at that node.
  • Runtime: any dispatch to a disallowed provider returns an error on the node's output (does not silently succeed).
  • Credential picker UI only lists allowed provider types.
  • Audit event emitted when a workflow is saved referencing a disallowed provider — helps find shadow-config attempts even when execution is blocked.

Empty / unset allow-list preserves today's behavior ("everything permitted").

Entry syntax: <provider-key>[:<base-url-glob>]. For hosted providers (OpenAI, Anthropic, Bedrock, Azure OpenAI) the entry can restrict to a specific region/resource; for openai-compatible / self-hosted, the base-URL glob is required so admins can pin exactly one gateway.

My use case:

We route all LLM traffic through an internal GenAI Gateway (LiteLLM-based) that enforces an approved model list, per-team budgets, PII/DLP scrubbing, and provider-level audit.

Today, any workflow author on any of our >30 n8n tenant instances can configure an OpenAI / Anthropic / Azure OpenAI credential with a personal or corp-side API key and bypass the gateway entirely.

Detection is retroactive: we scan the DB, find the workflow, and disable it after the fact. That's a poor user experience and a real compliance risk — Legal needs a "cannot happen" story, not a "we catch it eventually" one.

A hard, authoring-time block controlled at the instance level is the only pattern that scales across 30 tenants without touching every workflow.

I think it would be beneficial to add this because:

  • Enterprise / regulated deployments need provider governance. Whether the constraint is internal Legal, GDPR, HIPAA, or an approved-vendor list, the same shape applies: "these providers only." No amount of documentation or lint catches a determined workflow author; it has to be enforced by the platform.
  • Authoring-time > runtime-time > post-hoc-audit. Blocking at credential/workflow-save is the cheapest signal for both the user and the admin — the alternatives (egress firewalls, DB scans, forked builds) all cost far more.
  • Doesn't touch OSS defaults. Unset allow-list means today's behavior; only self-hosters who need this policy turn it on.
  • Consistent with existing directions. n8n already ships instance-level knobs for MCP (N8N_MCP_MANAGED_BY_ENV, N8N_MCP_ACCESS_ENABLED) and custom global-role scopes (behind N8N_ENV_FEAT_CUSTOM_INSTANCE_ROLES). This is the same shape applied to the AI-provider dimension.

Any resources to support this?

  • Related concept in n8n: credential sharing governance already scoped per-project; this FR is the provider-type axis rather than the who can see this credential axis.
  • Adjacent instance-level policy envs already in place: N8N_MCP_ACCESS_ENABLED, N8N_MCP_MANAGED_BY_ENV, N8N_ENV_FEAT_CUSTOM_INSTANCE_ROLES.
  • Reference for provider allow-list semantics: LiteLLM, an established open-source model-gateway with the shape of allow-list config we'd want to mirror.
  • Internal driver: security review requirement to ensure only approved GenAI Gateway providers are used from n8n AI nodes.

Are you willing to work on this?