AI Prompt Guard Policy

Related Documentation
Made by
Kong Inc.
Incompatible with
on-prem
Minimum Version
AI Gateway - 2.0
Tags

The AI Prompt Guard Policy lets you configure a series of PCRE-compatible regular expressions as allow or deny lists, to guard against misuse of text completion requests.

You can use this AI Policy to allow or block specific prompts, words, phrases, or otherwise have more control over how an LLM model is used when called via AI Gateway.

It does this by scanning all chat messages where the role is user for the specific expressions set.

For chat requests, this means the Policy only evaluates the messages[].content field of the request body against the allow and deny rules. Other parts of the request body, such as model or other parameters, are not scanned.

You can use a combination of allow and deny rules to preserve integrity and compliance when serving an LLM model using AI Gateway.

  • For llm/v1/chat type models: You can optionally configure the Policy to ignore existing chat history, wherein it will only scan the trailing user message.
  • For llm/v1/completions type models: There is only one prompt field, thus the whole prompt is scanned on every request.

How it works

The AI Prompt Guard Policy matches lists of regular expressions to requests routed through the AI Gateway.

The matching behavior is as follows:

  • If any deny expressions are set, and the request matches any regex pattern in the deny list, the request is blocked.
  • If any allow expressions are set, but the request matches none of the allowed expressions, the request is also blocked.
  • If any allow expressions are set, and the request matches one of the allow expressions, the request passes through to the LLM.
  • If there are both deny and allow expressions set, the deny condition takes precedence over allow. Any request that matches an entry in the deny list is blocked, even if it also matches an expression in the allow list. If the request does not match an expression in the deny list, then it must match an expression in the allow list to be passed through to the LLM.

Rejection modes

The AI Prompt Guard Policy responds to a blocked request according to its rejection mode.

Use config.rejection_mode to control how AI Gateway responds to a blocked request:

Mode

Status code

Response body

none (default) 400 A JSON error with the block message, for example {"error": {"message": "..."}}. The response omits the guardrail’s name. Clients can tell it apart from a malformed request only by its message, because the status code is the same.
stealth 403 A generic JSON error, {"error": {"message": "request forbidden"}}. The response hides all guardrail details.
verbose 403 A structured JSON error that names the Policy that blocked the request and the reason. See Verbose response.

Use none or stealth for clients outside your organization, so responses don’t reveal how your guardrails are configured. Use verbose in development or for trusted internal clients, to see why a request was blocked.

Verbose response

In verbose mode, the response always has the status code 403 and the error code GUARDRAIL_BLOCKED. Clients can check the error.code field to tell a guardrail rejection apart from other errors:

  • type: Always guardrail_rejected.
  • plugin: The type of the Policy that blocked the request.
  • reason: Why the request was blocked.
  • code: Always GUARDRAIL_BLOCKED.
  • detail: Additional context about the match. This field is only present when the Policy has details to report.

The AI Prompt Guard Policy evaluates the request before it reaches the LLM, so a blocked request returns the same error response whether or not the request sets stream to true.

For example, a request that matches a deny_patterns entry returns the following response in verbose mode. The detail.matched_pattern field contains the pattern that matched:

{
  "error": {
    "type": "guardrail_rejected",
    "plugin": "ai-prompt-guard",
    "reason": "prompt pattern is blocked",
    "code": "GUARDRAIL_BLOCKED",
    "detail": {
      "matched_pattern": "(?i)ignore previous instructions"
    }
  }
}

When a request fails to match any allow_patterns entry, the detail field is omitted.

To return this response, set config.rejection_mode to verbose:

Detect without blocking

To run the AI Prompt Guard Policy without blocking, set config.continue_on_detection to true. When a request matches, the Policy lets the request continue to the LLM. The caller receives the LLM’s normal response, so config.rejection_mode has no effect while this setting is enabled.

Unlike other AI guardrail Policies, the AI Prompt Guard Policy doesn’t populate the ai.proxy.guardrail_triggered object when this setting is enabled. For the fields that other guardrail Policies record, see the AI Gateway audit log reference.

Set continue_on_detection back to false to enforce the rules.

Best practices

Configure the AI Prompt Guard Policy to detect hidden unicode characters that attackers commonly use to embed malicious instructions in user input:

In this example:

  • (\xE2\x80[\x8B-\x8D]|\xEF\xBB\xBF): Detects zero-width characters (U+200B-U+200D, U+FEFF)
  • \xE2\x80[\xAA-\xAE]: Detects bidirectional text controls (U+202A-U+202E)
  • \xE2\x81[\xA0-\xAF]: Detects format controls (U+2060-U+206F)
  • \xF3\xA0\x80[\xA0-\xBF]|\xF3\xA0\x81[\x80-\xBF]: Detects unicode tag characters (U+E0020-U+E007F)

These patterns block invisible characters that can hide prompt injection attempts. Zero-width and bidirectional control characters render as blank space in most interfaces but remain visible to the LLM, allowing attackers to insert hidden commands.

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!