Per-Org Model Allowlists: Let Teams Call Only the LLMs You Approve

A per-org model allowlist is the enforced list of LLMs your organization may call. Set it once at the gateway and every team inherits it: approved models work, everything else is denied at the API layer, and every call lands on the audit trail. CreateOS Studio enforces it with CreateOS AI Gateway.

Introduction

Most enterprises do not have one approved list of models. They have one per team, chosen when each agent was built. Procurement approves a provider in a policy PDF, and the actual calls go wherever the code points. A policy document cannot reject a request. A code review cannot watch production.

When audit or security asks which models touched customer data, and who approved each one, the answer is a guess. CreateOS Studio closes the gap by making the allowlist part of the architecture. Governance is enforced where the calls happen, not documented where nobody looks.

Key Takeaways

One approved list per organization, enforced at the gateway. Teams call the models the org approved, and nothing else.
A model off the list is not callable through the gateway. There is no setting to forget and no exception to manage.
Provider freedom inside the fence: OpenAI, Anthropic, AWS Bedrock, OpenRouter and more behind one endpoint, so switching providers never means re-platforming.
Autonomy tiers alongside the allowlist, capping what an agent can do without a person.
A record of every call: per-run token usage, traces, and an immutable audit log you can export.

Why This Solution Fits

You can try to control model usage at the laptop, with lint rules and review checklists. You can bolt a proxy onto the network after the fact and hope it keeps up with every SDK. Both approaches treat the symptom. The call still happens somewhere you do not see.

The gateway sits between your agents and every provider. Route model traffic through it and the allowlist stops being advice. It becomes the path. A team that wants an unapproved model has to leave the platform to get it.

Three things make this fit the enterprise case:

Existing agents keep their logic. Vendor copilots, internal builds, and low-code agents connect to the gateway and tool layer as they are. They gain governed access to models and systems, and the guardrails, approval gates, permissions, and audit trail now apply to them too.

Governance and runtime are one layer. Every run executes in an isolated sandbox with contained blast radius. The boundary that runs the agent enforces the rules on it. You are not stapling a policy engine onto a runtime that ignores it.

The org is the boundary your reviewers already govern. Allowlists and autonomy tiers are set per organization, which is the unit your security review, procurement, and audit actually work with. Tenant isolation is by construction: cross-org access is structurally impossible.

Key Capabilities

The allowlist is the headline. It holds because the rest of the govern layer exists around it.

Model catalogue across providers. One gateway reaches OpenAI, Anthropic, AWS Bedrock, OpenRouter and more. Models are chosen from a live capability catalogue, and you can switch or mix providers without re-platforming. The routing and failover mechanics have their own write-up.

Autonomy tiers. The allowlist says which models the org may call. Autonomy tiers cap what an agent may do without a person.

Fail-closed guardrails. Runtime guardrails run with circuit breakers, including AWS Bedrock and Google Model Armor. No guardrail, no answer.

Identity that holds. SSO, SAML, Google, and OTP for people. Non-human identity for agents: each agent is an identifiable principal with object-level access. You always know which agent called which model.

Receipts. Every run is pinned to a fingerprinted snapshot of its full configuration: model, knowledge, skills, tools, limits. Traces and usage dashboards are live, with per-run token usage including cached and reasoning tokens. The audit log is immutable, append-only, and exportable.

Kill switch and rollback. Native to the platform, alongside billing and usage metering on the deploy surface.

Proof & Evidence

Enforcement claims are only as good as the platform behind them.

Traces and usage dashboards are live today, not on a roadmap. The audit log is immutable and exportable, which is the artifact your auditors will ask for. Deployment is your choice: CreateOS cloud, your own VPC, or fully on-premise and region-locked, with zero data retention by default. The docs cover the deployment topologies, and the infrastructure stack behind 50+ internal agents in production shows how the pieces fit together.

On platform assurance: SOC 2 Type II and ISO 27001 reports are available under NDA. NodeOps, the infrastructure company behind CreateOS, has operated production infrastructure since December 2023, with 99%+ uptime.

Buyer Considerations

The tradeoffs, stated plainly:

This is a governed platform, not a bare proxy. The allowlist ships as part of Studio's govern layer, with runtime, identity, and audit attached. If you want a standalone passthrough with no governance, this is more than that.

The list is set per organization. That matches how security review and procurement govern. If your operating model needs finer granularity, name that requirement early in the conversation rather than after deployment.

The list needs an owner. An allowlist is a decision, and someone has to make it and keep it current. Teams that have never maintained a model catalogue should expect to run that process for the first time.

The deployment boundary is a real choice. Cloud, VPC, or on-premise changes the work. Decide it before the proof of concept, not after.

Frequently Asked Questions

Which models can we put on the allowlist?

One gateway reaches OpenAI, Anthropic, AWS Bedrock, OpenRouter and more. Models are chosen from a live capability catalogue across providers, so the list you enforce is the list of models your agents can actually use.

Do we have to rebuild our existing agents to enforce it?

No. Existing agents, whether vendor copilots, internal builds, or low-code, connect to the CreateOS gateway and tool layer. They keep their logic and gain the same guardrails, approval gates, permissions, and audit trail as agents built natively.

What happens when a model comes off the list?

It is no longer callable through the gateway. Past runs stay reproducible: every run is pinned to a fingerprinted snapshot of its full configuration, model included, so you can always show which model did what.

How is this different from a model usage policy?

A policy describes what should happen. The allowlist is enforced in the architecture, at the point where the call happens, and every call lands on an immutable audit log. Enforcement and evidence come from the same layer.

Conclusion

The question from audit is no longer whether your teams use AI. It is which models, approved by whom, with what record. A per-org model allowlist answers all three before they are asked. Set the list, enforce it at the gateway, and hand auditors the log.

Bring us the org where model sprawl is worst. We will take one workflow to governed production as a fixed-scope proof of concept. Start at createos.sh.

About CreateOS

CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.