Model allowlists

Model allowlists define which models an organization, project or gateway key may call. Configure them in the console to keep workloads within the models approved for that scope.

How scopes combine

Each non-empty allowlist narrows access. A model must satisfy every applicable organization, project and key policy. An empty list at one scope imposes no additional restriction; it does not override a narrower list elsewhere.

Model identifiers

Use catalog model IDs or vendor wildcards such as anthropic/*, matched case-insensitively. Entries are validated when saved. Owners and admins edit the organization and project lists; anyone who can create a gateway key can set that key's own list. Route targets and fallback models remain subject to model policy; a named route is not a way around an allowlist.

Blocking models

Prefix an entry with ! to block what it names: !openai/gpt-4o blocks one model, !openai/* a whole vendor. A block entry always wins over an allow entry in the same list. A list of block entries alone allows every other model, including models added to the catalog later; for example ["!openai/gpt-4o"] allows everything except that model. A list with allow entries allows only what they match, minus what is blocked: ["anthropic/*", "!anthropic/claude-opus-5"] allows every Anthropic model but one.

Denied requests

A denied model returns HTTP 403 with error.type: "permission_denied" and error.code: "model_not_allowed"; the message names the list that refused it (organization, project or key). Change the model selection or the policy through an authorized administrator rather than retrying the same denied request.

Other boundaries

Environment-scoped connections and key route restrictions apply separately. Region fields are not a guarantee of data residency. See Routes and EU compliance.