Skip to main content
Use access key configurations to control which providers and models an access key can call. Restrictions are checked before the gateway 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

​
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"]
    }
  }
}
Use the provider and model in the access rule so the gateway knows exactly which upstream model is allowed.

​
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 is not, the fallback model can’t be used.

​
Common patterns

GoalConfiguration
Allow only OpenAIAllow provider openai
Allow only Claude SonnetAllow model anthropic/claude-sonnet-4-6
Give a team access to two providersAllow both provider IDs
Block expensive modelsAllow only approved model IDs
Limit a custom providerAllow the custom provider ID and model IDs

​
Next steps