Model access

Employees can reach every model Gateway serves your organization unless you block it.

Block a provider or model for the organization

Add a rule on the Blocklist tab naming providers, models, or both, plus an optional reason. A provider block covers every model from that provider, including future ones.

• Rules apply organization-wide on the next request
• Limit: 100 rules per organization
• A blocked model is removed from routing candidates and refused when named directly. If every candidate in a policy is blocked, the request fails with no eligible vendor.

Restrict one Group to approved models

1. Open the Group from Groups and access and choose Edit.
2. On the Resources tab, go to Approved models.
3. Add up to 200 entries: a provider/model id such as anthropic/claude-opus-5, or a trailing wildcard such as openai/*. Aliases are refused.

• The list reaches every member’s key within seconds
• Under a routing policy, unapproved targets are skipped. Naming an unapproved model returns 403.
• Saving an entry the blocklist covers returns 400

To steer a Group without blocking, scope a routing policy to it instead.

Enable access-gated vendors

Some vendors need access turned on before you can route to their models. Gating follows the model’s author, so it covers every host, including Amazon Bedrock. Gated models show Requires access in the catalog.

To request access, use the in-app chat or email support@merge.dev with the vendor, models, and expected volume. Until then, routing skips gated models, and saving one into a policy returns 400.

Error an employee sees when a model is refused

Refusals return 403. Branch on code, not the message.

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

Refused requests appear as blocked in LLM calls, not as errors.