Guardrails
Rules that travel with a key: which providers it may reach, what it may spend, and what it may send.
A guardrail is a named set of rules that you attach to one or more API keys. Every request made with those keys is checked against it before it reaches a provider. Owners and admins create and edit guardrails under Guardrails in the console.
How guardrails apply
- A key belongs to at most one guardrail of its own. Assigning it to another guardrail moves it there; the console shows the current guardrail next to each key before you save.
- Your organization also has a default guardrail. Its model-access rules are the switches on the Privacy page (see Maximum privacy), and they act as a floor: a key's own guardrail can tighten them but never lift them.
- A key without a guardrail of its own follows the default guardrail.
- Guardrails apply to every endpoint and also after a routing policy has expanded into its models.
Model access
Model access decides which providers and models a key may reach.
| Rule | Effect |
|---|---|
| Zero data retention only | Only providers with a contractual zero-retention commitment. |
| Block training | Only providers that contractually exclude training on your data. |
| Sovereign only | Only providers rated strict (EU-owned and rated sovereign by Kontinent). |
| § 203 StGB only | Only providers that have signed a confidentiality undertaking under § 203 StGB. |
| Allow all except | A block list: the listed providers and models are excluded, everything else is allowed. |
| Block all except | An allow list: only the listed providers and models are allowed. |
If a model has several routes, the routes that break a rule are skipped and the request is served by one that complies. Only when no route is left does the request fail with 403 model_access_blocked, and the message names the rule. A 200 therefore does not mean a rule was ignored: check the served model and provider in the logs.
While you edit a guardrail, the console shows how many providers and models are still reachable with your rules, so you can see a too-strict combination before you save it.
Budget
A guardrail can carry a spend limit per day, week or month. All keys attached to the guardrail draw from one shared pot, which is what sets it apart from the per-key limit. Once the pot is empty, the keys return 429 spend_limit_exceeded until the window resets. See Budgets & spend limits.
Prompt-injection scan
The scan checks every message of a request, tool results and pasted documents included, for well-known injection patterns:
- attempts to override previous instructions,
- requests to reveal the system prompt,
- forged chat-template delimiters such as
<|im_start|>or[INST], - jailbreak personas ("you are now DAN", "developer mode"),
- statements that the operator's rules no longer apply.
| Setting | Effect |
|---|---|
| Disabled | No scan. |
| Flag | The request goes through unchanged and is marked Flagged in the logs, with the rule that matched. Use it to find out whether your legitimate traffic trips a rule before you block. |
| Block | The request is refused with 403 prompt_injection_blocked, and the message names the rule that matched. |
The patterns are deliberately narrow, so ordinary prose rarely matches. They catch the naive attempt, not a determined attacker: treat the scan as one layer of defence, not a wall.
Sensitive information
The sensitive-information policy looks for personal and confidential data in a request before it leaves Kontinent. You pick the patterns:
| Group | Patterns |
|---|---|
| Contact | email address, phone number, postal address, IP address, URL |
| Finance | IBAN, BIC, credit card number, VAT ID |
| Identity | German tax ID (Steuer-ID), social security number, health insurance number, ID card number, license plate, date |
| Names | person, location, organization |
| Setting | Effect |
|---|---|
| Disabled | No check. |
| Flag | The request goes through unchanged and the match is recorded. |
| Redact | Matches are replaced with a placeholder before the request is forwarded, so the provider never sees the original value. |
| Block | The request is refused with 403, and the message names the pattern that matched. |
Refused requests in the logs
Requests refused by a guardrail appear in the logs with their status, so you can see how often a rule fires. They cost nothing. Every change to a guardrail is written to the audit log.