# Model allowlists

> Restrict models by organization, project and gateway key in INFRO, with policy checks across configured provider routes and fallback models.

Source: https://infro.io/docs/org/model-allowlists

> **Note:** INFRO is in private early access. Running these examples requires an early-access account, an active trial or subscription entitlement, and your own provider connection. Self-serve purchasing is not generally open. See [Early access](https://infro.io/early-access).

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](https://infro.io/docs/routes) and [EU compliance](https://infro.io/docs/compliance/eu).

> **Note:** Policy management uses the console. The previously documented `/v1/org/model-allowlist` APIs are not implemented; use the current console controls.