AI Gateway audit log reference

AI Gateway emits structured analytics logs for AI Policies following the same patterns as Kong Gateway. This means AI Gateway 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 a data plane in a containerized environment.

You can set the global log level for AI Gateway 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.

When operating AI Gateway alongside Kong Gateway, logs are stored separately in each product’s run time environment.

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

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

Core logs

AI Gateway logs 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

If you use the AI AWS Guardrails Policy, 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

If you use the AI GCP Model Armor Policy, 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 use the AI Azure Content Safety Policy, 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 Policy metadata and block reasons under the ai.proxy.azure-content-safety object:

AI Lakera Guard logs

If you use the AI Lakera Guard Policy, 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

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

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

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

AI PII Sanitizer logs

If you use the AI PII Sanitizer Policy, 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

When the AI Prompt Compressor Policy 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

If you use the AI RAG Injector Policy, 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

If you use the AI Semantic Cache Policy, AI Gateway logs include additional fields under the cache object for each Policy 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

If you use the AI LLM as Judge Policy, 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

If you create an AI MCP Server, 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 access control audit entries.

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

If you create an AI Agent, AI Gateway logs include additional fields under the ai.a2a object when 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, it 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"
        }
      ]
    }
  }
}