GuardRail Engines Overview
Guard rails are validation and enforcement policies that run alongside node execution. They check conditions before execution (Pre phase) and after output is produced (Post phase). A guard that returns Blocked in the Pre phase prevents the executor from running entirely.
What Guard Rails Do
Guard rails enforce cross-cutting constraints that should not live inside individual executors:
- Rate limiting — prevent a node from executing too frequently per tenant or user
- Token quota — cap AI token usage across an execution or tenant
- Input validation — check required fields or schema before the executor runs
- PII detection — scan output data for personally identifiable information
- Circuit breaker — stop execution if an external service is repeatedly failing
- Timeout enforcement — ensure a node cannot run longer than a configured limit
Engine Discovery
All IGuardRail implementations are discovered by the IGuardRailsExecutor at startup. The executor receives the collection of registered guards via DI and runs them in phase order (Pre → executor → Post). Guards declare which phase(s) they participate in via SupportedPhases.
Built-In Guards
| Guard | Phase | What It Does |
|---|---|---|
RateLimitingGuard | Pre | Limits requests per second per scope (global/tenant/user) |
InputValidationGuard | Pre | Validates required input fields against a schema |
TimeoutGuard | Pre + Post | Tracks execution time and blocks if timeout exceeded |
PiiDetectionGuard | Post | Scans output data for PII patterns (email, credit card, etc.) |
CircuitBreakerGuard | Pre | Opens circuit after consecutive failures, blocks until cooldown |
Fail-Open Design
The guard infrastructure is designed to fail-open: if a guard throws an unexpected exception, the executor logs a warning but continues execution. This prevents a misconfigured or buggy guard from blocking all workflow executions. Only explicit GuardRailCheckResult.Blocked results stop execution.