Model access: provider and model allowlist

Model access is an organization-wide allowlist for AI models. It decides which providers, service routes, model makers, countries, inference and storage locations, and models your calls can use, and which provider data practices they must meet, such as zero data retention. Opper enforces it on every call: a call to a model outside the allowlist is refused with 403 before anything reaches a provider. Start with an organization allowlist, then narrow it for projects with stricter requirements. Model access is a Control Plane feature. With no model-access rule, no models are excluded by model access. For the two most common setups, see Enforce zero data retention and Keep AI inference in the EU.

Choose a provider data policy

In Rules → Model access, use Provider data policy to choose which provider practices are acceptable for your calls.

Provider data policy set to Zero data retention, with No training, No logging and No stored moderation checked and No provider moderation unavailable pending an agreement

Option	Effect on eligible models
No data requirements	Applies no filter for provider training, logging, or moderation practices and hides the requirements checklist. Other model-access filters still apply.
Zero data retention	Selects No training, No logging and No stored moderation, allowing only models that meet all three requirements. No provider moderation is a separate requirement.
Custom	Opens the checklist so you can choose individual requirements. Models must meet every selected requirement.

No data requirements leaves those practices unconstrained. It does not request providers that train on, log, or moderate your content. The displayed policy follows your selections. For example, selecting only No training shows Custom; selecting No training, No logging and No stored moderation shows Zero data retention, even if you also require No provider moderation. Clearing every requirement returns to No data requirements and hides the checklist. Opening an empty Custom editor and cancelling it by selecting No data requirements does not create a rule.

What each checkbox requires

Checking a box adds a requirement; clearing it removes that requirement. An unchecked box does not require the opposite practice. Requirements inherited from the organization still apply to projects.

Requirement	Models that remain eligible
No training	Models whose provider policy rules out using requests or responses for training. Providers that offer training on an opt-in basis are also excluded.
No logging	Models whose providers do not store request or response content in logs. This does not cover provider caching, content kept by provider moderation (see No stored moderation), or Opper trace storage.
No stored moderation	Models whose provider moderation keeps no flagged requests or responses. A provider that runs moderation and keeps nothing passes. Providers that keep logged content are also excluded, and so are providers whose moderation policy is unknown.
No provider moderation	Models whose providers do not run content moderation classifiers on requests. This requires Opper approval under a signed agreement.

These requirements filter models using provider policies recorded in Opper’s catalog. They do not change provider settings. If the catalog does not establish a provider’s policy for a selected requirement, its models do not pass that requirement. A policy you have not selected does not exclude models.

The Zero data retention preset means No training, No logging and No stored moderation. Provider caching is outside these requirements and is recorded separately for each route. Configure Opper’s own tracing and storage separately under Opper retention. Tools and services your application uses outside Opper keep their own retention, so review them separately.

Routes that require an agreement

Selecting Zero data retention needs no agreement. Some of the routes it allows still require one before your organization can call them: routes whose IDs begin with azure-zdr or vertexai-zdr, such as azure-zdr/gpt-5.6-luna and vertexai-zdr/gemini-3.7-flash-eu. Opper approves access to each of these providers separately, under a signed agreement. Until then, the model catalog marks their routes Agreement required, and a call to one is refused with 403 and the code entitlement_required before anything reaches the provider. The two providers handle content differently, so a route that requires an agreement does not by itself mean provider moderation is off. Opper’s catalog records these practices for the current routes:

Routes	Training	Request logging	Provider moderation
`azure-zdr`	No training	No logging	Off
`vertexai-zdr`	No training	No logging	On, with no moderation retention

To decide whether you need one of these routes, start from your requirements:

OpenAI models on Azure. Ordinary Azure routes serve the same models with no training or request logging and no additional agreement, but they run provider moderation that may keep flagged content, so Zero data retention excludes them. To allow them, choose Custom and select No training and No logging. To use OpenAI models under Zero data retention, you need an azure-zdr route. Its agreement makes your organization responsible for content moderation.
Gemini. In Opper’s current catalog, every Gemini route that needs no agreement is recorded with abuse-monitoring logging, so none of them meets No logging. For Gemini without provider request logging, you may need a vertexai-zdr route.
Location. Both providers have EU and global routes, but not every model has both. Choose a route that meets your processing-location requirement, and use Inference location in your allowlist to enforce it.

Provider caching is recorded separately. The vertexai-zdr routes, for example, are recorded with implicit caching, which No logging does not cover. Route approval also does not change what Opper itself stores: configure tracing and storage under Opper retention. Each route’s details in the model catalog show its recorded training, logging, and moderation practices, and the models page lists each route’s price. When a call is refused with entitlement_required, the error message links to this page. Where the catalog supports it, the message also names a route for the same model in the same location that needs no agreement, or says that every such route is recorded with request logging, or with provider moderation that may keep flagged content. Opper does not switch the call to another route for you. To request access, select Contact us in the route’s details in the model catalog, or email support@opper.ai with your organization, the models or routes you need, your required processing location, and your retention requirements. We can help identify an appropriate route and arrange the agreement where needed. Provider data policies are part of Rules, which are a Control Plane feature; approval for a route is granted separately and does not change your rules.

Arrange approval for No provider moderation

Contact Opper before selecting No provider moderation to arrange a signed agreement accepting responsibility for content moderation. Until Opper approves your organization, the checkbox is unavailable and shows Agreement required. Use the small Contact us button beneath the requirement to open the support flow.

Custom provider data requirements with No training, No logging and No stored moderation unchecked, No provider moderation disabled, an Agreement required notice, and the Contact us button

After approval, you can select the requirement. It concerns provider moderation classifiers; it does not remove a model’s built-in safety behavior or your Opper checks.

Build an organization allowlist

If you do not have an organization allowlist yet, select Set an org allowlist. Filter the catalog by any combination of these fields:

Field	Use it to
Providers	Allow selected providers, such as Anthropic or OpenAI.
Blocked providers	Block providers even if another filter would include them.
Service routes	Allow specific ways a provider serves models.
Blocked routes	Exclude specific service routes.
Inference location	Limit where inference runs, using countries or broader areas such as the EU or EEA.
Storage location	Limit where providers retain content.
Maker	Choose the companies that trained the models, regardless of who serves them.
Maker country	Limit where the model maker is legally based.
Provider country	Limit where the company operating the service route is ultimately owned.
Models	Allow only specific catalog models.

A model must match every field you set. Leave a field empty when you do not want to filter on it. Blocked providers and routes take precedence. Provider data requirements apply alongside these filters, so a model must satisfy both. The match counter updates as you edit. Select it to review the exact models that will remain available before you save. Select Save changes to apply your draft, or Discard to return to the saved rules. Changing a selector or checkbox alone does not change live model access.

A dialog listing the catalog models that match the allowlist

If the same provider appears in both Providers and Blocked providers, the rule cannot be saved. The pickers hide already-selected values to help prevent that conflict.

When Opper adds a provider or route

The allowlist is checked against the live catalog on every call, so it also decides what happens to providers and routes that Opper adds later. There is no separate setting for new providers. The fields you set decide:

Your rule sets	A newly added provider or route is
Providers	Blocked if it comes from a provider company not on the list. A new route from a company already on the list is allowed.
Models	Blocked unless its route ID without the provider prefix, or one of its aliases, is on the list. For example, `claude-sonnet-4-6` admits a new `azure/claude-sonnet-4-6`, but not `aws/claude-sonnet-4-6-eu`.
Only Blocked providers or Blocked routes	Allowed, unless you block it too.
Inference location, Storage location, Maker, a country field, or a provider data requirement	Allowed as soon as the catalog records facts for it that meet every field you set.

Facts the catalog does not have count as a failure. A route with no recorded inference location counts as GLOBAL and fails an EU or country filter, and a data practice that has not been researched fails that requirement. To keep new providers out until you have reviewed them, set Providers.

What model access covers

Model access applies to every model call: text generation and embeddings, image generation, speech, transcription, video, OCR, realtime voice, and rerank. A disallowed model is refused before anything reaches a provider. Opper does not silently switch to a different model. How a call is checked depends on how it names the model:

The call names	What happens when the allowlist excludes it
A pinned model, such as `anthropic/claude-sonnet-5`	Refused with `403`.
A bare model name, such as `claude-sonnet-5`, served by a pool of providers	Excluded providers are skipped and the call runs on an allowed one. If none are left, the call is refused with `403`.
A dynamic route, `dynamic/<name>`	A Pool node skips excluded models; if it has none left, it takes its fallback edge, or fails with `403` when it has none. A Model node whose model is excluded ends the route with `403` and the code `route_compliance_blocked`.
A `models` fallback list	Excluded entries are removed from the list before the first attempt, without an error. If every entry is excluded, the call is refused with `403`.

A default-model rule must point to a model that the same scope can use. The API refuses a default model that the allowlist excludes, and refuses an allowlist change that would exclude an existing default model, with 400, until you change or remove that default.

What a blocked call returns

Every refusal is HTTP 403, sent before the request reaches a provider. That includes streaming requests: the error comes back before the stream opens. The message names the model and the condition that failed. It does not name the rule; the rule’s name and scope are recorded on the call’s trace. The body follows the shape of the endpoint you called:

Endpoint	Body
`/v3/compat/chat/completions`	`{"error": {"code": "permission_error", "message": "…"}}`
`/v3/compat/v1/messages`	`{"type": "error", "error": {"type": "permission_error", "message": "…"}}`
`/v3/compat/responses`	`{"error": {"code": "model_not_allowed", "message": "…"}}`
`/v3/compat/openresponses`	`{"error": {"type": "permission_error", "code": "model_not_allowed", "message": "…"}}`
Gemini-compatible `generateContent`	`{"error": {"code": 403, "status": "permission_error", "message": "…"}}`
`/v3/compat/embeddings`	`{"error": {"type": "permission_error", "message": "…"}}`
Image, audio, video, and OCR endpoints	`{"error": "…"}`

A dynamic route whose Model node is excluded fails with the code route_compliance_blocked, and its message names the node rather than the condition. For example, a chat completion that pins a US-hosted model under an EU-only rule returns:

{
  "error": {
    "code": "permission_error",
    "message": "model \"anthropic/claude-sonnet-5\" is blocked by the active model allowlist: inference location US is outside EU"
  }
}

The part after the colon names the condition that failed:

Condition	Message ends with
Inference location outside the allowed area	`inference location US is outside EU`
No recorded inference location	`inference location is not recorded for this route, which counts as GLOBAL (allowed: EU)`
Provider not on your Providers list	`provider "mistral" is not on the allowlist (allowed: anthropic, openai)`
Provider or route blocked	`provider "xai" is excluded`, or `service route "…" is excluded`
Model not on your Models list	`model "gpt-5.5" is not pinned (pinned: claude-sonnet-5)`

When a models fallback list names pinned routes and every one is excluded, their distinct conditions are joined with ; . If the list names bare model names instead, the first entry’s has no allowed members message comes back. Two other refusals use their own messages:

A bare model name with no allowed providers left: model "claude-sonnet-5" has no allowed members under the current model allowlist.
A route that requires an agreement: code entitlement_required. See Routes that require an agreement.

If Opper cannot read your rules, it refuses every call rather than letting one through unchecked, with a message that ends the model rules could not be read, so every model is refused until they can be; retry the request. To check before you call, list models with your API key and GET https://api.opper.ai/v3/models?include=policy. Each model gets a policy object with allowed, blocked_by (org, project, or entitlement), and reason: the condition that failed, as in the part of a 403 message after the colon. reason is left out when blocked_by is entitlement.

Narrow access for a project

Select Narrow model access for a project to add an override. A project override intersects with the organization rule: it can remove access, but it cannot restore a provider, location, service route, or model that the organization rule excluded. Organization data requirements are inherited too. When the organization sets provider data requirements, the project’s policy selector is locked and the inherited checkboxes stay checked and unavailable for editing. Add requirements that the organization has not set to narrow access further. For example, if the organization requires No training, a project can add No logging, but cannot allow providers that fail the organization’s training requirement. The override summary shows the effective result, not just the fields you added:

PROJECT         NARROWS ORG RULE BY            EFFECTIVE MODELS
sqlassistant    providers → anthropic, openai  45 models of 77

While you edit an override, values unavailable at the organization level are dimmed.

A project provider picker with values excluded by the organization rule dimmed

To make one of those values available, broaden the organization rule first. You can edit both levels in the same draft and save them together.

An override can leave a project with 0 available models. Opper warns you but allows the save because denying all model calls may be intentional.

If older organization rules exist

The runtime uses only the newest enabled organization allowlist. Older organization allowlists have no effect and do not intersect with it. Rules shows the active allowlist and tells you when older rules are still present so you can remove them. Project overrides still intersect with the active organization allowlist.

Set shared requirements, such as No training or EU inference locations, at the organization level. Use project overrides for workloads that need an even smaller model set.

Get started

Platform

Build

Observe & Control

Apps

Tutorials

Tooling

Model access: provider and model allowlist

Choose a provider data policy

What each checkbox requires

Routes that require an agreement

Arrange approval for No provider moderation

Build an organization allowlist

When Opper adds a provider or route

What model access covers

What a blocked call returns

Narrow access for a project

If older organization rules exist

​Choose a provider data policy

​What each checkbox requires

​Routes that require an agreement

​Arrange approval for No provider moderation

​Build an organization allowlist

​When Opper adds a provider or route

​What model access covers

​What a blocked call returns

​Narrow access for a project

​If older organization rules exist

Choose a provider data policy

What each checkbox requires

Routes that require an agreement

Arrange approval for No provider moderation

Build an organization allowlist

When Opper adds a provider or route

What model access covers

What a blocked call returns

Narrow access for a project

If older organization rules exist