What Is a Model Catalog? Governing Which LLMs Your Teams Can Use

Ask a platform lead how many distinct LLMs their company is paying for right now and you will usually get a pause, then a guess. The honest answer is often "more than we think," because any engineer with a credit card and an API key can wire a new model into a service in an afternoon. Each of those integrations is a separate bill, a separate set of credentials, and a separate path for sensitive data to leave the building, none of it visible from one place.

A model catalog is the control that closes that gap. It is the single, governed answer to the question "which models are our teams allowed to call, and under what rules?" Not a spreadsheet of approved vendors, an enforced list where each entry carries the policy that applies to it.

This post defines the model catalog precisely, draws the sharp line between a catalog and a model registry (they get conflated constantly), explains why sprawl is dangerous and expensive, and shows how a catalog implemented in a gateway attaches real policy to a logical model name.

Want a governed catalog of approved models with per-model budgets and policy? Book a demo.

What a model catalog actually is

A model catalog is a curated set of logical model entries. Each entry has two halves.

The first half is the binding: a logical name (say, summarizer-prod) mapped to one or more real targets (a specific provider, model version, and endpoint). This is the same indirection a logical/virtual model name gives you, applications call the name, not the raw provider.

The second half is the policy attached to that entry:

• Access: which users and teams may call it (enforced with RBAC).
• Budget: a spend cap over a period, after which calls are refused or throttled.
• Rate limits: requests or tokens per minute per user, team, or model.
• Data residency: which region the model may run in, so prompts do not cross a geographic or legal boundary.
• Guardrails: which checks run on input and output, PII redaction, prompt-injection detection, secret scanning.

An entry is "in the catalog" only once both halves exist. That is the distinction between a catalog and a list of model names in a wiki: the catalog enforces, because the policy travels with the entry and is applied on every call.

Because the policy binds to the logical name rather than to application code, changing it is a one-place operation. Tighten a team's budget, swap the underlying model version, add a PII guardrail, and every service calling that logical name inherits the change on the next request. No redeploys, no hunting through repositories for hardcoded model strings.

Model catalog vs model registry: not the same thing

This is the single most important clarification in the article, because the terms are used interchangeably and they refer to completely different systems.

A model registry (think of the artifact registries in MLOps tooling) manages trained-model artifacts. Its unit is a model you produced: a set of weights, with versions, lineage back to the training run and dataset, metrics, and a lifecycle (staging, production, archived). You use a registry when your data scientists train models and you need to track, promote, and deploy those artifacts reproducibly.

A model catalog manages access to models your teams consume, most of which you did not train, like third-party LLM APIs and open-weight models you serve. Its unit is an approved, policy-bound entry. You use a catalog to control who can call which model, at what cost, in which region, under which guardrails.

The confusion is understandable because both deal with "models," but they answer different questions. One asks "which version of the fraud model did we deploy, and from which training run?" The other asks "is the support team allowed to send customer data to this LLM, and are we over budget this month?" A mature platform often has both, and they sit at different layers.

If you take one thing from this section: a registry is about the supply of models you build; a catalog is about the governed demand for models your teams use. Picking the wrong one for a governance problem leaves you with a beautifully versioned artifact store and no control over the OpenAI bill.

Why ungoverned model sprawl is dangerous

Without a catalog, model usage grows organically, which sounds healthy and is actually the problem. Three failure modes follow, and they compound.

Shadow models. An engineer adds a new provider to ship a feature. It works, so it stays. No one approved it, security never reviewed it, and it is not in any inventory. Multiply by every team over a year and you have a fleet of unknown integrations, each a potential data-exfiltration path, that no single person can enumerate. You cannot govern what you cannot see.

Surprise bills. When every service holds its own API key, spend is distributed across provider invoices with no common tags. The monthly bill arrives as one large number, and nobody can answer "which team drove the 40% increase?" without a forensic exercise. Cost that cannot be attributed cannot be controlled, which is the entire premise of FinOps for AI.

Compliance gaps. This is the one that ends careers. An ungoverned integration sends EU customer data to a model running in a US region, violating a residency commitment. Or raw prompts containing PII reach a provider with no redaction in the path. Or an application leaks a secret into a prompt and it is logged provider-side. Each gap exists because there was no enforcement point between the application and the model.

The common root cause is the absence of a chokepoint. Direct app-to-provider wiring means there is no single place to see usage, attribute cost, or enforce policy. A catalog, implemented at a gateway, reintroduces that chokepoint without taking model choice away from teams, they still self-serve, but from an approved, governed set.

See how TrueFoundry attaches access, cost, and residency policy to every model. Book a demo.

How a catalog in a gateway attaches policy to a model name

The catalog is only as useful as its enforcement, and enforcement is why it belongs in the AI gateway rather than in a document. Structurally this is the same chokepoint an LLM proxy provides: every request passes through one place, so policy can be applied on every call.

Here is what happens on a single request when the catalog lives in the gateway. A service calls the logical model support-assistant. The gateway:

1. Authenticates and authorizes. It checks, via RBAC (backed by SSO and SCIM-provisioned identities), that the calling user's team is on support-assistant's access list. Not allowed, request refused.
2. Checks budget and rate limits. It verifies the team is under its spend cap and within its per-team token rate limit. Over the limit, it returns HTTP 429 instead of forwarding, so a runaway loop cannot run up the bill.
3. Applies input guardrails. It runs the configured checks, PII redaction, prompt-injection detection, secret scanning, before the prompt leaves the gateway.
4. Resolves residency and routes. It selects a target that satisfies the entry's data-residency region, then routes to it.
5. Applies output guardrails and records usage. It checks the response, then logs cost, tokens, and latency for the request, tagged by user, team, and model, for attribution and observability.

Every one of those steps references the entry's policy, not code in the calling service. That is the point. The application sends a name; the gateway enforces everything the name is bound to. Change the binding (new model version) or the policy (lower budget, added guardrail) in the catalog, and the next request obeys it, no application change required.

This also makes the catalog the natural home for the controls documented across governance tooling. Rate limits and budgets are detailed in LLM token rate limiting and budgets; the attribution that makes budgets meaningful is in LLM cost attribution and team budgets; the safety checks are in AI guardrails; and residency enforcement is in data residency. The catalog is where those policies get attached to specific models, and it slots into the broader set of AI governance tools.

TrueFoundry implements exactly this: a model catalog where each logical model name carries its access control, budget, rate limits, residency, and guardrails, enforced at the gateway on every request, with per-request observability tagged by user, team, and model. Because the data plane can run in your own VPC, on-prem, or air-gapped, residency is not a promise on a dashboard but a property of where the traffic physically flows.

A worked catalog entry

Concretely, the entry for support-assistant might read: logical name support-assistant, backed by a specific provider model version; access limited to the Support and CX teams; budget 2,000 USD/month; rate limit 50,000 tokens/minute per team; residency pinned to the EU; guardrails PII redaction and prompt-injection detection, on for both input and output. A developer on the Support team calls support-assistant and gets a governed model with zero knowledge of the provider, the region, or the limits. A developer on another team calling the same name is refused. That is self-service and governance at the same time.

A sample catalog

Here is what a small but realistic catalog looks like. Each row is one logical entry; the columns are the policy bound to it. Figures are illustrative.

Read across any row and you can answer, for that model, every governance question: who, how much, how fast, where, and how safely. Read down a column and you can audit a single dimension across all models, for example, "which models are pinned to the EU?" That two-way legibility is what a catalog buys you and what a pile of scattered API keys can never provide.

Where teams get this wrong

Confusing a catalog with a registry. Teams stand up a model registry, version everything beautifully, and still cannot control who calls the OpenAI API or what it costs, because a registry governs artifacts you train, not access to models you consume. Decide which problem you have before picking a tool.

Treating the catalog as a static list. An approved-models page in a wiki is not a catalog; it is documentation that nobody enforces. The value is enforcement on every request. If the list does not block an unauthorized call or a prompt that violates residency, it is a suggestion, not a control.

Attaching policy to application code instead of the model name. Hardcode a budget check or a region in each service and you have scattered, inconsistent, un-auditable policy that drifts the moment someone forgets to add it. Bind policy to the logical model in the catalog so every caller inherits it and changes propagate in one place.

Governing cost but not data. Budgets and rate limits are the easy half. The expensive failures are compliance ones, data crossing a region, PII reaching a provider unredacted. A catalog that controls spend but not residency and guardrails leaves the career-ending gaps open.

No per-request attribution. If usage is not tagged by user, team, and model at the point of the call, budgets are unenforceable and the monthly bill is a mystery. Attribution has to happen where the request flows, at the gateway, not be reconstructed later from provider invoices.

Conclusion

A model catalog turns "which models are we allowed to use, and under what rules?" from a question nobody can answer into a governed, enforced list. Each entry is a logical model name carrying its own access control, budget, rate limits, residency, and guardrails, and because the policy binds to the name, you change it in one place and every caller obeys. Crucially, a catalog is not a model registry: one governs access to models you consume, the other versions artifacts you train.

The reason to implement it in a gateway is enforcement. A list in a wiki documents intent; a catalog at the chokepoint every request passes through actually refuses the unauthorized call, throttles the over-budget team, keeps EU data in the EU, and redacts the PII before it leaves. That is how you give teams self-service access to models while keeping cost, access, residency, and safety under control, instead of discovering the gaps on the invoice or in an audit.

Govern which models your teams can use from one catalog. Book a demo.