Constraints vs. Guardrails
Constraints and guardrails operate at different layers of agent execution:Guardrails
Guardrails evaluate agent inputs and outputs against configurable safety categories. Depending on configuration, they can block content, warn users, redact sensitive information, escalate interactions, request rephrasing, or automatically sanitize responses. The following shows a typical runtime flow:Guardrail Configuration Levels
Guardrails can be configured at two levels:
Project-level policies apply in addition to agent-specific guardrails.
Use project guardrails when you want:
- Consistent governance across multiple agents.
- Shared moderation providers.
- Organization-wide safety controls.
- Centralized runtime management.
- Safety rules are specific to one agent.
- Runtime behavior must be customized locally.
- Shared project-level governance isn’t required.
Guardrail Policies
Policies are reusable governance containers that define runtime safety behavior across agents and projects. Each policy contains one or more rules. Each rule defines what to evaluate, where to evaluate it, which provider to use, and what action to take when triggered. Rules can support input and output evaluation, streaming responses, pattern matching, model-based moderation, and LLM-based classification. Go to Govern > Guardrails > Policies.Only one policy can be active per project at a time. Activating a new policy automatically deactivates the previously active one.
Policy Scopes
Project-level scope — Apply the policy to all agents in the project:Create a Guardrail Policy
- Go to Govern > Guardrails.
- On the Policies tab, click Create policy.
- Enter a policy name and description.
- Select whether the policy applies to all agents in the project or only to a specific agent.
- Configure the required rules and runtime settings.
- Click Save.
Rules
Runtime Settings
Custom Guardrail Policies
Custom guardrail policies provide centralized, organization-wide safety enforcement across agents and projects. They support reusable rules, provider-based moderation, streaming evaluation, budget controls, and scoped runtime enforcement. Custom policies support:- Project-level and agent-level scopes.
- Streaming guardrails.
- Budget controls.
- Constitution principles.
- External moderation providers.
Guardrail Providers
Providers are the evaluation engines used to classify or inspect content during runtime. They can detect unsafe content, identify PII, classify toxicity, evaluate prompt injection attempts, and perform model-based moderation. Supported provider types:- OpenAI Moderation
- Azure AI Content Safety
- Anthropic
- Lakera Guard
- Custom HTTP providers
- Custom webhook providers
- Built-in PII providers
Configure a Provider
- Go to Govern > Guardrails.
- Open the Providers tab and click Add provider.
- Configure the following fields and save.
Provider Health
The platform periodically checks provider health. When a provider becomes unhealthy, its circuit breaker activates and stops sending requests. After the reset timeout, it allows a test request through. When a provider’s circuit breaker is open, the platform follows the configured fail mode:- Fail-open — Content is delivered without guardrail evaluation. Violations may go undetected.
- Fail-closed — Content is blocked until the provider recovers. Safer, but may interrupt service.
Input Guardrails
Input guardrails evaluate user messages before they reach the LLM. Use them to detect unsafe content, identify prompt injection attempts, protect sensitive information, and enforce topic or policy restrictions. Usekind: input to evaluate user messages before they reach the LLM:
- Pattern-based detection.
- Provider-based moderation.
- LLM-based classification.
- Severity-based actions.
- Runtime priority ordering.
Output Guardrails
Output guardrails evaluate generated responses before they’re returned to the user. Use them to prevent unsafe responses, redact sensitive information, apply moderation checks, and inspect streaming output during generation. Usekind: output to evaluate generated responses:
kind: both to apply the same rule to both input and output:
- PII detection and redaction.
- Toxicity scoring.
- Streaming response evaluation.
- Bidirectional guardrails.
- Automatic response cleanup and fix strategies.
DSL and UI Mapping
The platform maintains a one-to-one mapping between the UI configuration and the DSL/ABL definition. This lets you:- Configure guardrails visually.
- Manage guardrails as code.
- Version and compare configuration changes.
- Switch between UI and DSL-based editing workflows.
GUARDRAILS: block in the DSL/ABL. Updating the GUARDRAILS: block directly in the DSL/ABL updates the same rule in the UI.
Best Practices
- Use project guardrails for centralized governance; use agent guardrails for localized runtime behavior.
- Start with
warnbefore enablingblockto understand impact before enforcement. - Test regex patterns carefully to reduce false positives.
- Enable streaming guardrails for high-risk applications.
- Use fail-closed behavior for compliance-sensitive workloads.
- Separate business constraints from safety guardrails.
- Use providers with caching and budget controls for large-scale deployments.