A Celigo guardrail is an import-type flow step that evaluates each record against safety, compliance, or governance policies. For every record, it returns a structured JSON result with a deterministic decision:
-
If flagged true → the record violates the configured policy
-
If flagged false → the record does not violate the configured policy
Important
Guardrails only flag – and do not enforce – actions. Based on their output, you must then implement your own logic (stop, route, retry, skip) in the flow using standard Flow builder and API builder settings, such as branching/routing, mappings, transformations, and error paths.
Guardrails always return schema-validated structured JSON so downstream mappings remain predictable and auditable.
You can place a guardrail step:
-
Before an AI agent – Detect unsafe inputs like prompt injection signals and PII, and route records based on the flag returned
-
After an AI agent – Validate generated output before downstream mapping/export
-
Anywhere in a traditional flow or API endpoint – Apply policy checks to any record
You can also chain multiple guardrails to check data sequentially (for example: PII detection → moderation → custom policy).
At runtime, a guardrail...
-
Runs once per record
-
Shares standard import step components:
-
preMap hooks
-
Standard error handling and branching patterns, depending on your flow configuration
-
Provides visibility in runtime logs, metrics, and audit trails
Among other applications, create a guardrail step when you need to:
-
Detect unsafe or non-compliant content on a record-by-record basis
-
Add governance checks before or after AI-generated content
-
Drive deterministic routing in your flow according to structured output (flagged, reasons, triggers)
-
Capture audit-friendly evidence of policy checks (what was flagged and why)
Review the input text and determine whether it complies with company policies. Return only one of the following values: Allowed or Blocked. If blocked, briefly state why.
Each guardrail is configured for a single policy mode: Moderation, PII, or AI policy.
Checks text and images (when supported) against standard safety categories. Output indicates:
-
flagged true/false
-
triggered categories/reasons
-
confidence/score (if applicable)
Detects personally identifiable information (PII) such as email addresses, phone numbers, IDs (based on configured entities). Output indicates:
-
flagged true/false
-
detected entities/types
-
optional masked/safe representation if your implementation returns it (the guardrail itself still does not change the record automatically)
Choose a model when the guardrail type is Moderation or AI policy.
Navigate to AI studio → Guardrails to create, manage, and review guardrails.
The list view shows:
-
Name / Description
-
Type
-
Last updated
-
Actions: Click the overflow (...) menu to select any of the following actions:
-
Edit guardrail
-
View audit logs
-
Used by
-
Clone
-
Delete
-
Every guardrail step provides an in-product trace view for preview runs and runtime sessions. It typically includes:
This trace provides key details, including:
-
Guardrail Identification: The type of guardrail policy
-
Configuration: The specific thresholds or policies
-
Outcome: Whether or not the result was flagged.
-
Triggers: The specific categories or entity types that were activated.
-
Performance data: High-level information regarding timing and usage.
Note
The trace data is specific to a session and is not stored permanently.