AI Gateway audit log reference

AI Gateway emits structured analytics logs for AI plugins through the standard Kong Gateway logging infrastructure. This means AI-specific logs are written to the same locations as other Kong logs, such as /usr/local/kong/logs/error.log, or to Docker container logs if you’re running in a containerized environment.

Like other Kong logs, AI Gateway logs are subject to the global log level configured via the kong.conf file or the Admin API. You can control log verbosity by adjusting the log_level setting (for example, info, notice, warn, error, crit) to determine which log entries are captured.

You can also use logging plugins to route these logs to external systems, such as file systems, log aggregators, or monitoring tools.

Each AI plugin returns a set of tokens. Log entries include the following details:

AI Proxy core logs

The AI Proxy and AI Proxy Advanced plugins act as the main gateway for forwarding requests to AI providers. Logs here capture detailed information about the request and response payloads, token usage, model details, latency, and cost metrics. They provide a comprehensive view of each AI interaction.

Logs and metrics for cost and token usage via the OpenAI Files API are not currently supported.

AI AWS Guardrails logs v3.11+

If you’re using the AI AWS Guardrails plugin, AI Gateway logs include fields under the ai.proxy.aws-guardrails object. These fields capture processing latency, the guardrails configuration applied, block reasons, and masking behavior.

AI GCP Model Armor logs v3.12+

If you’re using the AI GCP Model Armor plugin, AI Gateway logs include fields under the ai.proxy.gcp-model-armor object. These fields capture the template applied, processing latency, and reasons for blocking when content is flagged.

AI Azure Content Safety logs

If you’re using the AI Azure Content Safety plugin, AI Gateway writes to two separate log paths.

The first path records per-category severity data from the Azure Content Safety API. Each entry represents a category that breached its configured rejection threshold. Multiple entries can appear per request depending on which categories were configured and what was detected.

For information on categories and severity levels, see Harm categories in Azure AI Content Safety.

The second path records plugin metadata and block reasons under the ai.proxy.azure-content-safety object:

AI Lakera Guard logs v3.13+

If you’re using the AI Lakera Guard plugin, AI Gateway logs include additional fields under the ai.proxy.lakera-guard object. These fields capture processing latency, Lakera-assigned request UUIDs, block reasons, and violation details when requests or responses are blocked.

AI Custom Guardrail logs v3.14+

If you’re using the AI Custom Guardrail plugin, AI Gateway logs include additional fields under the custom-guardrail object. These fields record guardrail processing latency, block reasons, and the source and consumer identity associated with any triggered guards.

The following fields appear in structured AI logs when the AI Custom Guardrail plugin is enabled:

The plugin also allows you to define custom metrics based on Lua expressions.

AI PII Sanitizer logs v3.10+

If you’re using the AI PII Sanitizer plugin, AI Gateway logs include additional fields that provide insight into the detection and redaction of personally identifiable information (PII). These fields track the number of entities identified and sanitized, the time taken to process the payload, and detailed metadata about each sanitized item, including the original value, redacted value, and detected entity type.

AI Prompt Compressor logs v3.11+

When the AI Prompt Compressor plugin is enabled, additional logs record token counts before and after compression, compression ratios, and metadata about the compression method and model used.

AI RAG Injector logs v3.10+

If you’re using the AI RAG Injector plugin, AI Gateway logs include additional fields that provide detailed information about the retrieval-augmented generation process. These fields track the vector database used, whether relevant context was injected into the prompt, the latency of data fetching, and embedding metadata such as tokens used and the embedding provider and model used.

AI Semantic Cache logs v3.8+

If you’re using the AI Semantic Cache plugin, AI Gateway logs include additional fields under the cache object for each plugin entry. These fields provide insight into cache behavior, such as whether a response was served from cache, how long it took to fetch, and which embedding provider and model were used if applicable.

Note: When returning a cached response, time_per_token and llm_latency are omitted. The cache response can be returned either as a semantic cache or an exact cache. If it’s returned as a semantic cache, it will include additional details such as the embeddings provider, embeddings model, and embeddings latency.

AI LLM as Judge logs v3.12+

If you’re using the AI LLM as Judge plugin, AI Gateway logs include additional fields under the ai-llm-as-judge object. These fields provide insight into evaluation behavior, such as which models were scored, latency, and the numeric accuracy assigned by the judge.

AI MCP logs v3.12+

If you’re using the AI MCP plugin, AI Gateway logs include additional fields under the ai.mcp object. These fields provide insight into Model Context Protocol (MCP) traffic, including session IDs, JSON-RPC request/response payloads, latency, tool usage, and v3.13+ access control audit entries.

Note: Unlike other available AI plugins, the AI MCP plugin is not invoked as part of an AI request. Instead, it is registered and executed as a regular plugin, allowing it to capture MCP traffic independently of AI request flow. Do not configure the AI MCP plugin together with other ai-* plugins on the same service or route.

The MCP log structure groups traffic by MCP session ID, with each session containing zero or more recorded JSON-RPC requests:

AI A2A Proxy logs v3.14+

If you’re using the AI A2A Proxy plugin, AI Gateway logs include additional fields under the ai.a2a object when config.logging.log_statistics is enabled. These fields provide observability into Agent-to-Agent (A2A) protocol traffic, including operation names, task lifecycle state, latency, streaming metrics, and optional request/response payloads.

When config.logging.log_statistics is enabled, the plugin writes the following fields to the ai.a2a.rpc[] array:

LLM traffic entry

The following example shows a structured AI Gateway log entry:

{
  "ai": {
    "payload": {
      "request": "$OPTIONAL_PAYLOAD_REQUEST"
    },
    "proxy": {
      "payload": {
        "response": "$OPTIONAL_PAYLOAD_RESPONSE"
      },
      "usage": {
      "time_per_token": 30.142857142857,
      "time_to_first_token": 631,
      "completion_tokens": 21,
      "completion_tokens_details": {
        "rejected_prediction_tokens": 0,
        "reasoning_tokens": 0,
        "accepted_prediction_tokens": 0,
        "audio_tokens": 0
      },
      "prompt_tokens_details": {
        "cached_tokens": 0,
        "audio_tokens": 0
      },
      "prompt_tokens": 14,
      "total_tokens": 35,
      "cost": 0
    },
      "meta": {
        "request_model": "command",
        "provider_name": "cohere",
        "response_model": "command",
        "plugin_id": "546c3856-24b3-469a-bd6c-f6083babd2cd",
        "llm_latency": 2670
      },
      "cache": {
        "cache_status": "Hit",
        "fetch_latency": 12,
        "embeddings_provider": "openai",
        "embeddings_model": "text-embedding-ada-002",
        "embeddings_latency": 42
      },
      "aws-guardrails": {
        "guardrails_id": "gr-1234abcd",
        "guardrails_version": "DRAFT",
        "aws_region": "us-west-2",
        "mode": "BOTH",
        "input_processing_latency": 134,
        "output_processing_latency": 278,
        "input_block_reason": "",
        "output_block_reason": "",
        "input_block_source": "",
        "output_block_source": "",
        "input_block_consumer_id": "",
        "output_block_consumer_id": "",
        "guards_triggered_count": 0
      },
      "rag-inject": {
        "vector_db": "pgvector",
        "injected": true,
        "fetch_latency": 154,
        "chunk_ids": ["chunk-1", "chunk-2"],
        "embeddings_latency": 37,
        "embeddings_tokens": 62,
        "embeddings_provider": "openai",
        "embeddings_model": "text-embedding-ada-002"
      }
    },
    "compressor": {
      "original_token_count": 845,
      "compress_token_count": 485,
      "save_token_count": 360,
      "compress_value": 0.5,
      "compress_type": "rate",
      "compressor_model": "microsoft/llmlingua-2-bert-base-multilingual-cased-meetingbank",
      "msg_id": 1,
      "information": "Compression was performed and saved 360 tokens"
    },
    "sanitizer": {
      "pii_identified": 3,
      "pii_sanitized": 3,
      "duration": 65,
      "sanitized_items": [
        {
          "entity_type": "EMAIL",
          "original": "jane.doe@example.com",
          "sanitized": "[REDACTED]"
        },
        {
          "entity_type": "PHONE_NUMBER",
          "original": "555-123-4567",
          "sanitized": "[REDACTED]"
        }
      ]
    },
    "audit": {
      "azure_content_safety": {
        "Hate": "High",
        "Violence": "Medium"
      }
    }
  }
}

MCP traffic entry

The following example shows an MCP log entry:

{
  "ai": {
    "mcp": {
      "mcp_session_id": "abc123session",
      "rpc": [
        {
          "method": "tools/call",
          "latency": 6,
          "id": "2",
          "response_body_size": 5030,
          "tool_name": "list_orders"
        }
      ],
      "audit": [
        {
          "primitive_name": "list_orders",
          "consumer": {
            "id": "6c95a611-9991-407b-b1c3-bc608d3bccc3",
            "name": "admin",
            "identifier": "consumer_group"
          },
          "scope": "primitive",
          "primitive": "tool",
          "action": "allow"
        }
      ]
    }
  }
}