Model access locks

A Model access lock holds one project to the service routes that its saved Model access rules allow when you take the lock. A service route is one provider serving models from one place, such as azure:se (Microsoft Azure in Sweden) or openai/api-us. The lock records each route with the facts Opper’s catalog holds for it that day: the company that runs it, where inference runs, and how the route handles content for training, logging, moderation, and caching. Use a lock when a data processing agreement or an internal policy names the providers and locations a workload may use, and that list must not change when someone edits the rules. Once a project is locked, no rule change can widen what it reaches, and neither can a provider, location, or route that Opper adds to the catalog later. Only replacing or releasing the lock changes it. Locks are listed under Settings: open Data processing under Access & security, then Model access locks. The page is at platform.opper.ai/<your-org>/settings/data-processing/locks. Taking a lock needs the Control Plane or Enterprise plan.

How a lock works with your rules

A lock is a ceiling on top of the project’s Model access rules. A call from a locked project goes through only when both of these hold:

The rules that apply to the project, the organization rule and any project override, allow the model.
The model’s service route is one of the locked routes.

Which models the project may use on the locked routes is still up to the rules, so you can keep narrowing them. The lock blocks anything the rules allow outside it.

After the project is locked	Effect on the project
The organization rule or the project override is narrowed	Applies. The project reaches less than its lock holds, and the lock is shown as listing routes the rules already block.
Either rule is widened	No effect past the lock. Routes the rules now allow outside the lock are shown as blocked by the lock.
A rule is deleted or replaced	The project follows the rules now in force, inside the lock.
A rule change would leave the project no model it can call	Refused. See Change rules on a locked project.
Opper adds a model to a locked route	Reachable when the rules allow it.
Opper adds a provider, a location, or a route	Not reachable.
Opper renames a locked route	The lock still admits the route under its new ID.
Opper retires a locked route	The project can no longer call it. The lock does not change.
Your organization’s agreement for a restricted route ends	The project can no longer call that route.

A lock is taken from the saved rules and the restricted routes your organization has an agreement for. Changes not yet saved on the Rules page are not part of it. Like rules, a lock applies to every model type on the Opper v3 API, including the compatibility gateway and the playground. Deprecated APIs are not supported with locks.

Who can lock a project

Action	Permission	Plan
See locks on Data processing and the Rules page	View rules	Every plan
Lock a project, or replace its lock	Configure rules and View projects	Control Plane or Enterprise
Release a lock	Configure rules and View projects	Every plan
See lock events in the Audit Log	View audit logs	Enterprise

With the built-in roles, Owners and Admins can lock, replace, and release. Developers can see locks but not change them. Viewers do not see them. See Roles and permissions. Seeing and releasing locks work on every plan, so an organization can always see and remove a lock it holds. On another plan, a member who may configure rules is told which plans can lock and offered Upgrade to Control Plane. Locks are taken on Data processing, or from a project rule on the Rules page. The Management API does not take, replace, or release them.

Lock a project

Open Model access locks

In the Opper platform, open Settings, then Data processing, then Model access locks, and select Lock a project.

Pick the project

The dialog reads the project’s saved rules and shows the lock it would take, for example “4 routes at 2 companies, 37 models.”

Review the preview

The readiness review lists what to know before you lock, each item with the action that changes it where there is one. Routes in the lock lists each route under the company that runs it, with where it runs, how many models it serves, and its handling facts.

Take the lock

Optionally add a Label, such as the agreement the lock is for, then select Lock project.

The new lock is version 1 of the project’s lock. It reads Activating, then In force once every Opper server has confirmed it, usually in under a minute. See Activating and in force. You confirm the preview you see. If the project’s saved rules or the readiness review change before you select Lock project, the lock is refused and the dialog shows the new preview for you to confirm.

Lock from the Rules page

A project rule’s panel on the Rules page has a Lock group for each project the rule names. For a project with no lock, the group reads Not locked, with Lock this project: “A lock holds this project to the routes its saved rules allow now. Rules can narrow that later, not add to it.” The button opens the same lock dialog. Lock this project shows only to a member who may lock, on a plan that can. It is unavailable while the panel has unsaved changes: “Save or discard your changes first. A lock is taken from the saved rules.”

The readiness review

The preview sorts what to know before you lock into three groups. Each item is part of what you confirm.

Group	Items
Blocks locking	”The project’s saved rules allow no models.”, with Edit Model access. While something blocks locking, the review shows nothing else and Lock project stays unavailable.
Review	A check that does not run while the project is locked, because the lock blocks the models it runs on, with Choose an available check model. The item says whether requests then go through unchecked or are refused.
	An automatic dynamic route that does not work while the project is locked, because the lock blocks the models it classifies with, with Open route.
	Your organization’s custom models: “The lock blocks the organization’s 2 custom models.”
	Always shown: “The lock blocks Opper’s web search and web fetch tools. They send queries to search and fetch providers that are not routes in the lock.”
	Models the rules allow that have no service route, which the lock blocks.
Good to know	Always shown: “The lock does not cover calls made with an organization key and no project header.” See What a lock does not cover.

Activating and in force

Each Opper server enforces its own copy of your locks and confirms every few seconds which version it enforces. A new lock, or a new version from a replacement, reads Activating while the servers confirm it: “Every Opper server confirms a new lock before it is in force. This usually takes under a minute.” Servers enforce the lock as soon as they load it, so calls outside it can already be refused while it is activating. Once every server has confirmed it, the lock reads In force. Its Technical details give the moment it came into force: In force since, “Every Opper server enforces it.” A lock can stay Activating for up to about 45 minutes after an Opper server stops unexpectedly. Every server that has loaded it enforces it meanwhile. If it is still Activating after an hour, contact support. A server that cannot confirm its locks stops calling providers until it can. See If a server cannot confirm its locks.

What the Data processing page shows

Model access locks has one row per lock version, newest first, with the project, status, version, label, number of routes, who took the lock, and when. Replaced and released versions stay listed, so the list is also the history. Search by project or label, filter by status, and sort by date, project, status, or version.

Status	Meaning
Activating	The project is held to this version, and Opper’s servers are confirming it.
In force	Every Opper server has confirmed it and enforces it.
Replaced	A newer version replaced it.
Released	A member released it.
Project deleted	The project was deleted.
Organization deleted	The organization was deleted.
Plan downgraded	The organization moved to a plan without locking.
Released by Opper	Opper released it.

When an active lock and the project’s saved rules differ, a chip beside its status says how:

Chip	Meaning
N blocked (amber)	The saved rules allow routes the lock does not hold. The lock blocks calls to them.
N outside rules (neutral)	The lock holds routes the saved rules no longer allow. Nothing is blocked.

Select a row to open its details:

The lock. The project, the status, the version and its label, who took the lock and when, and for a version that has ended, how, when, and by whom. While the lock is activating, it says what it waits for.
How the lock and the rules differ. When the saved rules allow routes outside the lock: “The project’s saved rules allow 1 route, but the lock blocks it.” When the lock holds routes the rules no longer allow: “The rules already block 5 routes listed in this lock. Updating the lock removes them.” Each lists the route IDs, with Update lock and See rules, which opens the project’s Model access on the Rules page.
Locked routes. The number of routes, then each route under its company and legal entity, with its location, route ID, and how many of its models are available now. Each row shows the recorded training and logging facts and flags anything else to know, such as Residency not enforced or Some handling facts unknown. Open a route for every recorded fact: training, logging, moderation, caching, residency, third-party access, and sub-processors. A fact the catalog had not researched reads Unknown.
Source rules. The organization rule and the project rule as they stood when the lock was taken, in the words the Rules page uses, each with View current rule. Entitlements lists the restricted routes your organization had an agreement for.
Version history. When the project has had more than one version, every version, with who took it and how it ended. Select Open on one to view it.
Technical details. The lock ID, the snapshot hash, the catalog version, and for a lock in force, In force since. Use them to refer to this exact lock.

Source rules, Version history, and Technical details start folded. Opper never rewrites a lock. Its routes and facts stay as they were recorded, whatever changes in the catalog later. Model counts leave out models Opper has retired since.

Update a lock after a rule change

A lock and the project’s saved rules can come apart in two ways:

The rules were widened. They allow routes the lock does not hold. The lock blocks calls to those routes until you replace it.
The rules were narrowed. The lock holds routes the rules no longer allow. Nothing is blocked, since the rules refuse those routes. But a later rule change that allows them again needs no new lock, so replace the lock to bring it down to what the rules allow now.

Opper points both out in these places:

Above the Model access card on the Rules page, a notice lists each locked project whose lock and saved rules differ, for example “1 lock differs from the saved rules”. Projects whose lock blocks routes the rules allow come first, in amber: “The rules allow 1 route, but the lock blocks it.” Narrowed locks follow in neutral text: “The rules already block 5 routes listed in this lock.” Each line has Update lock, or View lock ↗ for a member who cannot update it, and the notice ends “Update lock creates a new lock version from the saved rules.” The notice is amber while the lock blocks any route the rules allow, and neutral when every difference is a narrowing.
When you save on the Rules page, Rules saved names the projects the save moved, for example “support-bot’s rules now allow 2 routes, but the lock blocks them.” or “default’s rules already block 5 routes listed in its lock. Updating the lock removes them.”, with Update lock.
In the Rules page, the project’s Model access row says how many routes the lock blocks, for example 1 route blocked by the lock, and the Lock group in its panel shows how the lock and the rules differ.
On Data processing, the lock reads N blocked or N outside rules, and its details list the routes.

A lock is taken from the saved rules, so Update lock on the Rules page is unavailable while there are unsaved changes: “Save or discard your changes first. A lock is taken from the saved rules.” A member who cannot update the lock reads who can in its place. To replace the lock, select Update lock, or open the lock’s details on Data processing and select Manage lock, then Replace lock. The Replace the lock dialog builds a new preview from the saved rules and compares it with the current version:

Row	Meaning
Adds	A route the new version holds that the current one does not.
Removes	A route the current version holds that the new one does not.
Facts changed	A route in both whose recorded facts have changed since the current version was taken.

If nothing differs, the dialog says the routes and facts are the same as the current version’s. The label starts as the current version’s. Select Replace lock to confirm. Replacing creates the next version and marks the previous one Replaced in the same step, so the project is never unlocked in between. The new version reads Activating until every Opper server has confirmed it. If another member changed the lock while the dialog was open, the dialog compares with the lock as it is now and asks you to confirm again.

Release a lock

Open the lock’s details and select Manage lock, then Release lock. The dialog names the project, the version, and how many routes the lock holds. Select Release lock to confirm. Once released, the project’s saved rules alone decide which models it can reach, including any route they allow that the lock blocked. Every Opper server picks up the release on its own, usually within a minute. The version stays in the list as Released. Releasing works on every plan.

Change rules on a locked project

Under Model access, the Rules page lists every locked project, whether or not a rule names it:

The project’s row shows locked v1 beside its name and the number of models it can call, such as 37 models. When its saved rules allow routes the lock does not hold, the row says how many in amber, such as 1 route blocked by the lock.
The project’s panel has a Lock group: “A lock holds this project to the routes it records. Rules can narrow that, not add to it.” It shows the version and label, who took the lock and when (“Locked by … on …”), the locked routes, and Can call with the number of models, followed by how many the saved rules allow when that is more. View lock ↗ opens the lock on Data processing.
A locked project with no rule of its own has a row and a panel too. The panel says “No project rule. The organization rule applies, within the lock.” and offers Narrow model access for this project.
While you edit a project rule, the model count says how many of the matching models are inside the lock. In the route picker, a route the lock does not hold is marked outside lock: “The rules allow this route, but the lock blocks it. Updating the lock allows it.” You can still pick it.
The organization rule’s panel has a Locked projects group: “Locks hold these projects to their routes. This rule can narrow them, not widen them.” Each project shows the models your draft leaves it within its lock, and in amber any routes outside the lock.
Blocked calls. In the organization rule’s panel, beside the rules’ own count, lock blocked N calls · 24h counts calls the lock refused that the rules allowed.

A change that would leave a locked project with no model it can call is not saved. The panel you saved from says “Not saved: support-bot would have no model to call.”, names the lock’s version, and links to Data processing. A save from the page’s bar says the same in a notification. Your changes are kept. To make the change, keep a model on a locked route in the rules, or replace or release the lock first. Deleting a rule is checked the same way, because a deletion can put a narrower rule in force. The same check applies to rule changes made through the Management API.

Checks on a locked project

A check that uses a model is held to the lock like any other call: it runs only on models whose routes are in the lock.

When you lock. The preview names each check that applies to the project and has no model inside the lock.
While the project is locked. Such a check does not run in the project, and the request follows the check’s On error setting: allow, the default, lets the request through unchecked, and block refuses it. Rules marks the check couldn’t run. Open it to read that a project’s Model access lock admitted none of its models, with a link to Data processing.
When you save a check. The check’s model picker offers only models the lock admits. Saving a check that could run on none of its models in a locked project it applies to is refused, with a message that names the lock and its version.

For a check a locked project must never skip, set On error to block and pick a model on one of the locked routes.

What a refused call returns

A call to a model outside the lock is refused with HTTP 403 before anything reaches a provider. That includes streaming requests: the error comes back before the stream opens. The message opens with model "<model>" is blocked by the project's Model access lock, says why, names the project and the lock’s version, and ends with a link that opens the lock in the platform:

{
  "error": {
    "code": "permission_error",
    "message": "model \"openai/gpt-4.1-nano\" is blocked by the project's Model access lock: service route \"openai/api-us\" is not one of the locked routes (project \"support-bot\", lock version 1). View the lock: https://platform.opper.ai/go?org=…&to=model-access-lock&project=…&lock=…",
    "details": {
      "docs_url": "https://docs.opper.ai/control-plane/rules/model-access-locks",
      "lock_url": "https://platform.opper.ai/go?org=…&to=model-access-lock&project=…&lock=…"
    }
  }
}

The lock is checked before the rules, so a model the rules also refuse gets this message. The reason after the colon depends on the call:

The call	Reason
Names a model on a route outside the lock	`service route "openai/api-us" is not one of the locked routes`
Names a bare model, and none of its providers is on a locked route	`none of its providers is on one of the locked routes`
Uses a custom model or your own provider credential	`it is called with your own provider credential, so it is not on one of the locked routes`
Names a model with no service route	`the model has no service route, so it is not on one of the locked routes`

Each reason is followed by the project and the lock’s version, such as (project "support-bot", lock version 1), or only the version when the project’s name is not known, then View the lock: and the link. A bare model name served by a pool, such as claude-sonnet-5, and a models fallback list skip what the lock excludes, the way Model access skips what the rules exclude. They are refused only when nothing inside the lock is left. Opper does not switch a call to another model for you. Each endpoint returns the body it returns for a rule refusal, so a client that handles one handles the other:

Endpoint	Where the code is
`/v3/compat/chat/completions`	`error.code` is `permission_error`
`/v3/compat/v1/messages`	`error.type` is `permission_error`
`/v3/compat/responses`	`error.code` is `model_not_allowed`
`/v3/compat/openresponses`	`error.code` is `model_not_allowed`
Gemini-compatible `generateContent`	`error.status` is `permission_error`
`/v3/compat/embeddings`	`error.type` is `permission_error`
Image, audio, video, and OCR endpoints	No code: `error` is the message

On /v3/compat/chat/completions, /v3/compat/v1/messages, /v3/compat/responses, /v3/compat/openresponses and /v3/compat/v1beta/interactions, error.details also carries the links: docs_url, this page, and lock_url, the link the message ends with. The other endpoints carry the link in the message only. A dynamic route that the lock stops fails with the code route_compliance_blocked, as it does for a rule. If Opper cannot read a project’s lock, it refuses every call from that project rather than letting one through unchecked, with a message that ends the lock could not be read, so every model is refused until it can be, followed by the project and the lock’s version.

See refusals in the platform

Logs shows a refused call as Blocked by project lock, under the Blocked status filter.
A call’s trace reads Blocked by the project’s Model access lock.
The model catalog and the playground’s model picker mark models outside the lock Blocked by project lock, and link to Data processing.

Check before you call

List models with the locked project’s API key and GET https://api.opper.ai/v3/models?include=policy. Each model outside the lock has "blocked_by": "lock" and the same reason as the 403:

"policy": {
  "allowed": false,
  "blocked_by": "lock",
  "reason": "service route \"openai/api-us\" is not one of the locked routes (project \"support-bot\", lock version 1)"
}

If a server cannot confirm its locks

Every Opper server confirms the locks it enforces every few seconds. A server that cannot confirm them for several minutes stops calling providers until it can, so that it never serves an out-of-date copy of a lock. This applies to every call that server receives, whether or not the project is locked. Such a call is answered with HTTP 503 and Retry-After: 5, and the message:

model "openai/gpt-4.1-nano" is refused: this server could not confirm its Model access locks, so it refuses every model until it can. No rule or lock refused this call; retry the request

Where an endpoint puts a code, the code is model_access_lock_unconfirmed, in place of its usual refusal code. For example, a chat completion returns:

{
  "error": {
    "code": "model_access_lock_unconfirmed",
    "message": "model \"openai/gpt-4.1-nano\" is refused: this server could not confirm its Model access locks, so it refuses every model until it can. No rule or lock refused this call; retry the request"
  }
}

Image, audio, video, and OCR endpoints return the message in error, with no code. A dynamic route stops with the same code. Retry the request after the Retry-After delay. Another server, or the same one once it confirms, serves it. Treat model_access_lock_unconfirmed as a temporary error, like a rate limit, and not as a refusal by your rules or your lock. Model lists keep listing the models you can use. A realtime session open on such a server is closed, and you can open a new one. Logs shows such a call as Server could not confirm locks, under the Error status filter. It names no project and has no link, because no lock refused it.

If a change has to wait

Some changes wait for any other lock change in progress: saving a rule, taking, replacing or releasing a lock, creating a custom model, deploying or rolling back a dynamic route, and deleting a project, in the platform or through the Management API. A change that waits too long is not made. It is answered with HTTP 503, Retry-After: 2, and the code model_access_lock_busy:

{
  "error": "Model access locks are busy with another change. Try again in a few seconds.",
  "code": "model_access_lock_busy"
}

When the wait was for something other than the locks, the message is “Another change is in progress. Try again in a few seconds.” Nothing was changed. Retry the request after the Retry-After delay.

When a lock ends without a release

Event	What happens to the locks
A locked project is deleted	The delete confirmation says “This also ends its Model access lock”. The lock is listed as Project deleted, and its details say Project deleted. A call or queued job of the project that is still running stays held to the lock.
The organization is deleted	While the deletion can still be cancelled, the locks stay active and enforced, and cancelling leaves them as they were. When the deletion goes ahead, every lock is released with the reason Organization deleted.
The organization moves to a plan without locking, such as Gateway	Every lock in the organization is released and listed as Plan downgraded.
The organization moves from Enterprise to Control Plane	The locks stay. Control Plane includes locking.

A downgrade to the Gateway plan also deletes every rule in the organization. With no rules and no locks, every project can call every model in the catalog.

On Enterprise, the Audit Log records each change as Locked model access, Replaced model access lock, or Released model access lock, including the releases a project deletion or a downgrade makes.

What a lock does not cover

Calls that do not run in a project. A lock belongs to a project. Calls made with an organization key and no project header do not run in a project, so no project’s lock covers them. They are held to the organization’s Model access rule alone. For example, a personal agent credential works at organization scope until you attribute it to a project. To hold calls to a lock, make them with the locked project’s API key, or attribute them to the project.
Custom models and your own provider credentials. A lock lists Opper’s routes, so a locked project cannot call a custom model or use its own provider credential.
Processing Opper runs for itself. A lock taken from 2 November 2026 has none: every model call Opper makes for the project is held by the lock. An older lock also records what Opper ran for itself when it was taken, which no rule chooses: script generation, plus Opper’s embedding model before 27 October 2026 and error rewriting before 23 October 2026. Opper runs neither script generation nor an embedding model of its own now, and does not send a locked project’s provider errors to a model to rewrite them.
Opper’s web tools. A locked project cannot use them. Opper’s web search and web fetch tools send queries to search and fetch providers that are not routes in the lock, so a request that asks for them is refused with 403 and a message that says the tool is blocked by the project's Model access lock. A model provider’s own web search is part of the model call and stays inside the lock: with engine: auto, a model that has one uses it.
What Opper stores. A lock does not change trace storage. Configure it under Opper retention.
Other projects. Each lock holds one project. There is no organization lock: to hold every project, lock each one.

FAQ

Does a lock switch my calls to another model or route?

No. A pinned model outside the lock is refused with 403. A bare model name runs only on providers whose routes are in the lock, and is refused when there are none.

How many projects can I lock?

Any number. Each project has its own lock, with its own versions.

How do I check that a lock is in effect?

On Data processing, the lock reads In force once every Opper server has confirmed it, usually under a minute after it is taken. To check from code, list models with the project’s API key and include=policy: models outside the lock read "blocked_by": "lock".

Why did a call fail with 503 and model_access_lock_unconfirmed?

The server that took the call could not confirm its Model access locks, so it refused every call for the moment. Retry after the Retry-After delay. See If a server cannot confirm its locks.

What happens when a locked route's facts change?

The lock holds routes by ID and keeps the facts as it recorded them. The route stays in the lock and calls to it go on. When you open Replace lock, the comparison lists the route as Facts changed, so you can review the facts the catalog records now and create a new lock version.

Does releasing a lock delete it?

No. Every version stays on Data processing with who took it, when it ended, and why. Only the project’s access changes.

I widened the rules and the new models still fail. Why?

The lock holds the routes it was taken from. The rules can narrow a locked project but cannot add routes outside its lock. Select Update lock to create a new lock version from the saved rules.

Can I take or release a lock from code?

No. Locks are taken, replaced, and released in the Opper platform. You can read the effect from code with GET /v3/models?include=policy.

Get started

Platform

Build

Observe & Control

Apps

Tutorials

Tooling

Model access locks

How a lock works with your rules

Who can lock a project

Lock a project

Lock from the Rules page

The readiness review

Activating and in force

What the Data processing page shows

Update a lock after a rule change

Release a lock

Change rules on a locked project

Checks on a locked project

What a refused call returns

See refusals in the platform

Check before you call

If a server cannot confirm its locks

If a change has to wait

When a lock ends without a release

What a lock does not cover

FAQ

​How a lock works with your rules

​Who can lock a project

​Lock a project

​Lock from the Rules page

​The readiness review

​Activating and in force

​What the Data processing page shows

​Update a lock after a rule change

​Release a lock

​Change rules on a locked project

​Checks on a locked project

​What a refused call returns

​See refusals in the platform

​Check before you call

​If a server cannot confirm its locks

​If a change has to wait

​When a lock ends without a release

​What a lock does not cover

​FAQ

How a lock works with your rules

Who can lock a project

Lock a project

Lock from the Rules page

The readiness review

Activating and in force

What the Data processing page shows

Update a lock after a rule change

Release a lock

Change rules on a locked project

Checks on a locked project

What a refused call returns

See refusals in the platform

Check before you call

If a server cannot confirm its locks

If a change has to wait

When a lock ends without a release

What a lock does not cover

FAQ