Endpoint
Fields
There are no length limits on
name, category, prompt, or response_message; all stored as unbounded text.
Example
201 Created):
The
key. The server derives a URL/LLM-safe slug from name at creation time: lowercased, spaces and punctuation replaced with underscores (e.g. "Hate Speech Filter" becomes hate_speech_filter). If that slug collides with one already in your workspace, a numeric suffix is appended (hate_speech_filter_2). This key is permanent: renaming the guardrail later via PUT never changes it, and it’s the identifier the running agent uses as the tool name.Validation rules
Listing guardrails
200 OK), a plain array (not wrapped in a data key), scoped to your workspace only. category, response_message, and callback_url come back as "", never null, when unset:
There’s no
GET /ext/guardrail/{id}. List-all is the only read endpoint today.Updating a guardrail
PUT /ext/guardrail/{id} is a full replace of every client-settable field, not a partial patch. Send the complete body, not just the field you’re changing.
200 OK): { "id": "dfbaa3c6-1e90-43df-869a-b023896a198c", "message": "Guardrail updated" }
key is never changed by an update, even if name changes.
Deleting a guardrail
200 OK): { "id": "dfbaa3c6-1e90-43df-869a-b023896a198c", "message": "Guardrail deleted" }
Writing an effective guardrail prompt
prompt is the only signal the LLM has for deciding whether to call this guardrail. Vague prompts get missed or over-triggered. Use the pattern:
[who] [is doing what] [under what condition]Too vague:
prompt competes with every other tool and instruction the LLM is weighing on a given turn. Specificity is what makes it win that competition reliably. It also has to be reachable in the first place: see Reliability depends on your prompt for why the system prompt still needs to tell the agent to use its guardrails at all.
What’s Next?
Attach to Agents
Wire this guardrail to one or many agents.
Runtime Behavior
What happens the moment a guardrail fires.