Security Nodes

Security nodes add protective layers to your workflows. Use them to guard against prompt injection attacks, redact sensitive information, enforce content policies, validate data schemas, and require human approval before critical actions execute.

All Security Nodes

GuardrailSecurity

Apply configurable safety rules to data flowing through your workflow. Detects prompt injection, redacts PII, filters content, validates JSON schemas, checks semantic similarity, and runs custom rules.

Human ApprovalSecurity

Pause workflow execution and wait for one or more human approvers. Configurable approval policies (ANY or ALL), timeout durations, and data preview for approvers.

Guardrail

The Guardrail node inspects data passing through the workflow and applies configurable safety rules. Each rule can detect, flag, or block problematic content before it reaches downstream nodes or external systems.

Built-in Checks

Check	Description
Prompt Injection Detection	Identifies attempts to manipulate LLM behavior through injected instructions. Uses pattern matching and heuristic analysis to flag suspicious prompts.
PII Redaction	Detects and redacts personally identifiable information including email addresses, phone numbers, SSNs, credit card numbers, and names.
Content Filtering	Screens content for profanity, hate speech, violence, and other policy violations using configurable sensitivity levels.
JSON Schema Validation	Validates data against a JSON Schema definition. Ensures structured data conforms to expected formats before processing.
Semantic Similarity	Compares input text against a set of reference texts using embedding-based similarity. Flags content that is too similar to (or too different from) expected patterns.

Custom Rules

Beyond built-in checks, you can define custom rules using four different rule types:

Rule Type	Description	Example
REGEX	Match content against a regular expression pattern.	`\\b(password\|secret\|token)\\b`
KEYWORD_LIST	Check for the presence of specific keywords or phrases from a list.	`drop table, rm -rf, sudo`
JAVASCRIPT	Run a JavaScript function that returns true (pass) or false (fail).	`(input) => input.length < 10000`
LLM_PROMPT	Send data to an LLM with a custom evaluation prompt. The model decides if the content passes or fails.	"Does this text contain medical advice?"

Severity Levels

Each rule is assigned a severity that determines what happens when the rule is violated:

Severity	Behavior
LOG	Record the violation in execution logs but continue execution normally. Useful for monitoring and auditing.
WARNING	Log the violation and attach a warning to the execution output. Downstream nodes can inspect warnings and take conditional action.
BLOCK	Immediately halt execution with an error. The workflow stops and no downstream nodes execute. Use for critical safety violations.

Guardrail configuration

// Example: Guardrail configuration
{
  "checks": [
    { "type": "PROMPT_INJECTION", "severity": "BLOCK" },
    { "type": "PII_REDACTION", "severity": "WARNING", "redactWith": "[REDACTED]" },
    { "type": "JSON_SCHEMA", "severity": "BLOCK", "schema": { ... } }
  ],
  "customRules": [
    {
      "name": "No SQL keywords",
      "type": "KEYWORD_LIST",
      "keywords": ["DROP TABLE", "DELETE FROM", "TRUNCATE"],
      "severity": "BLOCK"
    },
    {
      "name": "Max length check",
      "type": "JAVASCRIPT",
      "code": "(input) => input.length <= 5000",
      "severity": "WARNING"
    }
  ]
}

Layer guardrails

Place Guardrail nodes at multiple points in your workflow -- before sending user input to an LLM, after receiving LLM output, and before writing data to external systems. Defense in depth is key.

Human Approval

The Human Approval node pauses workflow execution and waits for one or more designated approvers to review and approve (or reject) the pending action. This is essential for high-stakes operations like financial transactions, data deletions, or production deployments.

Approval Policies

Policy	Behavior
ANY	Execution continues as soon as any single approver approves. One rejection does not block if another approver has approved.
ALL	Execution continues only when every designated approver has approved. A single rejection from any approver stops the workflow.

Features

Configurable approvers -- specify users or teams who can approve the action.
Timeout -- set a maximum wait duration. If no approval is received before the timeout, the workflow fails or takes a configurable fallback action.
Data preview -- approvers see a summary of the pending action, including relevant data from upstream nodes, so they can make an informed decision.
Notification -- approvers are notified via email or in-app notification when their approval is requested.
Audit trail -- every approval or rejection is logged with the approver's identity, timestamp, and optional comment.

Timeout behavior

Always configure a timeout for Human Approval nodes. Without a timeout, the workflow execution will remain paused indefinitely, consuming resources and potentially blocking other workflows.

Communication

Third-Party