Noma Runtime Protection

Noma’s Kong AI Gateway plugin offers full AI detection & response (AI-DR) runtime protection to all OpenAI-compliant modules through your Kong AI Gateway. It allows you to leverage Noma’s AI-DR service to classify, flag, and block a wide range of security risks in real-time.

Integrating the Noma plugin into your AI Gateway allows you to:

• Centralize security oversight: Automatically stream AI traffic data to the Noma Security Console for comprehensive audit trails and behavioral analysis.
• Enforce policy in real time: Use Noma’s AI-DR to evaluate every interaction, enabling you to redact PCI, PII, mask sensitive data, and block non-compliant requests instantly (optional).

The Noma plugin provides a high-performance, low-footprint solution for AI security. By processing traffic after SSL termination, it enables Noma to inspect prompts and responses in real time and apply critical security guardrails across your AI workflows.

The Noma Runtime Protection plugin is available as a LuaRocks module or as a set of Lua source files.

Prerequisites

Before enabling the plugin, you need to obtain assets from Noma.

Noma assets:

• Obtain the Noma plugin .rock file or set of Lua files from your Noma Technical Account Manager.
• Contact your Noma TAM for the client ID and client secret.

FROM kong/kong-gateway:latest

USER root

RUN \apt-get update && \apt-get install unzip -y

WORKDIR /usr/kong/noma

RUN apt update && apt-get install -y build-essential git curl unzip

RUN bash -c 'mkdir -pv {noma-runtime-protection}'

COPY ./noma-runtime-protection.zip noma-runtime-protection/noma-runtime-protection.zip

RUN unzip noma-runtime-protection/noma-runtime-protection.zip -d noma-runtime-protection && rm noma-runtime-protection/noma-runtime-protection.zip

RUN cd noma-runtime-protection && luarocks make

USER kong

Next, set up AI Gateway and enable the plugin.

After installing the plugin, you will need the following Kong Gateway entity configuration:

1. Set up AI Gateway by creating a Service, a Route, and enabling the AI Proxy plugin.
2. Create a Consumer and an auth key to identify the application/client calling the API.
3. Group Consumers (Optional): If you want to set up shared runtime policies, group your Consumers into Consumer Groups.
4. Enable the Noma Runtime Protection plugin.

The plugin can run in one of the following modes, configured using the config.monitor_mode parameter:

• monitor: AI-DR runs asynchronously. Monitors and logs requests, but doesn’t block them. Has no impact on request latency.
• blocking: AI-DR runs synchronously. Requests/responses may be rejected based on the verdict.

If the Noma plugin isn’t behaving as expected, use the following sections to identify and resolve common issues.

Look for [noma-runtime-protection] prefixes to identify specific Lua errors or HTTP handshake failures.

Synchronization and “Plugin Not Found” errors

Symptoms: You see the Noma plugin in Konnect, but requests fail with a 500 Internal Server Error, or the data plane logs show plugin 'noma-runtime-protection' not found.

Possible solutions:

• Hybrid sync check: Ensure the .rock file was installed on every data plane node. If you have a cluster of 5 nodes, all 5 must have the plugin code.

• Environment variable check: If you are using Docker or Kubernetes, ensure KONG_PLUGINS environment variable includes noma-runtime-protection. For example:

    PLUGINS=bundled,noma-runtime-protection
  

  Copied!

• Lua Path: Verify the plugin is in Kong Gateway’s search path by running:

    luarocks list | grep noma
  

  Copied!

Connectivity issues

Symptoms: Requests are delayed, or Noma’s console isn’t showing any new inferences.

Possible solutions:

• Egress rules: Ensure your Kong Gateway nodes have outbound HTTPS access (port 443) to api.noma.security.
• Credential validation: Double-check your client ID and client secret. If these are incorrect, the plugin will fail to authenticate with the Noma API.
• Timeout settings: If you are using blocking mode (synchronous), ensure your proxy_timeout settings in kong.conf aren’t too aggressive, as the plugin must wait for a verdict from Noma.

Entity mapping (Noma application ID)

Symptoms: Traffic is appearing in the Noma Console, but it’s all grouped under a generic name.

Possible solutions:

• Consumer identification: By default, Noma uses the Kong Gateway application ID. If you haven’t assigned a Consumer to the request (for example, you applied the plugin globally without auth), you’ll get a generic 'kong' application ID.

• Explicit ID: If you want specific grouping, manually enter a unique string in the Application ID field within the Noma plugin configuration in Kong Gateway.

Policy is not blocking (monitor mode)

Symptoms: Malicious prompts are being flagged in the Noma Console but are not being blocked at the Gateway.

Possible solutions:

• Mode check: Verify that config.monitor_mode is off (false).
  • Monitor mode ON: asynchronous (log only).
  • Monitor mode OFF: synchronous (enforce/block).