> This page is for Workforce.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.merge.dev/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.merge.dev/_mcp/server.

# Model access

> How the All models, Blocklist, and Provider keys tabs relate, how to block a provider or model organization-wide, how to narrow access for one Group with its approved-models list, and what a refused request looks like.

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.

| Tab                                                            | What it shows                                                                         |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| [All models](https://wf-develop.merge.dev/models/all-models)   | Everything Gateway serves your organization, with the blocked rows badged **Blocked** |
| [Blocklist](https://wf-develop.merge.dev/models/blocklist)     | The rules that do the subtracting                                                     |
| [Provider keys](https://wf-develop.merge.dev/models/providers) | Your own provider API keys, so requests bill your account instead of Merge's          |

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](/merge-gateway/models/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](/merge-workforce/provisioning/groups) 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](/merge-workforce/models/routing) 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](/merge-workforce/models/routing) 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](/merge-gateway/security/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 [support@merge.dev](mailto:support@merge.dev) 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`:

```json
{
  "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](/merge-workforce/logs/gateway), 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](/merge-workforce/models/advanced)'s first card, set in the Gateway console while that tab is gated. Read [Zero data retention](/merge-gateway/security/zero-data-retention) for which vendors qualify.