> For the complete documentation index, see [llms.txt](https://docs.ebbot.ai/ebbot-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ebbot.ai/ebbot-docs/core-capabilities/automations/workflow-nodes/guard-nodes.md).

# Guard Nodes

Check workflow inputs and generated answers, then route execution based on the result.

Guard nodes let you check inputs and generated answers before your workflow continues. Use them to detect prompt attacks, check for unsafe content, or verify that an AI-generated answer is supported by its source material.

With Guard nodes, you can:

* Check incoming text before sending it to an LLM.
* Check generated answers before using them in subsequent actions.
* Choose between **Prompt guard**, **Content guard**, and **Hallucination guard**.
* Define separate paths for **Not triggered** and **Triggered** results.

## Guard types

| Guard type              | Use it to                                                                            |
| ----------------------- | ------------------------------------------------------------------------------------ |
| **Prompt guard**        | Check incoming text for attempts to manipulate the LLM’s behaviour.                  |
| **Content guard**       | Check incoming text or generated answers against content categories or custom rules. |
| **Hallucination guard** | Check whether an AI-generated answer is supported by its source material.            |

{% hint style="info" %}
Each Guard node performs one type of check. To apply multiple checks, add multiple Guard nodes to your workflow.
{% endhint %}

## Configuration guide

1. Add a **Guard** node from the **System** section in the workflow builder.
2. Connect it to the preceding node.
3. Select a **Guard type**.
4. Configure the content to check.
5. Connect the **Not triggered** and **Triggered** branches to the appropriate next steps.

{% hint style="info" %}
For text inputs, you can select an output from a connected upstream node or compose text using variables.
{% endhint %}

## Prompt guard

A Prompt guard checks incoming text for attempts to manipulate the LLM’s behaviour, such as instructions to ignore its original prompt or perform an unintended action.

Place it **before the LLM node** that will process the text.

### Text to check

**Required.** Provide the text you want to inspect. Typical inputs include:

* A customer’s support ticket.
* An incoming email.
* A message submitted through a form.
* Text received through a webhook.

### Example: Check an incoming ticket

In a ticket-classification workflow, select the incoming ticket description as **Text to check**.

* Connect **Not triggered** to the LLM node that classifies the ticket.
* Connect **Triggered** to an alternative path, such as flagging the ticket for review.

## Content guard

A Content guard checks text against content categories or custom rules. Use it to check incoming content before an LLM processes it, or to check an AI-generated answer before sending it.

### Text to check

**Required.** Provide the text you want to inspect. For example, select an incoming message or the text output from an LLM node.

### Role

Specify whose text is being checked. For example:

| Role        | Use for            |
| ----------- | ------------------ |
| `user`      | Incoming messages. |
| `assistant` | Generated replies. |

Leave this field empty to use the default role, `user`.

### Content categories

Select the categories you want the guard to check. Leave the selection empty to check **all categories**.

<details>

<summary>Available content categories</summary>

* Violent Crimes
* Non-Violent Crimes
* Sex Crimes
* Child Exploitation
* Defamation
* Specialized Advice
* Privacy
* Intellectual Property
* Indiscriminate Weapons
* Hate
* Self-Harm
* Sexual Content
* Elections

</details>

### Custom categories

Use **Add custom category** to define additional content rules for your workflow. Each custom category requires:

* **Category code**
* **Name**
* **Description**

{% hint style="info" %}
Write descriptions that clearly define what should trigger the category.
{% endhint %}

## Hallucination guard

A Hallucination guard compares an AI-generated answer with source material to identify claims that are unsupported by, or disagree with, that material.

Use it **after an LLM node** and **before an action that sends or uses the answer**.

### Answer

**Required.** Provide the generated answer you want to check. Typically, this is the text output from a preceding LLM node.

### Source context

**Required.** Provide the source material the answer should be based on. Examples include:

* Relevant knowledge-base content.
* Retrieved documents.
* Product information or policy text.
* Data returned by an integration.

{% hint style="info" %}
Supply the relevant source content, rather than the generated answer itself. The guard uses this material as the reference for its check.
{% endhint %}

### Question

**Optional.** Provide the original question that the answer responds to. This gives the guard additional context when evaluating the answer.

### Sensitivity

Sensitivity controls how strictly the guard evaluates the answer against the source context. Available settings are:

* **Service default** — uses **Permissive** sensitivity.
* **Restrictive**
* **Cautious**
* **Permissive**
* **None**

If the check is too strict for your use case, try a more lenient sensitivity. To disable the check without removing the node or changing your workflow layout, select **None**.

## Branching

Guard nodes have two outgoing branches. Connect these to define what happens after the check.

| Branch            | Next step                                                            |
| ----------------- | -------------------------------------------------------------------- |
| **Not triggered** | Continue along the path for content that does not trigger the guard. |
| **Triggered**     | Follow an alternative path, such as flagging a ticket for review.    |

{% hint style="warning" %}
If the selected branch is not connected to another node, the flow ends at the Guard node.
{% endhint %}

A triggered result does not automatically send a fallback message or create a review task. Configure the **Triggered** branch with the actions you want the workflow to take.

## Example: Check a support reply before sending it

In this example, an LLM generates a support reply using knowledge-base content. A Hallucination guard checks the answer before it is sent to the customer.

{% stepper %}
{% step %}

### Retrieve the source material

Retrieve the knowledge-base content relevant to the customer’s question.
{% endstep %}

{% step %}

### Generate an answer

Use an LLM node to generate a reply based on that source material.
{% endstep %}

{% step %}

### Configure the Hallucination guard

Add a Guard node after the LLM node and select **Hallucination guard**.

| Field              | Value to use                                           |
| ------------------ | ------------------------------------------------------ |
| **Answer**         | The generated reply from the LLM node.                 |
| **Source context** | The knowledge-base content used to generate the reply. |
| **Question**       | The customer’s original question (optional).           |
| **Sensitivity**    | The setting appropriate for your use case.             |
| {% endstep %}      |                                                        |

{% step %}

### Connect the branches

* **Not triggered:** Continue to the action that sends the reply.
* **Triggered:** Flag the ticket for review.
  {% endstep %}
  {% endstepper %}

```
Receive customer question
  ↓
Retrieve knowledge-base content
  ↓
Generate reply with an LLM node
  ↓
Hallucination guard
  ├── Not triggered → Send reply
  └── Triggered → Flag ticket for review
```

{% hint style="info" %}
Place the action that sends the reply after the Guard node so the check happens before the customer receives it.
{% endhint %}

## Node outputs

Guard results are available to downstream nodes. The available fields depend on the selected guard type.

| Guard type              | Output keys                             |
| ----------------------- | --------------------------------------- |
| **Common outputs**      | `guardType`, `triggered`, `blocking`    |
| **Prompt guard**        | `ok`, `reason`, `confidenceScore`       |
| **Content guard**       | `categories`, `safetyLevel`             |
| **Hallucination guard** | `reason`, `level`, `disagreementClaims` |

Type-specific details may vary depending on the result returned by the guard service.

## Related documentation

* [LLM Nodes](/ebbot-docs/core-capabilities/automations/workflow-nodes/llm-nodes.md)
* [Workflow Security and Prompt Injection](/ebbot-docs/core-capabilities/automations/workflow-security-and-prompt-injection.md)
* [Safe Guards](/ebbot-docs/core-capabilities/ebbotgpt/ebbotgpt-configurations/security-and-guardrails/safe-guards.md)