Model guardrails

Guardrails on model traffic read two things: the prompt an employee’s AI client sends to a model, and the completion that comes back. Prompt injection screening is specific to model traffic and is covered below. Entity detection is not: the DLP tab and Security → PII detection render one organization-wide rule set, the Standard Entity Rules, so an action you change on either surface changes it on both.

Both engines run inline. A prompt is screened before it reaches the vendor, so a redaction or a block happens before the data leaves.

Data loss prevention

Entity rules inspect text against a seeded rule set and do one of three things with what they find.

Action	Effect
Log	Record the match and pass the text through unchanged
Redact	Replace the matched span with a placeholder before it reaches the vendor
Block	Refuse the call, with an error saying a security rule fired

Rules are grouped by region on the DLP tab, each row showing its entity type, what it detects, the detection method, its pre-run action, and whether it is active. Custom regex rules keep their one home on Custom Regex Rules; the DLP tab holds the standard entities only.

Region	Entity	Default action
Global	`CREDIT_CARD`	Redact
Global	`CRYPTO`	Redact
Global	`DATE_TIME`	Log
Global	`EMAIL_ADDRESS`	Log
Global	`IBAN_CODE`	Redact
Global	`IP_ADDRESS`	Log
Global	`NRP`	Log
Global	`LOCATION`	Log
Global	`PERSON`	Log
Global	`PHONE_NUMBER`	Log
Global	`MEDICAL_LICENSE`	Log
Global	`URL`	Log
USA	`US_BANK_NUMBER`	Log
USA	`US_DRIVER_LICENSE`	Log
USA	`US_ITIN`	Redact
USA	`US_PASSPORT`	Log
USA	`US_SSN`	Redact

Seeded rules arrive switched off

A new organization gets all seventeen rules with the actions above, every one of them Inactive. The default action is what a rule will do once you enable it, not what is happening today, so nothing is detected until you turn a rule on.

A seeded rule can be turned off or given a different action, but its detection pattern is fixed, because the pattern comes from the upstream recognizer. Two rules matching the same span resolve to the higher-priority entity, so CREDIT_CARD wins over DATE_TIME rather than producing two findings.

PERSON and LOCATION are the expensive ones to detect and the noisiest in ordinary employee prompts, which is why they default to Log rather than Redact. For what each entity matches and the detection method behind it, see Standard Entity Rules.

Prompt injection

Injection screening looks for adversarial intent rather than sensitive data: text trying to override a system prompt, leak it, or steer an agent into doing something the employee did not ask for. It runs on two independent axes, each with its own mode.

Axis	What it looks for
Direct	Instructions in the prompt itself that try to override or exfiltrate the system prompt
Indirect	Instructions arriving inside retrieved content, a tool result, or a pasted document

Because the axes are configured separately, you can run direct screening in alert while indirect runs in block, or the reverse. The indirect axis is the one that matters most for employees running agents, since the injected text arrives in a page or a ticket nobody read.

Mode	Behavior
`off`	The axis is bypassed: no screening, no alerts, no enforcement
`alert`	Screening runs and emits alerts, but never blocks
`block`	Detections are enforced according to your action configuration

Run in alert for a week first. Watch what fires, tune your allowlist, then switch to block.

On a detection, the action depends on direction. The inbound prompt defaults to block and the model’s response defaults to redact. Each takes one of five values: observe records only, redact replaces the flagged span, route sends the request to a safer vendor you nominate, block refuses it, and escalate blocks it and marks the alert for human review.

A classifier scores every prompt and that score drives the alerts feed, not the block decision. Enforcement on the direct axis comes from a curated set of lexical patterns, where a false-positive rate of zero is measurable. So when you are chasing false positives, tune the allowlist rather than the thresholds.

Allowlist. Some legitimate work looks like injection: a security team asking a model about jailbreak techniques, a support workflow summarizing spam. An allowlist of regex patterns suppresses those, up to 50 patterns of 200 characters each. Anchor every pattern to something specific in your traffic. A pattern broad enough to match ordinary prose is dropped when the allowlist is evaluated rather than applied, so it cannot quietly switch an axis off while the mode still reads block, and dropped entries are recorded on the detection record so you can see it happened.

A blocked prompt returns 400 with a stable code:

{
  "error": {
    "type": "invalid_request_error",
    "message": "Request blocked: prompt injection detected.",
    "code": "pi_blocked"
  }
}

Output blocks return the same shape with pi_output_blocked. Match on code, which does not change across releases.

Where detections land

Every detection from either engine, whatever its action, appears on the Security alerts tab with its time, whether it was PI or DLP, the action taken, the injection score, and the employee behind it. The tab is read-only: it reports what fired, and the rules that decide it live on DLP and in Gateway.

The Employee column is not populated yet

The alerts feed returns the requesting user’s id rather than a resolved name, so the Employee column reads as a dash. Match a detection to a person through its request in LLM calls until the feed resolves names.

Reading the alerts feed needs View security alerts. Reading the DLP tab needs View security rules, and changing a rule’s action or switch needs Manage security rules. Every change is written to the audit trail.

FAQs

How much latency does this add?

A few milliseconds per request, negligible against inference time. Screening runs in parallel with policy resolution where it can.

What happens if the scanning service is unreachable?

It fails open by default and the request proceeds as though nothing was detected. Set fail-closed to refuse the request instead, which is the right posture when any unscanned inference is unacceptable.

Are redacted prompts logged in their original form?

No. The redacted version is what the vendor receives and what is stored in the request log. The original is never kept unless payload logging is on for your organization.

Do these rules cover tool calls too?

The entity rules are shared rather than separate: one organization-wide set backs both the DLP tab here and the tool-argument scanning in Security Gateway, so changing an action changes it for both. What differs is where detections land, since tool call violations report to Security Gateway’s own violations feed. Prompt injection screening is model traffic only.

Test a rule against sample text before you turn it on with the Guardrail tester.