Ask Joget AI

Webhook Guard

Introduction

The Webhook Guard sends content to an external HTTP endpoint for safety evaluation and blocks, redacts, or redirects based on the response that endpoint returns.

Note
You need an HTTP(S) endpoint that is reachable from the Joget server. The endpoint must accept a JSON POST request and return a JSON response with a "safe" boolean field. No model setup in AI Central Config is required.

What it does

The Webhook Guard intercepts content at two points during an agent run. Before the main LLM receives the user's messages, the guard POSTs the message content to your endpoint. After the main LLM produces a response, the guard POSTs the response text. Both calls carry the same JSON structure:

\{"content": "...", "direction": "input|output", "runId": "..."\}
 Your endpoint evaluates the content and returns a JSON response. The guard reads the "safe" field:

If "safe" is true, the agent continues normally.
If "safe" is false, the guard applies the action you configured: Block, Sanitize, or Redirect.

The response may also include two optional fields:

Field	Purpose
`"reason"`	A string logged for audit and debugging.
`"sanitized"`	Replacement text used when the action is Sanitize. If absent, the guard uses the original content.

On any network error or non-200 HTTP status, the guard fails open: it logs a warning and lets the request through without blocking.

When to use it

Use a Webhook Guard when the safety decision must be made by an external system rather than a local rule or model.

Typical scenarios include the following:

Corporate DLP integration: In a customer portal agent, route all content through the corporate Data Loss Prevention system before the LLM sees it.
Third-party moderation API: In a public-facing agent, call a commercial content moderation service (such as Azure Content Moderator or AWS Comprehend) on every interaction.
Audit and compliance logging: In a financial services agent, send all inputs and outputs to a compliance log endpoint that both checks and records every exchange.

When not to use it

If the content follows a known format, use the Rule-Based Guard instead. It requires no external infrastructure and adds zero latency.
If you want a semantically-aware safety check without building an endpoint, use the LLM Safety Check.
The guard fails open on network errors. A slow or unreliable endpoint does not block the agent; it passes all content through. Do not rely on this guard as the only control on an unreliable network.

Get started

How to use it

To use the Webhook Guard Element, follow these steps:

Locate the Webhook Guard element under the Decisions section in the palette.
Drag and drop the element into the Drop a guard to here section.

Configure Form Properties

To properly integrate and configure the webhook guard, set the following fields:

Personalized Names: Specify a name for the webhook guard.
Purpose: A label describing what this guard instance does. Not sent to the endpoint. A plain-language description, for example, Corporate DLP check.
Webhook URL: The HTTP(S) endpoint that receives content for evaluation. The full URL of your safety endpoint, for example, https://compliance.example.com/check. The endpoint must be reachable from the Joget server. This is a required field.
API Key: A bearer token sent in the Authorization header. The token value. Leave blank if the endpoint is unauthenticated. Stored encrypted.
On Violation (Required): What happens when the endpoint returns "safe": false. Select Block, Sanitize, or Redirect
- Redirect Task ID: This setting only appears when Redirect is selected. The task to jump to when a violation is detected. Enter the ID of an existing task in this agent. This is a required field.

Endpoint contract

Your endpoint must meet the following requirements for the guard to work correctly:

Accept Content-Type: application/json POST requests.
Return HTTP 200 on success.
Include "safe": true or "safe": false in the JSON response body.

The following optional response fields are recognised:

Field	Type	What the guard does with it
`"reason"`	String	Logged for audit. Not exposed to the user or the agent.
`"sanitized"`	String	Used as replacement content when the action is Sanitize. If absent, the original content is preserved.

Samples

Minimal safe response from the endpoint

{"safe": true}

Violation response with reason and sanitised replacement

{"safe": false, "reason": "PII detected: credit card number", "sanitized": "[Content blocked by compliance policy]"}

Best Practices

Fail-open is intentional. A network error, timeout, or non-200 response causes the guard to pass content through, not block it. This prevents an endpoint outage from halting all agent runs. Build your endpoint to be highly available if blocking is critical.
If "safe" is absent in the response body, content passes. The guard defaults to true when the field is missing. Your endpoint must be explicitly set "safe": false to trigger a violation.
Set a short HTTP timeout on your endpoint. The guard does not impose its own timeout. A slow endpoint adds that latency to every agent interaction, on both input and output.
Both input and output are sent separately. The "direction" field in the payload tells your endpoint whether it is evaluating an incoming message or the LLM's output. Your endpoint can apply different rules for each direction.
The "sanitized" field gives your endpoint control over redaction text. In Sanitize mode, the value of "sanitized" becomes the new content. This lets the endpoint return a context-appropriate message rather than a generic placeholder.

Created by Debanraj Ravindran Last modified by Debanraj Ravindran on Jul 08, 2026