Skip to main content
This page covers what happens after a guardrail is created and attached: the moment-by-moment behavior during a live conversation.

How a guardrail becomes available

When a conversation starts, the backend fetches every active guardrail attached to that agent and embeds it into the agent’s dispatch config:
event_messages only appears if response_message was set on the guardrail; callback_url only appears if one was configured. This happens once, at conversation creation. See When updates take effect. From there, the LLM decides, turn by turn and based on the guardrail’s prompt/description, whether a given user message warrants calling it. Nothing in the platform forces this check; it’s LLM judgment, same as any other tool.

The three outcomes

A triggered guardrail is never silent. The user always hears something. Which of these three happens depends entirely on how the guardrail is configured, not on anything the LLM decides:

The verdict field

If the moderation path fires (path 2), verdict has no fixed schema. It’s a raw pass-through of whatever the moderation endpoint returns:
  • Valid JSON response → parsed and passed through as-is.
  • Non-JSON response → wrapped as {"raw": "<the raw text>"}.
  • The check itself fails → an error dict instead, such as {"error": "check request failed"} or {"error": "<exception message>"}.
Nothing in the platform inspects verdict’s contents. There’s no automatic “if flagged, block” logic anywhere in the pipeline. It’s handed to the LLM as a tool result, and whether the agent refuses, warns, or continues normally is entirely up to the LLM’s own judgment and your system prompt, not something TruGen enforces for you.

The webhook event

This is a separate mechanism from the agent-level callback_url / callback_events system documented in Event Callbacks. That system is an opt-in list of pipeline events (call_ended, tool_call, etc.) configured once per agent. A guardrail’s callback_url is configured per guardrail, is not part of callback_events, and fires automatically, with no opt-in list, any time that specific guardrail triggers.
If a guardrail has callback_url set, a guardrail_triggered event is POSTed there every time it fires, regardless of which of the three outcomes above occurred:
Delivery is fire-and-forget: no retries, and failures are swallowed silently. If callback_url isn’t set on a guardrail, nothing gets posted anywhere for it: not to this endpoint, not anywhere else. That’s expected behavior, not a bug. Don’t build logic that assumes guaranteed delivery; treat this as a best-effort notification, not an audit log.

What’s Next?

Event Callbacks

The separate, agent-level webhook system this is easy to confuse with.

Attach to Agents

Wire a guardrail to an agent, and know when changes take effect.