Input guardrails overview

  • Updated

Input guardrails give Optimizely Opal administrators and agent builders control over what users ask Opal. The rules apply however users reach Opal, including chat, integrations, and autonomous triggered agents. You define rules in plain language, and Opal trains a classifier to enforce them automatically. When a request breaks an active guardrail, the user sees a block message instead of a response. The block message is either a static message you configure or a contextual explanation Opal generates automatically.

Use input guardrails to keep a customer-facing chatbot on topic, protect confidential data, or restrict an agent to a single department's scope.

What input guardrails do

Input guardrails provide the following capabilities:

  • Natural-language rules – Define policies in plain language. No code or regular expressions required.
  • Automated training – Opal generates training data and trains a classifier based on your rules.
  • Instance-level enforcement – Activate a guardrail to apply it across your entire instance.
  • Per-agent enforcement – Assign specific guardrail versions to individual specialized agents for targeted control.
  • Adjustable sensitivity – Fine-tune classification thresholds after training with High, Medium, or Low sensitivity to balance strictness and permissiveness.
  • Curated training data – Review and edit the generated training examples before training for higher accuracy.
  • Custom or dynamic block messages – Configure a static block message, or leave it blank to let Opal generate a contextual explanation for each blocked message.
  • Version history and restore – Browse previous versions and restore any prior version without retraining.

How input guardrails work

Input guardrails follow a create-train-activate workflow. Each step builds on the previous one.

  1. Create – Write a rule in natural language and name the guardrail.
  2. Train – Start the training pipeline, which decomposes the rule into atomic policies and builds a classifier.
  3. Review and tune – Review the generated training data, adjust sensitivity, and test the guardrail against sample messages.
  4. Activate – Apply the guardrail across your instance, or assign it to a specialized agent.

For the full procedure, see Create and train an input guardrail. Then Activate an input guardrail for your instance or Assign an input guardrail to a specialized agent.

When to use instance-level and per-agent input guardrails

Use an instance-level input guardrail to apply one baseline policy across your Opal instance without configuring agents individually. Use a per-agent input guardrail when a specific specialized agent needs its own policy. 

The two are independent. A specialized agent enforces its own guardrail whether or not an instance-level guardrail is active, so you can pair a broad default with targeted per-agent rules.

The following examples demonstrate when each type fits:

  • Use an instance-level guardrail to block requests for legal, medical, or financial advice across your instance.
  • Use an instance-level guardrail to enforce professional-language standards for every user.
  • Use a per-agent guardrail to give a customer-facing agent stricter limits than an internal one.
  • Use a per-agent guardrail to keep a marketing agent from answering engineering, Human Resources, or finance questions.

See Write effective input guardrail rules for example rules.

Key considerations

  • Versioning – Each change to a guardrail creates a new version. Opal preserves previous versions and makes them available to restore.
  • One active guardrail per instance – Only one guardrail is active at the instance level at any time.
  • Maximum of five policies per guardrail – Opal decomposes your rule into up to five atomic policies. Keep rules focused to stay within this limit.
  • Training data quality – Reviewing and curating training examples before training improves classification accuracy. Editing examples creates a new draft version that you must retrain.
  • Fail-open enforcement – A classification error never blocks a user from sending a message. The system fails open by design.
  • Character limits – The guardrail name allows 255 characters, the rule text allows 10,000 characters, and the block message allows 1,000 characters.

Related documentation

Learn more about input guardrails in the following articles: