Understanding Protect

A guardrail is a named check on your traffic

A guardrail wraps a check and adds three settings you configure in Agent Command Center, under Gateway > Guardrails:

• An action for when it triggers: Block, Warn, Mask, or Log
• A stage for when it runs: pre runs before the model sees the request, post runs before the response reaches the caller, and both runs on each side
• A confidence threshold for how sure the check has to be before it fires

A stage of both isn’t a third mode. It’s the same check running twice, once on the way in and once on the way out. Stage belongs to the guardrail rather than to the check it wraps, which is why a single gateway, the Agent Command Center surface your guardrails live on, can carry a mix: some watching only what the caller sent, others only what the model sent back.

The threshold runs from 0.0 to 1.0: raising it makes the check fire only on higher-confidence matches, lowering it makes it fire more readily. Threshold and action are independent settings. The threshold decides how often a check fires; the action decides what the caller experiences when it does. Loosening a threshold on a check set to Log changes nothing a caller can see. For the response status each action produces, see Guardrail checks.

Every guardrail wraps a check, and the Rules tab groups checks under two headers that mark a single split: where the check runs. Rule-Based Checks are first-party: they run inside Protect without an external provider. AI-Powered Checks call a provider you configure under Provider Settings in that check’s own settings.

flowchart TD
accTitle: The parts of a guardrail and how its check is classified
accDescr: A guardrail carries an action, a stage, and a confidence threshold, and it wraps a check. That check is either Rule-Based, running inside Protect without an external provider, or AI-Powered, calling a provider configured under Provider Settings.
G["Guardrail"] --> A["Action: Block, Warn, Mask, or Log"]
G --> S["Stage: pre, post, or both"]
G --> T["Confidence threshold"]
G --> C["Check"]
C --> RBC["Rule-Based: runs inside Protect"]
C --> AIP["AI-Powered: external provider"]

protect() screens one input in your code

Separate from the dashboard sits a second surface: protect(), a function you call directly in your own code. It screens one input at a time, text, image, or audio, against a fixed, shorter list of checks: toxicity, bias, prompt injection, and data privacy (PII).

protect() does not read your dashboard’s guardrail configuration. Disabling or customizing a check on the Rules tab has no effect on what protect() screens for, and calling protect() doesn’t touch anything on the dashboard either. The two surfaces are configured independently.

When to use each

• Dashboard guardrails: blanket coverage of every request in your org’s traffic, configured once in Agent Command Center
• protect(): screening one specific input inline in your own code

A worked example: PII Detection through a guardrail

A support agent’s traffic has a guardrail named PII Detection enabled, set to Block. A request from a customer carries an email address. Its confidence clears the threshold, the check fires, and the Block action stops the request before it reaches the model.

Where the verdict ends up

That outcome doesn’t disappear once the request is blocked. Every request is recorded with whether a guardrail triggered and the result of each check that ran, and that record is what shows up in Logs and Analytics for this request. From there, feedback on the verdict can mark it correct or wrong, telling you whether PII Detection’s threshold and action are actually tuned right, not just switched on.

This record belongs to the dashboard-guardrail surface, while protect() returns its verdict directly to your code as the function’s response; see the Protect SDK reference for the response shape.

Why it matters

Treating a guardrail and protect() as one surface means assuming a check you configured in one place is protecting you in the other, when it isn’t.

Two guardrails with the same check can still behave completely differently once their action, stage, or threshold diverge, because a guardrail is this fixed shape, not a single on/off switch.

Keep exploring