Model allowlist
The list of models approved for use, per organization and cost center. Default-OFF: anything not explicitly approved is refused with a 403, before tokens are spent.
Why it matters
A model allowlist is the list of what's permitted to use — per organization and cost center — instead of a list of what's forbidden. The distinction is everything. A list of prohibitions (a denylist) assumes everything is allowed until someone vetoes it; an allowlist assumes the opposite: nothing is allowed until it's explicitly approved. For governance, only the second approach is safe, because the model catalog keeps growing, and a denylist is always behind what appeared yesterday.
It matters because choosing a model isn't an innocuous technical detail: models differ in cost, in quality, in where the data is processed, and in the terms the provider offers. Leaving any model open is leaving those decisions in the hands of whoever calls, case by case, with no common criterion. The allowlist gives the decision back to the organization and applies it before the spend.
How it works
The allowlist is default-OFF: no model is available until the organization explicitly approves it. When a call requests a model that isn't on that organization and cost center's approved list, the layer refuses with a 403 — before any token is spent. The refusal is cheap and immediate, and there's no charge for a call that never reached the provider. Approving a model is a conscious, recorded action that turns that model on for that scope.
For routing, the layer uses wildcard-per-provider: it knows how to talk to any model of a configured provider, but what each organization can actually use is the slice the allowlist authorizes. Separating the two things — the technical ability to call and the governance permission — is what lets you turn models on and off by policy without touching the integration.
How Horse Labs handles it
At Horse Labs, the allowlist is global default-OFF, kept in the governance database and applied per organization and cost center. The model catalog comes live from the providers' own APIs, and approval is a conscious toggle; anything not approved is refused with a 403 before a token is spent. Routing uses wildcard-per-provider, so turning an approved model on doesn't require rewriting the integration — you just approve it in the right scope.
Common mistakes
The classic mistake is inverting the posture: starting with everything open and trying to forbid things as they show up. That denylist never catches up with the catalog, which changes faster than the review. The second mistake is treating the allowlist as a single global setting, without scope — when the right way is per organization and cost center, because the model appropriate for one team may be expensive or unsuitable for another. The third is letting the refusal be expensive: blocking after the spend, not before. A well-made allowlist refuses with a 403 before the token, not after the bill.