Skip to main content

What are Guardrails?

Guardrails are WebRun’s safety mechanism for human-in-the-loop control. When the AI agent encounters a situation requiring human judgment or sensitive information, it pauses the task and triggers a guardrail. This ensures the agent never:
  • Submits credentials without explicit permission
  • Makes purchases or financial transactions autonomously
  • Proceeds when instructions are ambiguous
  • Bypasses security challenges like CAPTCHAs

When Guardrails Trigger


Guardrail Flow

When a guardrail is triggered, the workflow pauses and waits for human input:

Detection Methods

REST API (Polling):
WebSocket (Real-time):

Guardrail Response Format

Request from Agent

Response to Agent

Provide the requested information and resume the task: REST:
WebSocket:

Common Guardrail Types

1. Credentials Request

Trigger: Login form detected Agent Message: “I need login credentials to proceed” Response: Provide username and password Example:

2. Purchase Confirmation

Trigger: Checkout or payment page reached Agent Message: “Do you want me to complete this purchase? The total is $49.99” Response: Confirm or deny Example:

3. Ambiguous Choice

Trigger: Multiple valid options exist Agent Message: “Which product should I select? I see 3 options with similar names” Response: Clarify the choice Example:

4. CAPTCHA or Security Challenge

Trigger: CAPTCHA appears Agent Message: “A CAPTCHA is blocking me. Please solve it.” Response: Either solve it manually or instruct to skip Example:

Policy-Triggered Guardrails

When a session has an automation policy attached, the policy can trigger guardrails automatically. If a policy rule is set to guardrail enforcement (rather than block), the session pauses and waits for your approval, exactly like a credential or CAPTCHA guardrail. Handle policy guardrails the same way you handle any other guardrail in your integration.

How Guardrails Behave

The agent asks for clarification rather than guessing. Financial transactions, account changes, and data submissions always trigger a guardrail; the agent won’t act on these autonomously. WebRun doesn’t store credentials. You provide them on-demand when a guardrail triggers, or upfront using secrets. You can also intervene manually at any point, even if no guardrail has triggered. For unattended automations, guardrails can also be answered through a connected chat user (Telegram, WhatsApp, Slack, Discord, Teams) on the session’s environment, so a scheduled task can pause and wait for a human reply over chat instead of failing. This is controlled per-session via the reachOutMode parameter ("off", "guardrail_only", or "full"), which defaults to "guardrail_only". See Handling Guardrails.

Handling Guardrails in Code

Basic Pattern (REST)

Advanced Pattern (WebSocket)


Automated Guardrail Handling

For common scenarios, you can build automated guardrail handlers:

Avoiding Guardrails with Secrets

If you know the credentials the agent will need ahead of time, you can provide them upfront using the secrets parameter. This lets the agent authenticate automatically without triggering a guardrail or pausing the task.
Secrets are never stored; they exist only in the session’s memory and are discarded when the session ends. Secrets guide

Secrets

Provide credentials upfront to avoid guardrails

Handling Guardrails

Implementation guide with examples

Manual Interaction

Take manual control of sessions

Tasks

Understanding task lifecycle

Automation Policies

Runtime rules that can trigger guardrails automatically