Access controls
Every control that decides who can call what, from account-level defaults down to a single key.
Several controls decide who can call what. Each sits at a different level and answers a different question. This page maps them.
At a glance#
| Question | Control | Where you set it |
|---|---|---|
| Who in my team can do what in the console? | Roles | Members |
| Which models can this one key call? | Allowed models | API key |
| Which addresses can use this key? | IP allowlist | API key |
| When does this key stop working? | Expiry | API key |
| What may upstream providers do with my data? | Data policy | Per request, or account default |
| Which providers or regions serve my requests? | Provider routing | Per request |
| How much can be spent? | Budgets | Workspace or member |
| Who can use a private model? | Private model access | Granted to the account by us |
Budgets are the only control about how much money. Everything else on this list is about what is allowed.
Account defaults#
Account defaults apply to every request in the organization or personal space, without any change to your code. There is one: the data-policy floor.
Open the console, click the gear next to the account name at the bottom of the sidebar, and look under Access defaults. Organization admins and personal-space owners can change it. See Data policy for what each level means and what happens to models that do not qualify.
A request can be stricter than a default, but never looser.
Key restrictions#
Restrictions on a key apply only to that key: allowed models, IP allowlist, and expiry. Use them to limit the damage if a key leaks, and to give a service only what it needs. See API keys.
Private models#
Some models are not listed publicly. They are available only to accounts we have granted access. A granted account sees the model in its model list and can call it like any other, at the same price as the public catalog. An account without access gets the same error it would get for a model that does not exist.
Three things to know:
- Access is granted to an account: an organization or a personal space. It covers every member of an organization.
- It does not carry over. An organization you create does not inherit access from your personal space, and the reverse.
- It works alongside a key's allowed-models list. If a key is limited to specific models, the private model must be on that list too.
To request access to a private model, contact your account manager or support.
How a request is checked#
A request must pass every check below. Failing any one stops it:
- The key: enabled, not expired, owner still a member, and any restrictions met.
- The account's data-policy floor, combined with any
providerfields on the request. Whichever is stricter wins. - Budgets: the workspace's budget and the key owner's member budget. The first to reach its limit stops the request.
- Wallet balance: there must be credit available.
Spend limits return a 402. A data-policy or availability mismatch returns a 503. See Errors & rate limits.