AI Lakera Guard Policy

The AI Lakera Guard Policy evaluates requests and responses that pass through AI Gateway to Large Language Models (LLMs). It uses the Lakera Guard SaaS service to detect safety policy violations and block unsafe content before it reaches upstream LLMs or returns to clients. The AI Lakera Guard Policy supports multiple inspection modes and guards both inbound prompts and outbound model outputs.

The AI Lakera Guard Policy inspects model traffic at three points in the LLM request lifecycle. Each phase pages data into memory, extracts content that Lakera Guard can evaluate, and sends that content to Lakera for inspection.

• Request phase: Inspection occurs before any data leaves the gateway toward the target LLM. The AI Lakera Guard Policy buffers the full request body in memory, extracts the fields that the AI Lakera Guard Policy can evaluate, and sends them for inspection.
• Response phase (buffered): Inspection occurs before any byte is transmitted back toward the client. The AI Lakera Guard Policy buffers the full upstream response in memory, extracts the response fields that Lakera Guard can evaluate, and inspects them. This occurs before AI Gateway sends any part of the response back to the client.
• Response phase (per-frame): The AI Lakera Guard Policy runs during streaming responses like Server-Sent Events. AI Gateway processes the response in chunks, buffering each frame in memory as it arrives. When enough data is available to extract an evaluable segment, the AI Lakera Guard Policy inspects that segment with Lakera Guard before forwarding the frame to the client.

The AI Lakera Guard Policy inspects request and response bodies for routes that use supported model interaction formats. It skips inspection on non-text response types, which Lakera Guard does not currently support.

The AI Lakera Guard Policy responds to a blocked request or response according to its rejection mode.

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

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.

Streaming responses

When a guardrail blocks a streaming response, the final chunk of the stream has finish_reason set to blocked_by_guard. The chunks that the guardrail already evaluated and sent are not recalled, so the HTTP status code of the response remains 200. The rejection_mode setting changes what the chunk reports:

• none: The delta.content field contains the block message.
• stealth: The delta.content field contains the message request forbidden.
• verbose: The delta.content field contains the block reason, and choices[0] also includes a guardrail_result object with the same fields as the verbose response.

In none mode, the response body is the plain message set in config.request_failure_message for requests or config.response_failure_message for responses. The following response is the body for a request blocked in none mode:

{
  "message": "Request was filtered by Lakera Guard",
  "error": true
}

In verbose mode, detail contains the detector results that Lakera Guard returned for the content, and reason is the type of the detector that matched. For example, a prompt injection attempt returns the following response:

{
  "error": {
    "type": "guardrail_rejected",
    "plugin": "ai-lakera-guard",
    "reason": "prompt_attack",
    "code": "GUARDRAIL_BLOCKED",
    "detail": [
      {
        "project_id": "project-lakera-default",
        "policy_id": "policy-lakera-default",
        "detector_id": "prompt_attack",
        "detector_type": "prompt_attack",
        "detected": true,
        "result": "l1_confident",
        "message_id": 0
      }
    ]
  }
}

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

curl -X POST https://{region}.api.konghq.com/v1/ai-gateways/{AIGatewayId}/policies \
    --header "accept: application/json" \
    --header "Content-Type: application/json" \
    --header "Authorization: Bearer $KONNECT_TOKEN" \
    --data '
    {
      "display_name": "AI Lakera Guard - Verbose Rejection",
      "name": "ai-lakera-guard",
      "type": "ai-lakera-guard",
      "config": {
        "api_key": "'$LAKERA_API_KEY'",
        "rejection_mode": "verbose"
      }
    }
    '

ai_gateway_policies:
  - ref: ai-lakera-guard
    ai_gateway: !lookup {id: !env AI_GATEWAY_ID}
    display_name: AI Lakera Guard - Verbose Rejection
    name: ai-lakera-guard
    type: ai-lakera-guard
    config:
      api_key: !env LAKERA_API_KEY
      rejection_mode: verbose

The Policy inspects streamed responses one buffered segment at a time. Content that Lakera Guard only recognizes across several segments, such as a sentence split between two frames, might not be blocked while streaming.

To run the AI Lakera 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.

Detections are still recorded in the AI Gateway logs. The ai.proxy.guardrail_triggered object is populated with the Policy that matched and the direction of the match. To include the matched content, also set config.log_blocked_content to true. For the full list of fields, see the AI Gateway audit log reference.

This is useful when you roll out new rules: run them in detection-only mode, review the logs for false positives, then set continue_on_detection back to false to enforce them.

You can use the logging capabilities of the AI Lakera Guard Policy to monitor the inspection process and understand the detected violations. For the full list of log fields, see the AI Gateway audit log reference.

The AI Lakera Guard Policy provides detailed logging and controls over how violations are reported:

• SaaS platform logging: All inspected requests, responses, and chats are made available on the Lakera SaaS platform.
• AI Gateway logging: AI Gateway logs all request and response Lakera request UUIDs to the standard logging subsystem.
• Unsupported logging outputs: Prometheus, or OpenTelemetry.
• Logging outputs: HTTP Log, File Log, and TCP Log.

By default, the AI Lakera Guard Policy doesn’t tell clients why their request was blocked. However, this information is always logged to AI Gateway logs for administrators.

To change this behavior, use reveal_failure_categories: true. If activated, the client receives a JSON response including a breakdown array that details the specific detector_type that caused the failure.

To log the raw content of blocked requests and responses, enable config.log_blocked_content. When enabled, the blocked prompt or response body appears under ai.proxy.lakera-guard.input_faulty_prompt and ai.proxy.lakera-guard.output_faulty_response in the log entry.

Standard logging subsystem example

When a request passes all guardrails, the log includes processing latency and the request UUID:

"ai": {
  "proxy": {
    "lakera-guard": {
      "input_processing_latency": 72,
      "lakera_service_url": "https://api.lakera.ai/v2/guard",
      "input_request_uuid": "a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
      "lakera_project_id": "project-1234567890"
    }
  }
}

Violations log example

When the guardrails block a request, the log captures the violation reason, detector details, and the blocking AI Policy name, AI Consumer ID, and a running trigger counter:

"ai": {
  "proxy": {
    "lakera-guard": {
      "input_processing_latency": 78,
      "lakera_service_url": "https://api.lakera.ai/v2/guard",
      "input_block_detail": [
        {
          "policy_id": "policy-4f8a9b2c-1d3e-4a5b-8c9d-0e1f2a3b4c5d",
          "detector_id": "detector-lakera-moderation-1-input",
          "project_id": "project-1234567890",
          "message_id": 3,
          "detected": true,
          "detector_type": "moderated_content/hate"
        }
      ],
      "input_request_uuid": "a1b2c3d4-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
      "input_block_reason": "moderated_content/hate",
      "input_block_source": "ai-lakera-guard",
      "input_block_consumer_id": "consumer-uuid-1234",
      "guards_triggered_count": 1,
      "lakera_project_id": "project-1234567890"
    }
  }
}

Set config.proxy on this entity to route its outbound requests through an HTTP forward proxy. Use this in network-isolated deployments where AI Gateway cannot open direct connections to LLM providers or auxiliary services.

The proxy record is identical for AI Model, AI MCP Server, and supported AI Policy entities. Existing capabilities such as load balancing, health checking, streaming, WebSocket, and HTTP/2 continue to work when the proxy is active.

For the full field reference, traffic flow, and limitations, see Forward proxy support.