Configuring Guardrails

A guardrail is a safety and compliance check applied to data flowing through a Celigo integration. Guardrails are stored as imports with adaptorType: "GuardrailImport" and accessed via the /v1/imports API, but they have a dedicated page in the Celigo UI.

Guardrails handle three concerns:

• Data validation -- check records against rules before they reach downstream systems (PII detection, content moderation, or custom AI-based evaluation)
• Confidence tuning -- control sensitivity via confidenceThreshold (0 to 1, default 0.7). Lower values catch more issues but increase false positives
• PII masking -- optionally return a redacted copy of the record (pii.mask: true) under a masked response field. Masking is NOT automatic -- see PII: mask vs flag

No _connectionId is required unless using BYOK credentials for the ai_agent type. Platform-managed credentials cover most use cases.

Guardrails are used across flows, APIs, and tools.

Guardrails Flag, They Don't Enforce

The most important runtime semantic to internalize before designing a guardrail: a guardrail produces a verdict; it does not act on the record. Whether a flagged record gets blocked, routed to a review queue, dropped, retried, or forwarded with the verdict attached is decided by the parent's routing, branching, or filter structure -- the parent being a flow, an API endpoint, or a Tool -- not by the guardrail itself. The guardrail's job ends at "here is the structured JSON verdict"; everything downstream is the parent's responsibility.