Turn on a guardrail
Enable a check in Protect's guardrail catalog and set how it behaves.
Every check in Protect’s guardrail catalog starts out switched off. This guide flips one on end to end, using PII Detection configured for a support agent as the running example: enable it, configure it, and push it live. The same steps apply to any other check in the catalog.
This guide assumes Agent Command Center, where Protect’s guardrails live under Gateway, is already set up with at least one provider connected. If it isn’t yet, start with the Agent Command Center Quickstart.
Find the check in Rules
Go to Gateway > Guardrails > Rules. The Rules tab lists the full guardrail catalog as a list of check cards, split between AI-Powered Checks and Rule-Based Checks. PII Detection sits under Rule-Based Checks; find its card there. Each card carries a Switch and a pencil icon button.
Turn it on
Click the Switch on the PII Detection card. This only stages the change: it’s what raises the unsaved-changes banner covered in Push the change to the gateway below, and nothing reaches the gateway until you save there. How the check behaves is set separately, from the pencil.
Set how it behaves
Click the pencil icon button on the card to open the check’s dialog, then set:
- Enabled: leave it on (it mirrors the card’s Switch, so it already matches what you just set)
- Action: set to Block
- Confidence Threshold: leave at its default of 0.8
For provider-backed checks, the dialog also has a Provider Settings section (see the note below). It always has Cancel and Save buttons. For what action and threshold actually do to a request, see Understanding Protect.
Click Save to close the dialog.
Note
If the check calls out to an external provider, Provider Settings is where that check’s own provider connection lives (not the model provider connected during Agent Command Center setup). PII Detection’s dialog has no Provider Settings section, so skip it. (See Guardrail checks for which checks are provider-backed.) For a check that does use a provider, a credential you’ve already saved shows up masked; click into the field and it clears, ready for you to enter a new one.
Push the change to the gateway
Nothing you set in the check’s dialog reaches the gateway until you save here. Back on the Rules tab, an info banner now reads “You have unsaved changes. Save to push guardrail config to the gateway.”, with Reset and Save & Activate buttons. This Reset discards the unsaved changes shown in the banner, not the check’s saved configuration. It’s a separate control from the Reset button that appears on a check’s card once the check has been customized: that one clears the customization, switching the check back off and its action and threshold back to the defaults (Block, 0.8). Click Save & Activate; while the save is in flight the button reads Saving….
Confirm it in Overview
Switch to the Overview tab. The row shows up as pii-detector, enabled, and its Stage column reads Before LLM (before any guardrail is enabled, this tab reads “No guardrails configured” instead).
Confirm the stage
Click the row’s Edit icon button to open Edit Guardrail: pii-detector. Stage already shows Pre, matching the Before LLM you just saw in Overview; this dialog is where you’d change it if you needed a different stage. The dialog also shows Action and Threshold (with the helper text “Numeric threshold for the guardrail (optional)”), both carried over from the pencil dialog: Block and 0.8, plus Cancel and Save / Saving… buttons. Click Save. A toast confirms: Guardrail "pii-detector" updated.
PII Detection is now enabled, blocking at a 0.8 confidence threshold, running at the pre stage.
Dive deeper
Questions & Discussion