Prompt Guard

Overview

Prompt Guard runs in the relay hot path immediately after DLP. It scans the request body for prompt injection, jailbreak attempts, and related adversarial inputs, then applies a policy action — block, sanitize, or audit — before the request reaches the upstream model.

Prompt Guard is designed fail-open: if the engine encounters an internal error, the request passes through. This preserves service availability. DLP, by contrast, is fail-closed. See DLP vs. Prompt Guard for the rationale.

Relay Pipeline
  tokenAuth → quotaCheck → channelSelect
       ↓
  applyDLP               ← data leakage prevention
       ↓
  ✦ applyPromptGuard     ← adversarial input detection
       ↓
  applyRequestTransform
       ↓
  upstream (model provider)

Threat Categories

Prompt Guard classifies findings into seven categories.

Detection Architecture

Prompt Guard uses three detection layers in sequence. Earlier layers cache results so later layers only fire when needed.

Request body
    ↓
┌─────────────────────────────────┐
│  Layer 1: Pattern Engine        │  ≤ 2 ms
│  195+ regex + dictionary rules  │
│  Multilingual (9 languages)     │
└──────────────┬──────────────────┘
               │ findings
               ▼
┌─────────────────────────────────┐
│  Layer 2: Heuristic Scorer      │  ≤ 1 ms  (Phase 2 — not yet active)
│  Unicode anomalies              │
│  Zero-width characters          │
│  Role-confusion keyword density │
│  Suffix-attack patterns         │
└──────────────┬──────────────────┘
               │ findings (gray-area inputs)
               ▼
┌─────────────────────────────────┐
│  Layer 3: LLM Judge (optional)  │  ≤ 200 ms
│  Semantic classification        │
│  Two-level cache (LRU + Redis)  │
│  Daily call budget cap          │
└──────────────┬──────────────────┘
               ↓
         Block / Sanitize / Audit

Builtin pattern coverage:

All builtin patterns carry open-source licenses (CC0, Apache-2.0, MIT, or BSD-3-Clause).

Custom Patterns

Add tenant-private patterns in Console → Security → Prompt Guard → Patterns → New Pattern.

Supply:

• Category — one of the seven categories above
• Detector type — regex (RE2 syntax) or dictionary (term list)
• Base score — 0.0–1.0; contributes to the aggregate verdict score
• Language — BCP-47 tag (e.g. en, zh-CN); the engine skips patterns whose language does not match the request locale

Policies & Actions

Create policies in Console → Security → Prompt Guard → Policies → New Policy.

Actions

Sanitize Modes

When action is sanitize, choose how matched spans are rewritten:

Minimum Block Score

Set MinBlockScore (0.0–1.0) per policy. The engine blocks only when the aggregate score across all findings meets or exceeds this threshold. Lower values are more aggressive; higher values reduce false positives.

Recommended starting values:

• 0.7 — conservative (production user-facing applications)
• 0.5 — balanced (internal tooling)
• 0.3 — aggressive (high-risk contexts)

LLM Judge

Layer 3 uses a small language model to classify ambiguous inputs that Layer 1 and 2 cannot confidently score. Enable it for high-value contexts where false negatives are costly.

Required configuration when enabling the judge:

Latency: The judge operates under a 200 ms deadline per request. Requests where Layer 1 produces a definitive result skip the judge entirely.

API Behavior

When a Request Is Blocked

HTTP status 403 Forbidden. Response body:

{
  "error": {
    "code": "prompt_injection_blocked",
    "message": "Request blocked by PromptGuard: potential prompt injection detected",
    "detector": "pg_injection_ignore_prev_en",
    "request_id": "req_01abc..."
  }
}

detector is the pattern code of the highest-scoring finding. request_id correlates with gateway logs.

When a Request Is Sanitized

The request completes normally (200). The upstream receives the rewritten body. The caller is not notified that sanitization occurred.

When Audit-Only

The request completes normally (200). No visible change to the caller or the upstream.

Fail-Open Design

If the Prompt Guard engine fails (configuration load error, judge timeout, unexpected panic), the request passes through. This is intentional.

Prompt Guard defends against adversarial inputs — inputs a human or automated system crafted to subvert your application. An engine failure in this context does not expose data; it degrades a security layer. Degraded security is recoverable. A gateway that goes down because its security scanner crashed is not.

DLP makes the opposite choice: if the DLP engine fails, requests are blocked. DLP prevents data leakage, where a single missed detection can cause a compliance incident. Certainty matters more than availability.

See Also

• Data Loss Prevention — Scan and redact sensitive data in AI requests
• Security Overview — Full security architecture