Govern which models a team can use

Give a team one API key, let its requests reach only the models and providers you approve, and prove it in the Playground and in Logs.

On this page

The path

Modelsenable approved models

Policiesfence, pin, or block

API keysone key per team

Playgroundtest with the key

Tracesprove it

Cloud Score governs access in three layers. The catalog decides which models exist to compete at all. Policies narrow that set per task type, capability, modality, cost band, or API key. The key a request carries decides which team it belongs to. This guide sets up all three for one team.

Layer	Where	What it decides
`Models`	Sidebar, under Gateway	Which models are in the routing pool. A disabled model is never chosen.
`Policies`	Sidebar, under Gateway as Routing policies	Per matching request: which providers are allowed or denied, whether one model is forced, a cost cap, or an outright block.
`Admin` › `API keys`	Sidebar, under Admin	Which team a request belongs to: its budget, its attribution defaults, and the id a policy can target.

Once a request has been classified, the candidates pass through these gates in this order. A forced model that is denied, not allowed, disabled, or over the cap leaves nothing to route, and the request ends no_candidates.

Enabled models

only rows switched on in Models

Match

required capabilities and context window

Allow providers

the last matching policy wins

Deny providers

unions across every matching policy

Force model

pins one model_key, scoring skipped

Max cost

drops candidates over the cap

Score

cost, latency, quality

A block happens before any of this.

When a matching policy has Block request ticked, evaluation stops at once and the request is refused before any provider is called. Blocks, budget gates, and security guards all run before the cache, so a blocked request is never served from cache either.

Models: enable only what is approved

Routing only ever chooses a model that is enabled on Models. Everything a Discover run adds arrives disabled, so the safest starting point is a short list you switch on by hand. See Models for every column.

Click Models under Gateway in the sidebar.
If the table reads No models yet. Connect a provider above and click Discover., click Discover OpenAI models (or the button for your provider) and wait for a note such as Added 57 from LiteLLM (disabled — enable to route) · updated 57.
Set Provider to one provider.
The status text reads 0 of 57 enabled. Counts and the bulk buttons scope to the rows in view, not the whole registry.
Tick the approved rows and click Enable selected.
While ticking, the status reads 2 selected; afterwards the note reads Enabled 2 models. A row's own switch (Enabled column) does the same for one model.
Disable everything else with Disable selected or Disable all.
Disable all acts on every row under the current filter. Confirm the captured model count before the writes. The note reads Disabled 12 models. Repeat per provider until the status line for each shows only the approved count.

Switch state	What it means for routing
`Enabled`	In the candidate pool, listed by `GET /v1/models`, and offered as the Optimization reference model.
Disabled	Removed from every routing decision immediately; the model's response-cache entries are purged.

Two things a Discover run can undo.

Discover disables enabled rows that LiteLLM no longer lists (the note shows · disabled: {n}), so re-check the status line after every run. And disabling the last enabled model makes every request fail with no_candidates.

Azure AI Foundry has a Discover button like every other connected provider, but it always fails with Discover failed: Azure deployments must be added manually — deployment names are specific to your resource. Azure deployments are created through the admin API instead, then enabled here like any other row.

Policies: fence, pin, or block

The catalog is workspace-wide. Policies are where one team's traffic gets narrower rules than the rest. Each policy is a set of conditions (all must match) and actions; enabled policies run in Priority order, lowest number first. See Policies for every field.

Action field	What it does	How matches combine
`Allow providers (comma-sep: openai/anthropic/gemini/grok/openrouter/together/azure/vertex/bedrock)`	Keeps only candidates from the listed provider types.	A later match replaces the list.
`Deny providers (comma-sep)`	Removes candidates from the listed provider types.	Lists union across every matching policy; a later rule can never un-deny.
`Force model (model_key)`	Pins routing to that `model_key`; scoring is skipped. The model must be enabled.	A caller's own model override takes precedence over the forced model.
`Block request`	Refuses the request before any provider is called, with `Block message` or the default `blocked by policy '{name}'`.	The lowest-numbered matching block wins; nothing after it is evaluated.

Fence a task type to approved providers.

Click Routing policies under Gateway in the sidebar, then New policy.
Give it a Name and leave Priority at 100.
Under Conditions (all must match), set Task type to code.
Under Actions, fill Deny providers (comma-sep) with openrouter, together.
Use the exact provider types from the allow-list label. The fields are split on commas and trimmed, but not validated: a misspelt type silently never matches a candidate.
Click Save policy.
The dialog closes and the row appears with its switch on.

Pin one task type to one model.

Click New policy and set a Task type.
Type the model's key into Force model (model_key), for example gpt-5-mini.
Copy the mono key from the Model column on Models. Nothing checks that the key exists or is enabled; a wrong key ends every matching request no_candidates.
Click Save policy.

Block a task type outright, with a message the caller will see.

Click New policy; set Priority to 5.
A low number runs first, so the block is decided before any other policy.
Set Task type to the type you want refused.
To refuse images instead, set Modality to multimodal. The gateway sets that modality on any request that carries an image.
Tick Block request; Block message appears. Type the message.
Without a message the caller gets blocked by policy '{name}'. The gateway reports error.type="blocked", HTTP 403 on the OpenAI-compatible endpoint.
Click Save policy.

Check the fence before any traffic

What you do: In Test against a sample, paste Refactor this Python function to remove the nested loops into Sample input and click Run test.
What Cloud Score does: Classifies the sample with the built-in heuristic rules and evaluates every enabled policy against it.
What you see: Classified code, complexity 1, the green pill Allowed, and deny: openrouter, together. A forced model shows as force → gpt-5-mini; a matching block shows the red pill Blocked: {block_message}.

What the sample test cannot show.

The panel sends no key and fixes the modality to text, so policies conditioned on API key ID (UUID), Modality = multimodal, or a Required capability never match here. Disabled policies are invisible to it. Test those with the team key in the Playground instead.

Confirm policy removal

Delete policy? names the captured policy and its version-history consequence. Cancel makes no change. Confirm removes it. To pause a rule, flip its switch off instead.

Strategies do not loosen the fence.

A caller's routing strategy changes scoring weights only. Blocks, allow and deny lists, forced models, and cost caps still bind whatever strategy the request sends.

API keys: one key per team

Every gateway request carries one platform key, and the key is how Cloud Score knows which team is calling. One key per team gives you a budget, attribution defaults, and a stable target for key-scoped policies. See API keys for every column.

Click API keys under Admin in the sidebar.
Click Create key and name it, for example billing-service-prod.
Set Monthly budget (USD, optional), for example 500. Once the calendar month's spend reaches the cap, requests on this key are refused.
Leave Store request/response bodies checked.
Logs can then show the prompt and the answer for this team's requests.
Leave Sandbox key — may hand-pick policies per request (playground) unchecked.
A sandbox key lets the Playground switch individual policies off per request. A team key must not be one: with sandbox off, every enabled policy applies to every request.
Leave Security profile on Observe (default).
Under Cost attribution defaults (optional), fill Team, Application, Environment.
For example payments, billing-service, prod. They apply to requests on this key that carry no tag of their own, so the Cost page can group this team's spend.
Click Create, then Copy in Key created, then Done.
Copy this key now — you will not see it again. Hand the key to the team; the table shows only its Prefix from now on.

Column	What the team key's row should show
`Legacy cap`	The cap as `$X.XX/mo`; `—` means no budget was set.
`Store bodies`	`on`
`Security`	The profile name with its `block: …` · `redact: …` · `log only (not enforced): …` line.
`Attribution`	Chips `team=…`, `application=…`, `environment=…`; `Edit tags` is in the row's `⋯` menu.
`Status`	`Enabled`, and no `Sandbox` badge.

Scoping a policy to this key.

A policy's API key ID (UUID)condition matches the key's UUID, and the backend refuses anything that does not parse as one. The key table's columns are Name and Prefix, not the id. Once you have the UUID, pair that condition with Set max cost ($) and Deny providers (comma-sep)to cap and fence one team's key.

Retire with Disable, not Revoke.

Disable on the row flips the badge to Disabled and gateway calls with the key fail from then on. Revoke refuses any key that has served a request with key has request history — disable it instead of deleting.

Playground: test with the team key

The Playground sends real gateway requests under whatever key you paste, so it is the honest way to see the team's fence from the team's side. See Playground for the whole page.

Click Playground and paste the team key into Platform API key.
Switch on Save for session to keep it for this tab.
Open Advanced options, then Policies.
For a non-sandbox key it reads read-only and explains Only sandbox keys can choose policies per request. Each enabled policy is listed with its #{priority}. If it read all applied, the key is a sandbox key.
Type an approved prompt in Message, keep Routing on auto, click Send.
The caption under auto reads workspace rules decide. The button reads Running… while the request runs.
Open Details › Routing and read the Policy and Select stations.
Policy reads {n} policies, the number evaluated. Select names the winning model, which must be one you enabled and one the fence allows. The decision summary under the stations repeats the model with its score.
Send a prompt that hits the block.
The Policy station reads blocked, the status badge reads Blocked, and the error above the answer and under Send shows your Block message or blocked by policy '{name}'.

Station	Reads	Meaning
`Match`	`{n} models`	Enabled models that can do this task before policies run. Zero here means the catalog, not a policy, is the problem.
`Policy`	`{n} policies`	Policies evaluated; the fence was applied and the request continues.
`Policy`	`blocked`	A block matched. No provider was called and no later station appears.
`Record`	`blocked`	The final status stored in Logs.

A forced model with a denied provider

What you do: Keep a policy that forces gpt-5-mini and another, higher-numbered, that denies openai; send a matching prompt.
What Cloud Score does: Applies the allow and deny gates first, then the forced model. The forced model is no longer a candidate, so nothing is left to route.
What you see: The request ends no_candidates rather than routing elsewhere. Fix one of the two rules; deny lists cannot be undone by a later policy.

Try the other strategies too.

Click cost or intelligence and Send again. The winning model may change within the fence, but it never leaves it.

What to check afterwards

The effect of the fence is visible wherever requests are listed. Filter by the team key first; everything else follows from that. See Logs for the full filter bar.

Click Requests in the sidebar.
In the any API key select, choose the team key.
Keys are listed as name plus prefix, for example billing-service-prod (dex_sk_AbCdE…). Every row now belongs to this team.
Scan the Model column.
Every completed row should name an approved model. To check one model, type its key into the filter whose placeholder reads model_key.
In the any status select, choose blocked.
These are the requests the fence refused. Click a row: the Request detail drawer shows the same route board with Policy at blocked. Close it with Close details.
Click Clear to drop the filters.

Where	What to look at	What it proves
`Logs`	`Status` column with the key filter set; the `blocked` status filter.	Which requests the fence refused, and that nothing routed to an unapproved model.
`Dashboard`	The `Value engine` shows blocked requests in the selected period; open `Request evidence` for rows.	A recorded refusal is visible in the selected population.
`Policies`	`Test against a sample` after every rule change.	The deny list and any block still fire on a sample prompt.
`Models`	The status line per provider, for example `2 of 57 enabled`.	No Discover run has silently changed the approved set.
`Cost`	Spend grouped by team, using the key's `Team` default.	The team's spend is attributed to the team. See Cost.

The security filter is a different 'blocked'.

The any security select also offers blocked, but that one means AI Security refused the content. Policy blocks show under the status filter.