LangChain’s Beta LLM Gateway Blocks Models Outside Access Policies

Organizations can set provider and model limits by organization, workspace, user, or API key. But a narrower rule replaces a broader catalog instead of adding to it.

By 2 min read
LangChain’s Beta LLM Gateway Blocks Models Outside Access Policies
LangChain’s Beta LLM Gateway Blocks Models Outside Access Policies

Listen to this story

The audio brief

About 1:19
0:001:19
Read transcript
LangChain’s beta LLM Gateway can now enforce an approved list of AI providers and models—and block requests that fall outside it with an HTTP 403 response. The important detail is how those lists interact. Administrators can set a policy for an entire organization, a workspace, an individual user, or a single API key. But the most specific matching policy replaces the broader one; it does not add to it. So if an organization allows OpenAI and Anthropic, a key-level policy allowing OpenAI and Gemini leaves that key with OpenAI and Gemini only. Anthropic does not carry through. When several policies apply at the same level, the rules become stricter: a model has to be allowed by every policy at that level. If no policy matches, the gateway continues to allow all providers and models. Creating or managing these policies requires permission to manage the organization, and changes take effect immediately. There is also a practical tradeoff: while a policy is enabled, the gateway blocks its provider- and model-configuration routes, and the beta does not support custom model providers. For teams, the feature offers a straightforward way to control approved access, but the key constraint is the replacement behavior—narrower rules create a new catalog rather than an exception layered onto the old one.

Story brief

3 key points

LangChain’s beta LLM Gateway adds administrative enforcement for approved AI-provider and model catalogs. Policies can target an organization, workspace, user, or API key, with the most specific matching scope replacing broader permissions; overlapping rules at the same scope become more restrictive. Unauthorized requests receive HTTP 403 responses, and policy changes apply immediately. Administrators need...

  1. 01

    API-key policies override organization, workspace, and user policies instead of inheriting or adding to them.

  2. 02

    When multiple policies match at the same scope, a model must be allowed by every policy.

  3. 03

    If no policy applies, all providers and models remain available through the gateway.

LangChain’s beta LLM Gateway supports model access policies that let organizations decide which AI providers and models can be called through the service. A request for a provider or model outside an applicable policy is blocked rather than sent onward.

A shared catalog or a tailored exception

A policy can allow every model offered by a provider or name only selected models. It can govern an entire organization, a workspace, an individual user, or one API key. That gives administrators a choice between setting a common approved catalog and assigning a different catalog to a particular person or credential.

Four places a policy can apply

  • Organization: all users and workspaces in the organization.
  • Workspace: all users in one workspace.
  • User: one individual user.
  • API key: one specific credential.

Overrides are replacements, not additions

LangChain ranks policy specificity from API key to user, workspace, then organization, and applies only the most specific matching tier. A key permitted to use OpenAI and Gemini, for example, would not also inherit Anthropic access from an organization policy that permits OpenAI and Anthropic.

The same-tier behavior runs the other way: when multiple policies match at one tier, a model must be permitted by all of them to remain available. That makes overlapping rules more restrictive, while a more-specific scope creates a distinct replacement catalog.

A gate with clear limits

The gateway returns a 403 response for requests outside a policy. If no policy applies, all providers and models remain available. While a policy is active, the gateway also blocks its provider- and model-configuration routes.

The beta capability does not support custom model providers. Creating or managing a policy requires the organization:manage permission, and saved changes take effect immediately. The design therefore offers quick control over approved provider access, but not over unusual custom-provider setups.

Sources

  1. docs.langchain.comModel access policies - Docs by LangChain

Loading discussion...