AI GCP Model Armor Policy

The GCP Model Armor Policy integrates AI Gateway with Google Cloud’s Model Armor service to enforce content safety guardrails on AI requests and responses.

It leverages GCP SaaS APIs to inspect prompts and model outputs, preventing unsafe content from being processed or returned to users.

The AI GCP Model Armor Policy provides the following content safety capabilities:

The AI GCP Model Armor Policy inspects requests and responses using GCP Model Armor:

• Request inspection: Chat prompts are intercepted, and the relevant content (by default, the last chat message) is sent to the sanitizeUserPrompt API.
• Response inspection: Chat responses are buffered (supporting gzip and streaming) and sent to the sanitizeModelResponse API. SSE streaming is supported with chunk buffering.

Request guarding flow

1. An incoming request to an LLM (for example, a chat completion) is intercepted by the AI GCP Model Armor Policy.
2. The AI GCP Model Armor Policy extracts the relevant content, usually the last user message in the conversation.
3. The content is submitted to GCP Model Armor’s sanitizeUserPrompt endpoint for analysis.

Response guarding flow

1. The AI GCP Model Armor Policy buffers the upstream response body (including gzipped responses).
2. It extracts the model’s response content.
3. The content is sent to GCP Model Armor’s sanitizeModelResponse endpoint for validation.

Sanitization and action

1. GCP Model Armor evaluates the provided content against the configured template_id.
2. The AI GCP Model Armor Policy interprets the sanitizationResult from GCP.
3. If a violation is detected (for example, hatred, sexually explicit content, harassment, or jailbreak attempts), the request or response is blocked.
4. Blocked traffic returns the response for the configured rejection mode. By default, the response is a 400 Bad Request with the configured request_failure_message or response_failure_message.
5. If reveal_failure_categories is enabled, the response also lists the categories that triggered blocking.

When configuring template_id in the AI GCP Model Armor Policy, ensure that it aligns with the content safety policies and categories defined in your GCP Model Armor service.

Review whether your organization requires custom categories or additional policy definitions, and integrate them into the selected template to match compliance and safety requirements.

The AI GCP Model Armor 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 GCP Model Armor",
  "error": true
}

In verbose mode, reason is the type of the Model Armor filter that matched, and detail lists the filter results that GCP Model Armor returned. For example, a prompt injection attempt returns the following response:

{
  "error": {
    "type": "guardrail_rejected",
    "plugin": "ai-gcp-model-armor",
    "reason": "pi_and_jailbreak.piAndJailbreakFilterResult",
    "code": "GUARDRAIL_BLOCKED",
    "detail": [
      {
        "checkType": "pi_and_jailbreak.piAndJailbreakFilterResult",
        "confidenceLevel": "MEDIUM_AND_ABOVE"
      }
    ]
  }
}

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 GCP Model Armor - Verbose Rejection",
      "name": "ai-gcp-model-armor",
      "type": "ai-gcp-model-armor",
      "config": {
        "project_id": "'$PROJECT_ID'",
        "location_id": "us-central1",
        "template_id": "'$TEMPLATE_ID'",
        "gcp_use_service_account": true,
        "gcp_service_account_json": "'$GCP_SERVICE_ACCOUNT_JSON'",
        "rejection_mode": "verbose"
      }
    }
    '

ai_gateway_policies:
  - ref: ai-gcp-model-armor
    ai_gateway: !lookup {id: !env AI_GATEWAY_ID}
    display_name: AI GCP Model Armor - Verbose Rejection
    name: ai-gcp-model-armor
    type: ai-gcp-model-armor
    config:
      project_id: !env PROJECT_ID
      location_id: us-central1
      template_id: !env TEMPLATE_ID
      gcp_use_service_account: true
      gcp_service_account_json: !env GCP_SERVICE_ACCOUNT_JSON
      rejection_mode: verbose

To run the AI GCP Model Armor 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.

The following configuration guidance helps ensure effective content safety enforcement:

Caution: Do not set the Model Armor Floor Setting directly in GCP, as it will cause conflicts with the AI GCP Model Armor Policy. See the FAQ entry for this error for more information.

The AI GCP Model Armor Policy blocks requests when GCP Model Armor returns a filter result with an unrecognized or new filter type. To avoid blocked requests, review your Model Armor template and ensure it only includes filter types that the AI Policy supports.

The AI GCP Model Armor Policy emits structured log data for every inspected request and response. For the full list of log fields, see the AI Gateway audit log reference.

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.gcp-model-armor.input_faulty_prompt and ai.proxy.gcp-model-armor.output_faulty_response in the log entry.

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.

• Only chat prompts and chat responses are inspected; embeddings and other modalities are not checked.
• Inspects one chat message or one response body at a time. Combining multiple messages reduces accuracy.
• For SSE streaming, the Policy inspects the response in segments, so unsafe content can reach the client before the Policy blocks the stream. A violation that only appears across several segments might not be blocked.
• Only one template_id can be configured per AI Policy.