Restrict Providers and Models

Use access key configurations to control which providers and models an access key can call. The gateway checks restrictions before it routes a request upstream. That means a request can fail fast if a client asks for a provider or model the key shouldn’t use.

What you’ll need

An access key.
An access key configuration.
The provider IDs and model IDs you want to allow.

Allow specific providers

Use provider restrictions when an access key should only call certain providers.

{
  "access": {
    "providers": {
      "allow": ["openai", "anthropic"]
    }
  }
}

With this configuration, requests can only route to OpenAI or Anthropic.

Allow specific models

Use model restrictions when an access key should only call certain models.

{
  "access": {
    "models": {
      "allow": ["openai/gpt-4o", "anthropic/claude-sonnet-4-6"]
    }
  }
}

Model entries accept three forms:

Entry	Matches
`gpt-4o`	The model on any provider that serves it
`openai/gpt-4o`	The catalog ID (author and model). Matches that model on any provider that serves it, including resellers such as OpenRouter
`openai:openai/gpt-4o`	That model on the `openai` provider only

Use the provider: prefix when you always want to use that provider. Combine model rules with a provider allowlist to block resellers.

Allow providers and models together

Combine provider and model restrictions when you want a key to stay within a small set of approved providers and models.

{
  "access": {
    "providers": {
      "allow": ["openai", "anthropic"]
    },
    "models": {
      "allow": ["openai/gpt-4o", "anthropic/claude-sonnet-4-6"]
    }
  }
}

Requests outside the allowed providers or models are rejected before they reach an upstream provider.

How this works with fallback

Every model in a fallback request must be allowed.

{
  "model": "openai:gpt-4o",
  "models": ["anthropic:claude-sonnet-4-6"],
  "messages": [{"role": "user", "content": "Hello"}]
}

If the primary model is allowed but the fallback model isn’t, the gateway drops the fallback and names it in the Ngrok-AIG-Rejected-Models response header. The request fails only when none of the models you listed are allowed.

Virtual models

Model restrictions apply to the models in a virtual model, not to its name. To let a key use a virtual model, allow the models in it. The gateway skips each model the key can’t use and names it in the Ngrok-AIG-Rejected-Models response header. You can’t add a virtual model name to access.models.allow. The API rejects it with the message 'chat-default' is a virtual model. Add its models to the key instead.

Common patterns

Goal	Configuration
Allow only OpenAI	Allow provider `openai`
Allow only Claude Sonnet	Allow model `anthropic/claude-sonnet-4-6`
Give a team access to two providers	Allow both provider IDs
Block expensive models	Allow only approved model IDs
Limit a custom provider	Allow the custom provider ID and model IDs

Next steps

Access key configurations: Full configuration flow
Choose a model: Use model IDs in requests
Configure fallback models: Use allowed fallback models

Concepts

Getting Started With

SDKs

Agents

Guides

Observability

Examples

Reference

API Reference

What you’ll need

Allow specific providers

Allow specific models

Allow providers and models together

How this works with fallback

Virtual models

Common patterns

Next steps

​What you’ll need

​Allow specific providers

​Allow specific models

​Allow providers and models together

​How this works with fallback

​Virtual models

​Common patterns

​Next steps

What you’ll need

Allow specific providers

Allow specific models

Allow providers and models together

How this works with fallback

Virtual models

Common patterns

Next steps