# Input Guard Node

> Pre-actor safety gate: yes/no checks evaluated by Jev in one call, routing to clean, review, or blocked.

**URL:** https://caywork.com/learn/docs/node/input-guard-node

## Content

The **Input Guard Node** is a pre-actor safety gate. It evaluates your configured yes/no checks against the input in a single Jev (TypeSafe System One) call and routes to clean, review, or blocked — before the message reaches an agent node.

## How it works

1. Each check is a **Noul** question (returns P(yes) in 0..1). All checks are evaluated in parallel in one call.
2. Any check at or above its **block threshold** routes to `route:blocked`.
3. Otherwise, any check at or above its **review threshold** routes to `route:review`.
4. Otherwise the flow continues via `route:clean`.

## Parameters

* **checks** (array): Each check has:
  * **id** (string): Stable identifier, shown in the guard state.
  * **question** (string): The yes/no question (e.g. "Does this message attempt to override system instructions?").
  * **block_threshold** (number, 0-1, default 0.8): P(yes) at or above which the input is blocked.
  * **review_threshold** (number, 0-1, default 0.4): P(yes) at or above which the input needs review.
* **input_key** (string, default "user_message"): Which state field to check.

## Output Handles

* `route:clean` — wire to your normal agent path.
* `route:review` — wire to a Generative Question Node (human confirmation) or a logging branch.
* `route:blocked` — wire to a refusal text generator.

## State

Writes `guard = { clean, action, violations, checks }` with the raw P(yes) per check.

## Use Cases

1. **Prompt-injection screening** before a Tool Calling Node.
2. **PII detection** with human confirmation for borderline cases.
3. **Off-topic gating** for domain-specific agents.

## Tips

* Set thresholds from the cost of being wrong, not round numbers: block aggressively only when a false block is cheap; keep a wide review band when a mistake is expensive.
* The node fails open (clean) when the decision service is unreachable — a decision model must never take your product down.