Guardrails

Guardrails protect your organization by automatically detecting and blocking harmful content in LLM requests before they reach the model.

Overview

Guardrails run on every API request, scanning message content for:

• Security threats (prompt injection, jailbreak attempts)
• Sensitive data (PII, secrets, credentials)
• Policy violations (blocked terms, restricted topics)

When a violation is detected, you control what happens: block the request, redact the content, or log a warning.

Organization and Project Scopes

Guardrails are configured for the whole organization by default, and every project uses that configuration.

A project can opt out and define its own guardrails instead — useful when one application needs stricter or looser rules than the rest of the organization. Turn off Use organization guardrails in the project's Guardrails settings, and that project's configuration and custom rules fully replace the organization's for its traffic.

Exactly one scope is ever in force for a request:

Opting out never inherits partially: the organization's custom rules stop applying to that project too, and the project starts with a copy of the organization's current settings so nothing is silently dropped at the moment you opt out. Other projects are unaffected either way.

Both pages state which scope wins. A project page names itself and, while it inherits, shows the organization settings read-only; the organization page lists any projects that override it, so it is clear those settings apply everywhere else.

Only organization owners and admins can change guardrails, at either scope.

System Rules

Built-in rules protect against common threats:

Prompt Injection Detection

Detects attempts to override or manipulate system instructions. Common patterns include:

• "Ignore all previous instructions"
• "You are now a different AI"
• Hidden instructions in encoded text

Jailbreak Detection

Identifies attempts to bypass safety measures:

• DAN (Do Anything Now) prompts
• Roleplay-based bypasses
• Instruction override attempts

PII Detection

Identifies personal information:

• Email addresses
• Phone numbers
• Social Security Numbers
• Credit card numbers
• IP addresses
• Passport and driver's license numbers

When the action is set to redact, PII is replaced with placeholders like [EMAIL_REDACTED].

Detection is validated rather than purely pattern-based, so identifiers that only look like PII are left alone: card numbers must pass the Luhn checksum, phone numbers need grouping separators or a nearby phone keyword, and passport and license numbers need a nearby keyword. A bare numeric id such as a product id, order number or unix timestamp is therefore never redacted as a phone number.

Secrets Detection

Detects credentials and API keys:

• AWS access keys and secrets
• Generic API keys
• Passwords in common formats
• Private keys

High-entropy checks and placeholder filtering keep ordinary content out of the way: git SHAs and hex digests are not treated as AWS secrets, and template values such as YOUR_API_KEY, ${OPENAI_API_KEY} or ******** are not treated as credentials.

File Type Restrictions

Control which file types can be uploaded:

• Configure allowed MIME types
• Set maximum file size limits
• Block potentially dangerous file types

Document Leakage Prevention

Detects attempts to extract confidential documents or internal data.

Configurable Actions

For each rule, choose how to respond:

Custom Rules

Create custom rules for your use case, on the organization or on a single project:

Blocked Terms

Prevent specific words or phrases from being used:

• Match type: exact, contains, or regex
• Case-sensitive matching option
• Multiple terms per rule

Custom Regex

Match patterns unique to your organization:

• Internal project codenames
• Customer identifiers
• Domain-specific sensitive data

Topic Restrictions

Block content related to specific topics:

• Define restricted topics
• Keyword-based detection

Security Events Dashboard

Monitor all guardrail violations with a dedicated dashboard:

• Total violations — Overall count and trends
• By action — Breakdown of blocked, redacted, and warned
• By category — Which rules are being triggered
• Detailed logs — Individual violations with timestamps and matched patterns

How It Works

Request → Guardrails Check → Action Based on Rules → Forward to Model (if allowed)
                ↓
           Log Violation

1. Request received — API request comes in with messages
2. Scope resolved — The project's own guardrails if it overrides, otherwise the organization's
3. Content scanned — All text content is checked against enabled rules
4. Violations detected — Matches are identified and logged
5. Action taken — Based on rule configuration (block/redact/warn)
6. Request proceeds — If not blocked, the (potentially redacted) request continues

Best Practices

1. Start with warnings — Enable rules in warn mode first to understand your traffic patterns
2. Review violations — Check the Security Events dashboard regularly
3. Tune custom rules — Adjust blocked terms and regex patterns based on false positives
4. Layer defenses — Use multiple rule types together for comprehensive protection

Get Started

Guardrails are an Enterprise feature. Contact us to enable Enterprise for your organization.