A model catalog is the list of model ids a platform can serve; model access control is the policy that decides which of those ids a given project key may call. This guide is for engineers who treat “it appears in /v1/models” as “we are allowed to use it.”
Menu ≠ permission. On ATP, list endpoints describe the platform; project allowlists enforce access and return 403 when violated (models, how it works). Confusing the two is a quiet driver of post-go-live bill spikes.
Two questions every request must answer
| Question | System | Bad shortcut |
|---|---|---|
| Does the platform know this model? | Catalog / routing | Assume docs = prod rights |
| May this project call it? | Allowlist | Trust client config only |
| Can this project afford it? | Credits / caps | Ignore until invoice |
Why catalogs look like permission
SDKs print friendly model lists. Marketplaces celebrate breadth. Without a gateway check, any string in model= is a purchase order. Governance platforms separate discovery from authorization so finance and security can answer “who may use Opus-class models.”
Designing allowlists
- Default deny for frontier ids.
- Per project, not per human (one project, one key).
- Change control — widening allowlist is a logged admin event (monitoring).
- Pair with caps (spending caps).
- Document for app teams — 403 means policy, not outage (errors).
By use case
Customer-facing bots: small stable set.
Internal agents: mid-tier + optional frontier project.
Eval sandboxes: wider list, tiny allocation.
A more modern approach
Spreadsheets of “approved models” rot. Runtime allowlists on the project do not. ATP Token sets allowed models per project; every key inherits them; unauthorized calls never reach providers.
Resources / projects → · Quickstart →
FAQs
What is the difference between a model catalog and model access control?
A catalog lists models a platform can route. Access control is the per-project (or per-key) policy that allows or denies those models at request time.
Why does my API return 403 for a model I see in the docs?
Documentation and list endpoints often show the platform menu. If the model is not on your project allowlist, a governance gateway rejects the call before upstream.
Should every project allow frontier models?
No. Default mid-tier models for high-volume paths; enable frontier models only for projects with budget and a written reason.
How do model allowlists reduce AI cost?
They prevent silent upgrades to expensive models in application code. Cost control still needs spending caps; allowlists remove accidental premium routing.
Where should model policy live—code or platform?
Platform enforcement survives client bugs and forks. Code can default wisely; the gateway must be the final authority.
Further reading
Discovery inspires; permission protects.
