Model Filtering
ai-gateway-model-filtering-v2
Model Filtering decides which models an app may use and creates the model selection the rest of the chain works from. Without it, an app can reach any model offered by the providers assigned to its team.
Configure each capability—completions, embeddings—in one of two modes. The modes are mutually exclusive per capability.
- An allow list exposes a curated set of models. The first entry is the default when a request names no model.
- A block list permits every available model except the ones named. Each request must name its model, because a block list supplies no default.
Models are written as providerName/model, where providerName is the provider
name configured in your gateway—for example openai/gpt-5.
What a rejected request gets
| Request | Response |
|---|---|
| A model the rules don't allow | 403, listing what's allowed |
No model named, in block list mode | 400 |
| A capability the policy doesn't configure at all | 403 |
| A provider name that isn't in the catalog | 400 |
Rejections are returned as problem details, and the detail names what the
caller should have sent—the allowed models for a blocked model, or the gateway's
configured provider names for an unrecognized one. The
Akamai AI Firewall is the exception among the
policies here: it answers in the provider's own error format instead.
Place Model Filtering first in the chain—it creates the model selection that Fallback Model and Budgets and Costs build on.
For the portal workflow see Restricting models; for every option see the generated reference. When model selection needs logic instead of a list, see Dynamic model routing.