Restrict AI Models, Not Just Their Providers

To restrict AI models is to limit which individual models may serve your prompts, not just which vendors. Insulin’s AI Model Policy enforces the vendor half on every run; the model half has to be enforced at the provider, where OpenAI projects offer a control and the Anthropic documentation reviewed here describes none for API keys.

---

A security review that approves models rather than vendors ends with a list like Acme’s: two OpenAI models for the support agents, one Claude model for drafting, nothing else. The next question is the practical one: how do we keep every other model out?

In Insulin, the answer comes in two layers. Insulin decides which providers may serve your organization, and holds that on every run. Which of a provider’s models may run is a rule only the provider can hold, on the key you connect, and not every provider offers one. This post maps where each layer stops, and what to do where neither reaches.

Can Insulin restrict AI models, or only providers?

Only providers. The AI Model Policy is the organization setting that decides which AI providers may serve your organization. It sits under Settings → Organization → AI Model Policy, only an org ADMIN can change it, and its Allowed AI integrations list is an allow-list: “AI features may use only the integrations listed here.” An integration missing from a non-empty list fails closed, so no turn reaches an unlisted provider, not even on failover.

Each row admits everything its connection offers, and none narrows to a model:

• A model provider row, such as OpenAI or Anthropic, admits the models that connection makes available.
• An open-source model aggregator row, such as OpenRouter or Together AI, admits a catalog that can run to hundreds of models.
• A Cloudflare Workers AI or DigitalOcean GradientAI row admits that provider’s fixed set of five chat models.
• The hosted-model (DeepInfra) row admits the Fours-hosted pool. In the AI Model Policy reference’s words, the entry “pins no particular model — it admits the pool, and nothing more.”

Which rows to add, and what the hosted row and the platform-key switch change, is covered in how Insulin’s AI model allowlist decides which vendors see your prompts.

Who picks the model inside an allowed provider?

Several people, plus failover, and no list of models checks any of them. A model-level rule has to cover each place a model is chosen:

• An agent’s Default model, set by whoever can edit the agent: its Owner, or an ADMIN or EDITOR on it. An org-wide share as EDITOR hands that choice to the whole organization.
• The built-in Insulin assistant’s model, which each person picks in its model settings, the pencil in the conversation header, from the Fours-hosted models and their own providers’ models.
• Failover. Each agent “fails over automatically”: if a model call fails, the turn retries on your next connected provider, and the reply names the model that took over.
• Features with no model picker of their own, which use the organization default: the policy’s top row.

Why Insulin has no per-conversation picker at all is covered in who picks the model, and what happens when it fails.

Where can a model-level rule be enforced?

At the provider, on the credential Insulin uses, and only where the provider offers a control. Insulin enforces which providers serve a run. OpenAI projects can enforce which model IDs a key may call. In the Anthropic documentation reviewed for this post, no workspace or API-key control limits which Claude models a key can call.

Control	What it restricts	Limits individual models?	Set by	Where it stops
Insulin AI Model Policy	Which providers AI features may use, failover included; on a non-empty list, an unlisted provider fails closed	No. A row admits every model its connection offers	An org ADMIN	It names providers, not models, and not whose key a request runs on
OpenAI project model permissions	Which model IDs one project may call: allow_list permits only those listed, deny_list blocks those listed and permits the rest	Yes	An OpenAI admin, with an Admin API key	Any request sent with a different credential, a member’s own connection included
Anthropic workspaces	Each workspace’s members and API keys, its monthly spend, and its rate limits per model	No. The reviewed pages describe no model allow-list	An Anthropic organization admin	Inference hooks list model allowlists as a use, but serve Claude Enterprise conversations, not API access
OpenRouter guardrails, one aggregator’s control	A model allowlist and a provider allowlist, per member or per API key	Yes	An OpenRouter organization admin	It “enforces nothing until it is assigned”: to a member, a key or the workspace default
The hosted-model (DeepInfra) row	Whether the Fours-hosted pool may serve at all	No. It “pins no particular model”	An org ADMIN	Which hosted model serves a given turn

Where a provider offers no model control, its row is all or nothing. List it and accept every model its connection offers, or leave it off. Keep the hosted-model (DeepInfra) row only if every hosted model is on your approved list. As documented on October 14, 2026, those are DeepSeek V4 Pro as the pool’s quality tier and DeepSeek V4 Flash, GLM 5.3 Flash and Gemma 4 31B as its light tier, all from one supplier; which models serve Insulin chat and knowledge bases explains the roster. Keep an aggregator only if its own control, such as OpenRouter’s guardrails, narrows the key you connect.

How do you restrict OpenAI models for Insulin?

Restrict the OpenAI project whose API key you connect. OpenAI project model permissions are a per-project list of model IDs with a mode: allow_list permits only the listed models, and deny_list blocks them while permitting the rest. OpenAI documents setting them through its Admin API or its Terraform provider, both with an Admin API key.

1. Give Insulin its own OpenAI project. A project is OpenAI’s “workspace for keys, files, and resources,” and the permission covers one project, so a dedicated project keeps Insulin’s list apart from your other workloads.
2. Choose allow_list, and list the IDs your review approved. A deny list permits any available model nobody thought to list, including ones added later; an allow list refuses them until someone approves them. Each ID “must be visible to the organization,” fine-tuned snapshots included, and removing the Terraform resource “deletes the project’s model-permission configuration.”
3. Leave room for the rest of Insulin’s work on that key. The list applies to every model the project’s key calls, so if your knowledge bases embed with OpenAI, approve text-embedding-3-small or text-embedding-3-large as well.
4. Connect a key from that project as the organization’s OpenAI integration under Settings → Integrations, which takes an API key and an optional Organization ID. To swap a key that’s already connected, the docs have you delete the integration and create a new one. Don’t take the card’s Connected as proof the key works: for an API-key integration, the connection check confirms the key is stored, not that OpenAI still accepts it. Step 5’s test is what proves it.
5. Point each organization agent’s Default model at an approved ID, then test a refusal. Neither OpenAI guide says what a refused request returns, so call a model outside the list with the project’s key and look. In Insulin, a failed call retries on your next connected provider, so a refusal can still end in another listed provider’s answer, with a note naming the model that took over. If that provider’s models aren’t approved either, take its row off the list.

Can you restrict which Claude models Insulin uses?

Only all or nothing. In Insulin, Anthropic is one row: list it, and every Claude model its connection offers is admitted. The Anthropic documentation reviewed for this post describes nothing that narrows that for an API key:

• Workspaces hold members, API keys and limits. Spend limits cap monthly spending, and rate limits, set with Edit next to a model, cap requests and tokens per minute. Both limit volume; neither is described as a list of allowed models.
• The Admin API manages “members, workspaces, invites, and API keys.” A key carries its principal, its scope and its expiry, and nothing on the page ties it to particular models.
• Inference hooks list “model allowlists” among their uses, but they serve Claude Enterprise organizations, and “Platform organizations (API access through the Claude Platform) are out of scope.” An Anthropic API key, which is what Insulin’s organization connection to Anthropic takes, is API access.

So for Claude, a model-level rule is one people keep. Set approved Default models on organization agents, grant EDITOR by name rather than org-wide, and review usage by model. If the rule has to hold whatever people do, the setting that holds it is leaving Anthropic off the list.

Do provider-side restrictions cover members’ own keys?

No. A model restriction holds only for the credential it was set on. The built-in Insulin assistant and Personal agents “add the providers you have connected under Settings → Integrations (bring-your-own-key). They never reach the organization’s keys.” A member’s own Anthropic API key, or their own Claude Code or Codex sign-in, is a different credential from any key you restricted.

The AI Model Policy still applies to those turns, because AI features may use only the integrations on the list, but it names providers, not whose key a request runs on. If the model rule must cover personal connections, write it into your AI policy as a rule people keep, and check it in usage.

How do you check which models actually ran?

Group the Usage panel on Settings → Billing by Model, then by Provider. The usage breakdown answers “Which model was used” and “Which provider served it,” and own-key usage appears too, attributed to the provider whose key was used. A model there that your review never approved points to the layer that let it through: a provider row, a provider’s own control, or a member’s own connection.

Two caveats: the breakdown is re-aggregated every couple of hours, and a reply streamed from Cloudflare Workers AI, DigitalOcean GradientAI or Together AI on your own key may be missing from it.

Frequently asked questions

Can Insulin’s AI Model Policy restrict individual models?

No. The AI Model Policy lists providers, and AI features may use only the integrations on it. Each row admits every model its connection offers, so a rule naming specific models has to be enforced at the provider, where the provider offers a control.

How do we limit which OpenAI models Insulin can use?

Restrict the OpenAI project whose API key you connect. OpenAI’s project model permissions set an allowlist or a denylist of model IDs for one project, through its Admin API or its Terraform provider. Connect a key from that project as your organization’s OpenAI integration, then test it.

Can Anthropic restrict which Claude models an API key can call?

Not in the Anthropic documentation we reviewed. Workspaces cover members, API keys, spend limits and per-model rate limits, with no model allow-list. Inference hooks can enforce one, but they serve Claude Enterprise conversations, and API access through the Claude Platform is out of scope.

Do provider-side model restrictions cover members’ own keys?

No. A restriction holds only for the credential it was set on. Insulin’s built-in assistant and Personal agents use each member’s own connections, never the organization’s keys, so your project’s list doesn’t reach them. The AI Model Policy, which works by provider, still does.

Does the hosted-model (DeepInfra) row pin a hosted model?

No. The row admits the whole Fours-hosted pool and pins no particular model. On a non-empty list, keep it only if every hosted model is approved; leave it off and the hosted models stop being offered.

How can we check which models actually ran?

Open the Usage panel on Settings → Billing and group the period by Model, then by Provider. The breakdown is re-aggregated every couple of hours, and a streamed reply from Cloudflare Workers AI, DigitalOcean GradientAI or Together AI on your own key may be missing.

Takeaways

• Insulin’s AI Model Policy restricts providers, not models. A listed row admits every model its connection offers, and an unlisted provider fails closed, on failover too.
• Enforce a model list where the provider offers one. OpenAI project model permissions can allow-list model IDs for the project whose key you connect; test a refusal before you rely on it.
• Without a provider control, a row is all or nothing. The Anthropic documentation reviewed here describes no model allow-list for API keys, so a Claude-model rule is a review step, or a reason to leave the row off.
• A provider control stops at its credential. Members’ own connections sit outside it, so check usage by model to see what actually ran.

A model-level rule ends up applied agent by agent, in each Default model and in who holds EDITOR. To see how an Insulin agent gets its model, its connections and its audience, start with AI agents for business workflows.