Kong Gateway + Prisma AIRS Integration

The v2 plugin uses the same two-file structure (schema.lua + handler.lua) but with MCP detection and buffered SSE scanning logic. Deploy it the same way as v1, but use the v2 source files.

Traditional Kong Gateway

1. Copy the v2 plugin files:

   sudo cp -r prisma-airs-intercept/ \
     /usr/local/share/lua/5.1/kong/plugins/prisma-airs-intercept/

   Copy
2. Confirm both files are present:

   ls /usr/local/share/lua/5.1/kong/plugins/prisma-airs-intercept/
   # Expected: handler.lua  schema.lua

   Copy

Docker (Volume Mount)

services:
  kong-dp:
    image: kong/kong-gateway:3.14.0.2
    environment:
      KONG_PLUGINS: "bundled,prisma-airs-intercept"
    volumes:
      - ./kong/plugins/prisma-airs-intercept:/usr/local/share/lua/5.1/kong/plugins/prisma-airs-intercept:ro

Registration follows the same process as v1. Add the plugin name to KONG_PLUGINS.

1. Set in kong.conf or environment variable:

   plugins = bundled,prisma-airs-intercept

   Copy
2. For Kong Konnect, upload the v2 schema.lua to the Control Plane:

   curl -X POST \
     "https://us.api.konghq.com/v2/control-planes/${CONTROL_PLANE_ID}/core-entities/plugin-schemas" \
     -H "Authorization: Bearer ${KONNECT_TOKEN}" \
     -H "Content-Type: application/json" \
     -d "{\"lua_schema\": $(jq -Rs '.' schema.lua)}"

   Copy

The Request Callout method uses no custom plugin files. Instead, the AIRS API key is stored in Kong Vault and referenced at runtime. This step is Kong Konnect-specific.

1. In Kong Konnect, navigate to the Control Plane settings.
2. Add an environment variable for the vault:

   KONG_VAULT_ENV_AIRS_API_KEY=YOUR_AIRS_API_KEY

   Copy
3. The plugin configuration references this value as {vault://env/airs-api-key}.

The Request Callout attaches to an existing service targeting the AI provider.

1. Confirm a service exists pointing to the AI provider (e.g., https://api.openai.com).
2. Confirm a route exists with the path /v1/chat/completions (or equivalent).
3. Note the Service ID for use in the configuration JSON.

Attach the v2 plugin. The configuration includes additional MCP and SSE parameters.

Traditional Kong Gateway (Admin API)

curl -X POST http://localhost:8001/services/{service}/plugins \
  --data "name=prisma-airs-intercept" \
  --data "config.api_key=YOUR_AIRS_API_KEY" \
  --data "config.profile_name=YOUR_PROFILE_NAME" \
  --data "config.app_name=YOUR_APP_NAME"

Kong Konnect (Control Plane API)

curl -X POST \
  "https://us.api.konghq.com/v2/control-planes/${CONTROL_PLANE_ID}/core-entities/plugins" \
  -H "Authorization: Bearer ${KONNECT_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "prisma-airs-intercept",
    "service": {"id": "YOUR_SERVICE_ID"},
    "config": {
      "api_key": "YOUR_AIRS_API_KEY",
      "profile_name": "YOUR_PROFILE_NAME",
      "app_name": "YOUR_APP_NAME"
    }
  }'

Configuration Parameters (v2)

v2 automatically detects MCP JSON-RPC 2.0 requests by checking for jsonrpc and method fields. Understanding which methods are scanned versus bypassed prevents false positives and scanning gaps.

Scanned (tool_event)

• tools/call — request arguments scanned as tool_event.input; response result scanned as tool_event.output

Bypassed (control messages)

• initialize, initialized, ping
• notifications/initialized
• tools/list, resources/list, prompts/list

AIRS Payload for MCP tool_event

{
  "tr_id": "{kong-request-id}",
  "ai_profile": {"profile_name": "YOUR_PROFILE_NAME"},
  "contents": [{
    "tool_event": {
      "metadata": {
        "ecosystem": "mcp",
        "method": "tools/call",
        "server_name": "kong-YOUR_APP_NAME",
        "tool_invoked": "search_docs"
      },
      "input": "{\"query\":\"kong plugin development\"}",
      "output": "{\"content\":[{\"type\":\"text\",\"text\":\"...\"}]}"
    }
  }],
  "metadata": {
    "app_name": "kong-YOUR_APP_NAME",
    "app_user": "mcp-client",
    "ai_model": "mcp"
  }
}

Apply a different AIRS profile per request on a single shared route, chosen from a signed JWT claim instead of deploying a separate gateway (or route) per application. The profile is selected from the caller's already-validated token, so it cannot be spoofed the way a header can.

Example: one shared route, profile chosen by a risk_tier claim:

curl -X POST http://localhost:8001/services/{service}/plugins \
  -H "Content-Type: application/json" \
  -d '{
    "name": "prisma-airs-intercept",
    "config": {
      "api_key": "YOUR_AIRS_API_KEY",
      "profile_name": "default-baseline",
      "profile_claim": "risk_tier",
      "profile_claim_map": {
        "high": "strict-production",
        "medium": "default-baseline",
        "low": "flexible-internal"
      },
      "fallback_profile_name": "strict-production"
    }
  }'

Resolution Order

1. Claim value is looked up in profile_claim_map → mapped profile name is used.
2. If profile_claim_map is omitted, the claim value itself is used directly as the profile name.
3. If the claim is missing or unmapped, falls closed to fallback_profile_name.
4. If profile_claim is not set at all, behavior is the static profile_name (legacy default).

The resolved profile is logged at debug level and stamped on the upstream request as X-AIRS-Profile-Used.

Unit Tests

The plugin exposes pure resolver helpers that can be tested without a Kong runtime:

lua spec/profile_selection_spec.lua

The Request Callout method uses the native request-callout plugin with inline Lua scripts that extract the prompt, send it to AIRS, check the verdict, and restore the original body for upstream.

1. Create the configuration JSON file. Replace YOUR_SERVICE_ID and YOUR_PROFILE_NAME:

   {
     "name": "request-callout",
     "service": {
       "id": "YOUR_SERVICE_ID"
     },
     "config": {
       "callouts": [
         {
           "name": "airs_request_scan",
           "request": {
             "url": "https://service.api.aisecurity.paloaltonetworks.com/v1/scan/sync/request",
             "method": "POST",
             "headers": {
               "Content-Type": "application/json",
               "Accept": "application/json",
               "x-pan-token": "{vault://env/airs-api-key}"
             }
           },
           "timeout": {
             "connect": 2000,
             "read": 10000,
             "write": 10000
           },
           "on_error": "exit",
           "retries": 2
         }
       ],
       "request": {
         "before": "<prompt extraction Lua script>"
       },
       "response": {
         "before": "<verdict check Lua script>"
       },
       "upstream": {
         "before": "<body restore Lua script>"
       }
     }
   }

   Copy
2. The three inline Lua phases:
   • request.before — Extracts the last user message from the OpenAI messages[] array, builds the AIRS scan payload, and sets it as the callout request body.
   • response.before — Checks the AIRS verdict. If action is block, returns HTTP 403.
   • upstream.before — Restores the original request body before forwarding to the LLM provider.
3. Apply via Konnect API:

   curl -X POST \
     "https://us.api.konghq.com/v2/control-planes/${CONTROL_PLANE_ID}/core-entities/plugins" \
     -H "Authorization: Bearer ${KONNECT_TOKEN}" \
     -H "Content-Type: application/json" \
     -d @request-callout-prisma-airs-config.json

   Copy

Restart the Kong runtime to load the v2 plugin files.

# Docker
docker compose restart kong

# Traditional
kong restart

# Kubernetes
kubectl rollout restart deployment/kong-dp

1. Check the Admin API:

   curl -s http://localhost:8001/ | jq '.plugins.available_on_server["prisma-airs-intercept"]'

   Copy
2. Confirm the output is true.

The Request Callout plugin is a bundled Kong plugin and does not require a restart after configuration. Confirm it is active on the target service.

1. In Kong Konnect, navigate to the service and check the Plugins tab.
2. Confirm request-callout appears with status enabled.

MCP control messages should pass through without AIRS scanning.

curl -i -X POST http://localhost:8000/your-mcp-route \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list"
  }'

MCP tools/call requests should be scanned as tool_event payloads in both directions.

curl -i -X POST http://localhost:8000/your-mcp-route \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "echo",
      "arguments": {"msg": "hello"}
    }
  }'

1. Log in to Strata Cloud Manager.
2. Navigate to AI Runtime Security → AI Activity → Scan Logs.
3. Confirm scan records for both LLM and MCP traffic appear with the expected verdicts and content types (prompt, response, tool_event).

1. Log in to Strata Cloud Manager.
2. Navigate to AI Runtime Security → AI Activity → Scan Logs.
3. Confirm scan records for the prompts appear. No response scan records will appear (prompt-only method).