Model access

Your organization starts with every model Gateway serves it. Model access is subtractive: you take models away, and what is left is what employees can reach.

There is no organization-wide approval list to keep in sync. Blocking a model on the Blocklist tab is what takes it out of reach, and All models keeps the blocked rows visible rather than hiding them.

For what each model costs, what it can do, and which vendors serve it, see the model catalog.

Blocking a provider or model

A rule names one or more providers, one or more specific models, or both, plus an optional reason. Blocking a provider covers every model it serves, present and future, which is usually what you want when the decision was made about the vendor rather than the model.

Record the ticket or the requirement in the reason field. It shows up alongside the rule and in the audit trail for that rule’s create, update, and delete events, which is what makes a review of your blocklist six months from now readable.

Rules are organization-wide and take effect on the next request. Up to 100 rules per organization.

Two properties are worth planning around:

• A block cannot be routed around. Rules are evaluated before routing, so a blocked model is filtered out of a routing policy’s candidate set before scoring and is refused when an employee names it directly. If a policy’s every candidate is blocked, the request fails with no eligible vendor.
• Blocking is not the same as unlisting. Blocked models still appear on All models, so an employee asking why they cannot use one, and an admin deciding whether to unblock it, are looking at the same row.

Narrowing access for one Group

The blocklist is the organization-wide floor. Above it, each Group carries its own approved-models list, on the Group’s Resources tab under Approved models. Open a Group from Groups and access and choose Edit.

Leave the list unset and the Group reaches any model in the catalog, including ones added later. Set it and only those entries are approved, up to 200 of them. An entry is a canonical provider/model id such as anthropic/claude-opus-5, or a trailing wildcard such as anthropic/claude-opus-* or openai/*, which the card renders as “OpenAI (all models)”. A model alias is refused, because the list applies to resolved models. An empty list approves nothing, so that Group’s employees can use no model at all.

Two things to know before you rely on it:

• The list is enforced on the employee’s key, not inline. Saving records the intent and the next reconcile pushes it onto every member’s key, which follows in seconds rather than on the same request. A Group with no Gateway project yet still stores the list, and reconcile applies it once the project and keys exist.
• It filters under a policy and refuses a named model. On a Priority or Intelligent policy an unapproved target is skipped and the request falls through to a permitted one; a request that names an unapproved model directly gets a 403.

Saving an entry that your own blocklist covers is refused with a 400 naming the entries, so a Group cannot be approved for a model the organization forbids.

The softer lever is to scope a routing policy to the Group instead: its requests then select only from that policy’s models, and nothing is denied outright. Reach for the approved-models list when a model has to be unreachable for that team, and the policy when you are steering rather than blocking. For per-customer deny and pin rules that this dashboard does not expose, see Per-customer restrictions in Gateway.

Models that need access enabled

A few vendors are access-gated, so an organization needs access turned on before it can route to their models. Gating follows a model’s author, not its host, so it covers every path to that model at once, including the vendor’s own API and the same model served through Amazon Bedrock. Models by other authors on the same host are unaffected.

Organizations on the Enterprise plan, and any organization created before a vendor’s cutoff, already have access and need to do nothing. Everyone else sees those models labelled Requires access in the catalog. To request access, use the in-app chat or email [email protected] with the vendor, the models, and roughly the volume you expect. It applies organization-wide within a few minutes, with no change on your side.

Until then, a gated vendor’s models are skipped rather than fatal: a routing policy whose best candidate belongs to a gated vendor falls through to the next permitted one. The case that fails is a policy where every target is gated. Saving one of those models into a policy is refused at write time with a 400, so a target you could never route to does not sit in your configuration looking active.

What an employee sees

A refused request comes back as an ordinary API error in whatever client they are using. Blocklist refusals return 403:

{
  "error": {
    "message": "Request blocked by organization policy.",
    "type": "blocked_by_policy",
    "code": "model_blocked"
  }
}

The code says which dimension refused it: model_blocked for a blocked model, provider_blocked for a blocked provider, model_not_allowed for a model outside the Group’s approved list, and vendor_access_required for a gated vendor you have not requested access to. Branch on code rather than the message text.

These are recorded as blocked requests rather than errors, so they do not inflate your error rate in LLM calls, and a spike in them tells you which model a team keeps asking for.

Next

To keep traffic on vendors that hold a zero data retention agreement, ZDR enforcement is the Advanced tab’s first card, set in the Gateway console while that tab is gated. Read Zero data retention for which vendors qualify.