Skip to main content
A guardrail is a reusable usage policy that controls:
  • Model access: which providers and models can be called.
  • Rate limits: how many requests can be made over a given period.
  • Member budget: a spending cap for a member over a period (see Budget cap).
You create a guardrail once, then attach it to a role, a member, or an individual API token. For example, one team can be limited to a curated set of models, a shared token can be capped to a low request rate, or a member can be given a monthly spending cap.
Guardrails are part of the advanced organisation features. See plans and pricing for availability.

​
Creating a guardrail

1

Open Guardrails in Settings

In the Eden AI dashboard, go to Settings and, under Organization, select Guardrails.
2

Create a new guardrail

Click + Create Guardrail and give it a Name and an optional Description.
3

Set a rate limit (optional)

In the Rate Limit field, enter a limit in the form N/period, for example 10/minute. Leave it blank to inherit the rate from the next level up. See Rate limits below.
4

Restrict models (optional)

Turn on Enable model rules to control which models can be used, then define your allow/deny rules. See Model rules below.
5

Set a member budget (optional)

Enter a Budget amount and a period (daily, weekly, or monthly) to cap how much a member can spend. See Budget cap below.
6

Save

Click Create Guardrail. It now appears in your guardrails list, ready to assign.

​
Model rules

When you enable model rules, a guardrail uses a default action plus a list of exceptions:
  • Default: allow or deny every model unless a rule says otherwise.
  • Rules: each rule targets a model by pattern and sets its action to allow or deny. Rules are checked in order and the first match wins; if none match, the default applies.
Patterns can target a single model or a whole provider: Each rule can optionally be scoped to specific features (e.g. only llm/chat, or only image/generation). A request that hits a deny rule is rejected.
Two common setups:
  • Allow-list: set the default to deny, then add allow rules for only the models you permit.
  • Deny-list: set the default to allow, then add deny rules for the models you want to block.

​
Rate limits

The rate limit uses the format N/period, where period is second, minute, hour, or day:
Leave the rate limit empty on a guardrail to inherit it from the next level up (role → organisation default).

​
Budget cap

A guardrail can cap how much a member spends over a recurring period. In the Create/Edit Guardrail dialog, turn on Member budget (“Cap each member’s spend across all their API keys”), then set a Budget amount (in USD) and a Per period: Both fields are set together — a budget needs a period, and a period needs an amount. Leave them empty to apply no spend cap. How it behaves:
  • Per member, not shared. The cap applies to each member the guardrail resolves to individually — it is not a shared pool across the team.
  • Soft cap. The check happens before each request. A request already in flight can push spend past the cap; the next request is the one that gets blocked. The limit is a spending guardrail, not a hard cutoff mid-request.
  • Counts real usage only. Sandbox calls and calls made with your own provider keys (BYOK) don’t count toward the budget. Refunds credit it back.
The budget only applies when a guardrail is attached to a role or a member. A budget set on a guardrail that is attached to an API token is ignored — use a token budget to cap a single key instead.

​
Assigning a guardrail

A guardrail does nothing until it’s attached to something. You can assign it to:
  • A role: from Settings → Roles & Permissions, so everyone with that role inherits the policy.
  • A member: from Settings → Members, to apply it to one person.
  • An API token: to constrain a single key (for example a shared or CI token).
When a request comes in, Eden AI resolves the policy per field, most specific wins:
For model rules and rate limit independently, Eden AI uses the value from the most specific level that has it set, and inherits the rest. So a token can override the model rules while still inheriting its role’s rate limit. The member budget resolves differently: only the member and role levels are considered (token budgets are handled separately, on the token itself), and the budget amount and period are always taken together from the most specific level that sets them — they are never mixed across levels.
Guardrails can also be managed programmatically through the User Management API if you need to automate provisioning. See the API Reference for the guardrails endpoints.