Running Checks with Guardrails
Use the checks endpoint to evaluate messages against input and output rails without generating a completion. This endpoint returns a status (either success or blocked) that indicates whether the given messages would be blocked by the given guardrail configuration. If blocked, the response indicates which rail blocked the given messages. You might use the checks endpoint for the following:
- Testing guardrail configurations — Validate that a configuration blocks or allows specific messages before deploying it to production.
- Pre-screening user input — Check messages in your application pipeline before forwarding them to an LLM, letting you control routing, logging, or user feedback independently of inference.
- Post-hoc output auditing — Evaluate previously generated responses against your rails without re-running inference.
The checks endpoint is a standalone Guardrails API for evaluating messages against rails without running inference. For inference with guardrails applied automatically, use a VirtualModel with guardrails middleware.
Model field
The model field is only consulted by self-check rails (which need a main LLM to evaluate the prompt). The checks endpoint never runs the main model for generation. Task models (content_safety, topic_control, etc.) are resolved from the guardrail configuration as usual.
Prerequisites
Create a guardrail configuration that includes self-check input and output rails.
Check an Existing Configuration
Reference a stored configuration by name.
CLI
curl
Python SDK
Example Output
Debug Results
The checks endpoint supports the same guardrails.options.log diagnostics as
guardrailed inference. Use these fields to debug scenarios where a check blocks or passes unexpectedly. For field descriptions, see Log Options.
Check an Inline Configuration
Provide the configuration inline to test a guardrail configuration before saving it.