Guardrails

Guardrails let you flag, block or replace specific patterns in input, output, or both during inference. Use guardrails to make sure your Deployments handle sensitive or unwanted data consistently.

Guardrails support the following safety handling patterns:

• Pattern matching with regular expressions
• Blocking, flagging, or replacement
• Direction control (input, output, or both)
• Multiple guardrails on the same Deployment

Create a guardrail

To create a guardrail:

1. In your Workspace, go to the Guardrail page.
2. Click + Create.
3. Enter a unique name for the guardrail.
4. Select a guardrail type: regex or deployment. For the deployment type, see Using a deployment as a guardrail.
5. If you select regex, provide a custom regular expression or choose one of the default options.
6. Enter a replacement string. The default value is ****.
7. Choose whether to apply the guardrail to input, output, or both.
8. Click Save.

Default regex options

The following default regex options are available:

• Email: matches email addresses. Use this to identify and mask email addresses before storing or displaying data.
• Inline event handler: detects inline event handlers in HTML. Use this for HTML sanitization.
• Prompt injection: matches prompt injection attempts. Use this to detect and neutralize manipulative prompts.
• Script tags: matches entire <script> tags in HTML. Use this for HTML sanitization.

Using a deployment as a guardrail

When you select deployment as the guardrail type, the guardrail uses another Deployment endpoint (models designed to detect sensitive patterns) to decide if it was triggered. The endpoint must return a guardrail_triggered value.

Optionally, for masking-type deployment guardrails, the endpoint should also return the full transformed input body.

The Deployment response must follow this schema:

{
	"type": "object",
	"required": ["guardrail_triggered"],
	"properties": {
		"guardrail_triggered": {
			"type": "boolean"
		}
	},
	"additionalProperties": true
}

The following example shows a standard guardrail response:

{
	"guardrail_triggered": true,
	"other-properties": "value"
}

The following examples show a masking deployment guardrail. This is the raw input:

{
	"key":"value-pre-mask"
}

This is the masking guardrail response:

{
	"guardrail_triggered": true,
	"key":"value-post-mask"
}

danger

If the Deployment response doesn't include guardrail_triggered as a boolean, the request fails with a schema validation error.

Recommended setup:

1. Select a Deployment endpoint dedicated to guardrail processing.
2. Verify the endpoint behavior with representative examples before attaching it to production traffic.
3. Keep the guardrail Deployment stable and versioned so behavior changes are controlled.
4. Monitor prediction logs after rollout to confirm the output matches expectations.

Use a guardrail in a Deployment

You can apply guardrails when you create a new Deployment or update an existing one:

• When creating a Deployment, select the guardrails you want in the Deployment details step.
• To update guardrails for an existing Deployment, go to the update details page and select the desired guardrails under the safety section.

You can apply multiple guardrails at the same time.

Configure deployment guardrails effectively

When configuring guardrails at the Deployment level, choose input guardrails, output guardrails, or both based on your use case:

• Input guardrails: sanitize or block unsafe prompts before they're processed.
• Output guardrails: sanitize or block unsafe model responses before they're returned.
• Input + output guardrails: enforce end-to-end filtering across both directions.

Recommended Deployment workflow:

1. Start with flag mode to verify match quality and avoid unexpected blocks.
2. Review prediction logs to validate real traffic behavior.
3. Enable block mode only for patterns that must be strictly denied.
4. Re-test after guardrail changes and after model updates.

View guardrail usage in prediction logs

You can see which guardrails were applied to input and output in the prediction logs. This helps you track how guardrails affect your data during inference.

note

Prediction logs show the original request and response from the model, before any guardrails are applied. However, when you use an input guardrail, the model receives the validated (guardrail-processed) input. If you use an output guardrail, the response returned to you is also the validated output.

Beware

When your model has both input and output guardrails, the model works with the guardrail-processed input, not the original input. If the model's response includes portions of the input text, it contains the already-filtered version. This happens because the model never sees the original unfiltered input.

note

For batch requests, the applied guardrails shown are the ones applied anywhere in the batch.