VeriKnox

The VeriKnox plugin (veriknox-plugin) lets you attach cryptographically signed audit receipts to every AI interaction passing through Kong Gateway. The plugin intercepts LLM inference, MCP, and A2A requests and responses, applies business policy, and forwards tamper-evident receipts to VeriKnox Hub. This gives your organization verifiable proof of what each AI agent did, whether it was authorized to do so, when it happened, and on whose behalf.

AI agents increasingly call LLMs, MCP servers, and each other through a shared gateway, but standard access logs don’t prove what payload was sent or what the model returned. VeriKnox addresses this by embedding ED25519 and ML-DSA-65 (NIST FIPS 204, post-quantum) signatures on every receipt. The signatures are resistant to both classical and future quantum attacks, and no private key material ever leaves the Rust signing library on the data plane.

Benefits of using the VeriKnox plugin:

• Tamper-evident proof of every AI interaction: Signed receipts record what the agent sent, what the model returned, who authorized it, and when.
• Dual classical and post-quantum signatures: Each receipt carries both an ED25519 signature (fast, verifiable today) and an ML-DSA-65 signature (NIST FIPS 204, resistant to quantum adversaries).
• Policy enforcement at the gateway: VeriKnox Hub evaluates each interaction against your business policy and can block non-compliant requests before they reach the upstream.
• Broad protocol coverage: Supports OpenAI Chat Completions, OpenAI Responses, Anthropic Claude Messages, OpenRouter, Google Gemini, MCP tool calls, and A2A JSON-RPC operations including streaming.
• No credential exposure: The agent passphrase is resolved from a Kong Vault reference at runtime and never written to disk in plain text.

Every Kong Gateway data plane enrolled with VeriKnox Hub holds an encrypted identity bundle on disk. When the VeriKnox plugin is enabled on a Route, it decrypts this identity using the agent_passphrase Vault reference, then acts in the Kong Gateway request lifecycle access phase.

In the access phase, the plugin:

1. Parses the request body according to the configured endpoint.specification (OpenAI, Anthropic, MCP, A2A, and so on).
2. Evaluates the request against VeriKnox Hub policy.
   • If the policy blocks it, the plugin returns an error and nothing is forwarded upstream.
   • If the policy allows it, the plugin signs a receipt with both ED25519 and ML-DSA-65 signatures and forwards it to VeriKnox Hub.
3. Strips VeriKnox-specific agent headers (x-veriknox-agent-id, x-veriknox-api-key, x-veriknox-agent-auth) before proxying the request upstream.

After the upstream responds, the plugin signs and forwards a response receipt to VeriKnox Hub as well.

 
sequenceDiagram
    autonumber
    participant A as AI Agent
    participant K as Kong Gateway
VeriKnox plugin
    participant H as VeriKnox Hub
    participant U as Upstream
LLM / MCP / A2A

    A->>K: Request with agent headers
    Note over K: access phase
    K->>H: Policy check + signed request receipt
    alt If the policy blocks the request
        H-->>K: Deny
        K-->>A: 403 Forbidden
    else If the policy allows the request
        H-->>K: Allow
        K->>U: Proxied request (agent headers stripped)
        U-->>K: Response
        K->>H: Signed response receipt
        K-->>A: Response
    end
  

Supported endpoint specifications

The endpoint.specification field tells the plugin which protocol and API format to expect. Set it to one of the following values:

Plugin priority

Kong Gateway runs plugins in descending priority order (higher number runs first). The VeriKnox plugin must run after authentication plugins (which sit at approximately 1001-1005), so its priority must be lower. You can control this using dynamic plugin ordering.

Where you place the VeriKnox plugin relative to Kong AI Gateway plugins determines what gets signed:

VeriKnox recommends a priority of approximately 700. Use 785-999 if you need to sign the raw user intent before any model routing or prompt injection by AI plugins.

Caller identity

The VeriKnox plugin doesn’t authenticate clients to Kong Gateway. If you want receipts to identify the calling agent, configure an authentication plugin or another gateway mechanism separately, then pass the caller context to the VeriKnox plugin through VeriKnox-specific request headers:

Use the Pre-Function plugin to copy these headers into shared request context and remove them before proxying upstream:

plugins:
  - name: pre-function
    config:
      access:
        - |-
          kong.ctx.shared.veriknox_agent_auth = kong.request.get_header("x-veriknox-agent-auth")
          kong.ctx.shared.veriknox_agent_id = kong.request.get_header("x-veriknox-agent-id")
          kong.ctx.shared.veriknox_api_key = kong.request.get_header("x-veriknox-api-key")
          kong.service.request.clear_header("x-veriknox-agent-auth")
          kong.service.request.clear_header("x-veriknox-agent-id")
          kong.service.request.clear_header("x-veriknox-api-key")

If no agent ID is supplied through x-veriknox-agent-id or x-veriknox-agent-auth, the plugin generates a traceable ID in the form http-client:<ip-address>. It uses the forwarded client IP when Kong Gateway trusts the proxy, otherwise it uses the direct client IP. This fallback supports audit tracing, but it is not an authenticated identity.

In production, each AI agent (HTTP client) must authenticate with Kong Gateway before sending traffic. Kong Gateway supports this through authentication plugins such as Key Auth or JWT. The VeriKnox plugin should not handle authentication itself.

Without a paired authentication plugin, Kong Gateway may accept LLM inference, MCP, and A2A traffic without authentication: it allows each HTTP request through, and the VeriKnox plugin may then block it based on policy. That downstream step is authorization without prior authentication. Run a separate Kong Gateway authentication plugin or dedicated service for AI agents alongside the VeriKnox plugin to provide x-veriknox-agent-id.

Logging

Log verbosity is controlled by Kong Gateway’s KONG_LOG_LEVEL environment variable.

Set KONG_VERIKNOX_LOG_PRINT_ALL in KONG_NGINX_MAIN_ENV alongside the other VeriKnox environment variables so Nginx workers can read it:

KONG_NGINX_MAIN_ENV="KONG_VERIKNOX_LOG_PRINT_ALL; env KONG_VERIKNOX_IDENTITY_STATE_DIR; env KONG_VERIKNOX_HUB_BASE_URL"

The VeriKnox plugin ships as part of a custom Kong Gateway image distributed from the VeriKnox ECR registry. It’s not available as a standalone LuaRock.

Note: If you want to try the plugin without installing it against your own data planes, see the Quickstart for a self-contained Docker Compose environment with sample data planes and upstream services.

Prerequisites

Before installing the plugin, you need:

• A VeriKnox account and a site enrollment token to register the data plane identity with VeriKnox Hub.
• AWS credentials with pull access to the VeriKnox ECR registry (510978032592.dkr.ecr.us-east-1.amazonaws.com).
• A Kong Vault to store the identity passphrase. VeriKnox recommends using a Konnect Config Store-backed vault.

Enroll the data plane identity

Before the plugin can sign receipts, each data plane must be enrolled with VeriKnox Hub. Enrollment generates ED25519 and ML-DSA-65 key pairs, encrypts the private keys with the identity passphrase, and registers the public keys with VeriKnox Hub.

Run enrollment as an init container using the 510978032592.dkr.ecr.us-east-1.amazonaws.com/veriknox/kong-init-identity image. The container exits after enrollment completes and doesn’t need to run alongside Kong Gateway:

services:
  kong-init:
    image: 510978032592.dkr.ecr.us-east-1.amazonaws.com/veriknox/kong-init-identity:0.0.9
    restart: "no"
    environment:
      KONG_VERIKNOX_IDENTITY_ENROLLMENT_TOKEN: ${VERIKNOX_ENROLLMENT_TOKEN}
      KONG_VERIKNOX_IDENTITY_PASSPHRASE: ${VERIKNOX_IDENTITY_PASSPHRASE}
      KONG_VERIKNOX_IDENTITY_BASE_URL: https://hub.veriknox.ai
      KONG_VERIKNOX_IDENTITY_STATE_DIR: /data
    volumes:
      - kong-init-volume:/data

The KONG_VERIKNOX_IDENTITY_STATE_DIR and KONG_VERIKNOX_HUB_BASE_URL environment variables must be exposed to Nginx workers via KONG_NGINX_MAIN_ENV so the plugin can read them at runtime. You will use them during installation.

After enrollment, the encrypted identity bundle is written to KONG_VERIKNOX_IDENTITY_STATE_DIR (default: /data):

/data/
└── identity/
    ├── identity.kdf.json
    ├── identity.keys.enc
    └── identity.meta.json

Installation steps

After installing the plugin, enable it on the Routes you want to audit. See the following examples:

• LLM inference: Sign receipts for OpenAI-compatible LLM inference traffic.
• MCP tool call: Sign receipts for Model Context Protocol tool-call requests.

VeriKnox provides a Docker Compose quickstart environment that runs the full stack locally: a Konnect-connected data plane with the VeriKnox plugin, a sample MCP math server, a sample A2A math-agent server, and a test client. Contact your VeriKnox Technical Account Manager to obtain the quickstart files.

Prerequisites

• Docker with the Compose plugin
• The just command runner
• decK (deck)
• AWS credentials with pull access to the VeriKnox ECR registry
• Python 3 with python-dotenv, jinja2, and requests (pip install -r requirements.txt)
• A VeriKnox site enrollment token
• A Konnect personal access token (PAT)
• An OpenAI API key (required for the OpenAI inference and A2A examples)

Example data planes and upstream services

Traffic through the data plane is inspected by the veriknox-plugin before it reaches the upstream service. For each request, the plugin both forwards traffic to the upstream service and posts a signed receipt to VeriKnox Hub, which acts as the policy engine (allow or block) and records the receipt.

 
flowchart LR
    A[Client / AI Agent] --> B
    subgraph DP["kong-dp-0"]
        B[VeriKnox plugin]
    end
    B --> C["Upstream service
(data plane traffic)"]
    B --> D["VeriKnox Hub
(policy engine)"]
  

After just up, the stack includes the following components.

Routes synced from konnect.yml send LLM, MCP, and A2A traffic through the data planes so the plugin can sign receipts to VeriKnox Hub.

What the quickstart does

The ./setup_quickstart script performs the following steps in one run:

1. Creates a VeriKnox site and obtains a site enrollment token, used by kong-init to register the data plane identity with VeriKnox Hub.
2. Creates a Konnect control plane (or selects an existing one) and collects the control plane connection details: the endpoints and mTLS material the data planes use to join hybrid mode.
3. Configures the control plane:
   • Uploads the veriknox-plugin schema.
   • Creates vault secrets, including the identity passphrase.
   • Syncs the gateway configuration with deck gateway sync konnect.yml, or applies the same Services, Routes, and plugins manually in Konnect.
4. Prepares the local runtime: writes .env and renders docker-compose.yml so Compose can run identity enrollment (kong-init), start the data planes, and bring up the sample backends (the MCP math server and the A2A math-agent server).

The script prompts for the enrollment token, Konnect PAT, and OpenAI API key, then provisions Konnect and writes the local files. After it finishes, start the stack with just up.

Run the quickstart

1. Authenticate to the VeriKnox ECR registry:

   aws ecr get-login-password --region us-east-1 \
     | docker login --username AWS --password-stdin \
       510978032592.dkr.ecr.us-east-1.amazonaws.com

   Copied!

2. Run the setup script. When prompted, enter your VeriKnox enrollment token, Konnect PAT, and OpenAI API key. The script provisions the Konnect control plane and writes the local configuration files:

   ./setup_quickstart

   Copied!

3. Start the stack:

   just up

   Copied!

   The gateway is reachable at http://localhost:8080 after identity enrollment completes.

To configure the plugin on your Routes, see the LLM inference and MCP tool call examples.

Manage data planes and upstream services

just up        # Start (pulls ECR images, runs docker-compose.yml)
just down      # Stop, keep containers
just logs      # Follow logs
just shell-dp 0  # Open a shell in kong-dp-0
just shell-agent # Open a shell in the agent test client
just delete    # Unenroll, then stop and remove containers and volumes

Uninstall

To unenroll the data plane identity and tear down the stack:

just delete
./setup_quickstart --deinit