AI agent API traffic: how to use gateway request logs as compliance evidence

Enlarge

When a compliance auditor asks "what did your AI agents actually call last quarter?", most platform teams find out they cannot answer that question. They can show that an AI agent had a token. They can show that the token authenticated. What they cannot show is a record of which API paths were called, with what payloads, at what times, against what response codes. That is the kind of evidence that satisfies a regulator asking about AI agent API traffic in a regulated environment.

Human users typically make a small number of high-value API calls. AI agents make many calls, often in bursts, sometimes against endpoints their operators did not expect. The volume and pattern of agent traffic make the absence of per-request runtime logs far more damaging than the equivalent absence for human users.

The solution is not a separate AI logging system. It is ensuring the gateway already logs every request, including every MCP tool invocation, with enough identity context to answer the compliance question. This post covers exactly how that works in Zerq: what the request logs contain, how to filter them for AI agent activity, how to read an individual record, and how to package the results as compliance evidence.

Why existing approaches fail for AI agent traffic

The most common improvised answer to "how do we log AI agent calls?" is to instrument the agent itself: log the tool calls the agent decides to make before they hit the network. This approach logs intent, not execution. An agent may decide to call an endpoint, hit a network error, and receive a 403. Application-layer logging shows the agent's intent. Gateway logging shows what actually happened at the API layer, including every rejected call, every rate limit hit, and every response code. Gateway logs are produced by the enforcement layer, not by the entity being governed.

Kong, Apigee, AWS API Gateway, and Azure API Management log gateway traffic. None of them have a first-class concept of AI agent identity in their logs. You get the IP address, the API key, maybe a JWT claim. You do not get a structured record that separates "the AI agent running in production" from "the human developer using the same API key for testing." When your access control model does not distinguish agent identity from human identity, your logs cannot either. The compliance query becomes "show me all traffic on this key" rather than "show me what this specific AI agent called."

Zerq uses a dual-header identity model where every request from every client, human or agent, carries an explicit X-Client-ID and X-Profile-ID. That identity context flows through into every request log entry. AI agents get dedicated client records and dedicated profiles, and the logs carry those identifiers. The compliance query "show me everything the order-processing agent called in Q2" is a single filter, not a join across systems.

What the request log captures for every AI agent call

Every request that passes through the Zerq gateway, whether a standard REST call or an MCP tool invocation, produces a log entry with the following fields:

This is the raw material for compliance evidence. A single log entry answers: which agent (Client ID), using which credential set (Profile ID), called which endpoint (Path + Collection), with what payload (Request body), received what response (Status code + Response body), and when (Timestamp). That is the fact set a compliance review needs for every AI agent action.

For MCP tool invocations, the same log structure applies. When an AI agent calls the gateway's MCP endpoint and uses the execute_endpoint tool, the resulting log entry includes the request path (/mcp), the full JSON-RPC request body containing the tool name and parameters, and the response. The X-Client-ID and X-Profile-ID headers identify the agent. No separate MCP-specific logging infrastructure required.

Filtering request logs for AI agent compliance reviews

The Zerq management UI logs page includes a filter panel that writes active filter state into the browser URL. Filtered views can be bookmarked and shared, which is useful when handing off an investigation to a compliance colleague or security team member.

Filtering to a specific AI agent

The most important filter for AI agent compliance work is Client ID. Every AI agent in Zerq has a dedicated client record with a UUID. Filtering by that UUID shows all traffic from that agent, across all of its profiles, across all time periods within your retention window.

1. Open Logs in the sidebar of the management UI.
2. Expand the filter panel.
3. Set Client ID to the agent's client UUID (visible in the client detail page under Access Control > Clients).
4. Set the Time range to cover the review period (preset options: last 1 hour, 24 hours, 7 days, 30 days; or set a custom start and end date).

The result is the complete call history for that agent in that period.

Narrowing to failures and policy denials

For compliance investigations, filter the agent's traffic to non-2xx status codes:

1. Apply the Client ID filter as above.
2. Add a Status code filter set to 4xx or 5xx.

A 401 response means the agent's credential was rejected. A 403 means the agent authenticated but attempted a collection or method it was not permitted to use. A 429 means it exceeded its policy rate limit or quota. These three status codes tell the compliance story: was the agent presenting valid credentials, was it staying within its authorized scope, was it operating within its agreed call volume?

Tracing a specific tool invocation

When an incident occurs and you have a request ID from an upstream error log or a support ticket, trace it directly:

1. Open Logs.
2. Filter by Request ID (the UUID from the X-Request-ID response header).
3. Open the resulting entry.

The detail view shows the complete request and response, including body and headers, plus the matched collection, profile, and target backend URL. This is point-in-time evidence of exactly what an agent called and what it received.

Searching by payload content

For specific compliance questions such as "did the agent ever submit a request containing a particular customer ID?", use the Payload filter, which searches both request body and response body simultaneously:

1. Apply the Client ID and time range filters.
2. Set the Payload filter to the string you are looking for, such as a customer ID, an error code, or a specific field value.

This is useful when investigating whether an agent processed data it should not have had access to, or when correlating a gateway log entry with a downstream system's error record.

Reading a complete log entry for an AI agent call

Here is what a request log entry looks like for an AI agent making an MCP tool call to the gateway. The agent is an order-processing automation using the Gateway MCP to look up and execute an order endpoint.

Log summary row:

2026-06-15T09:14:23.077Z  POST  /mcp  200  client:agent-order-proc  profile:prod-read  collection:Order APIs  312ms

Full detail (relevant fields):

{
  "request_id": "req_7f4b2e9a-1c3d-48f1-b7e0-a2d5c6f891bc",
  "timestamp": "2026-06-15T09:14:23.077Z",
  "method": "POST",
  "path": "/mcp",
  "target_endpoint": "internal:mcp:gateway",
  "status_code": 200,
  "latency_ms": 312,
  "client_id": "cli_a8d2f3b1-4e7c-4190-b2a1-c9f0d8e3a741",
  "profile_id": "prf_3c1e5a9b-72f4-4d8e-9b0a-f1d2c4e6a823",
  "collection": "Order APIs",
  "client_ip": "10.0.4.15",
  "request_headers": {
    "X-Client-ID": "cli_a8d2f3b1-4e7c-4190-b2a1-c9f0d8e3a741",
    "X-Profile-ID": "prf_3c1e5a9b-72f4-4d8e-9b0a-f1d2c4e6a823",
    "Authorization": "Bearer [redacted]",
    "Content-Type": "application/json"
  },
  "request_body": {
    "jsonrpc": "2.0",
    "id": "call-42",
    "method": "tools/call",
    "params": {
      "name": "execute_endpoint",
      "arguments": {
        "collection": "Order APIs",
        "proxy": "GET /orders/{id}",
        "path_params": { "id": "ord_9928471" },
        "query_params": {}
      }
    }
  },
  "response_status": 200,
  "response_body": {
    "order_id": "ord_9928471",
    "status": "processing",
    "items": 3,
    "total": 184.50
  }
}

Every field that matters for compliance is present: the agent's identity (client_id, profile_id), the exact tool it called (execute_endpoint), the parameters it passed (collection, proxy, path_params), the response status, and the response content. The request_id ties this entry to any upstream trace that references the same request.

A compliance workflow: quarterly AI agent access review

Here is a step-by-step workflow for producing compliance evidence of AI agent API activity for a quarterly access review.

1. Enumerate the AI agents in scope. Open Access Control > Clients in the management UI. Filter by name prefix to find agent clients. Note their Client IDs.

2. Pull the request log for each agent. For each Client ID, set the time range to the review quarter and export or screenshot the log summary. The summary shows total request count, failure rate, and the distribution of paths and status codes.

3. Review failure patterns. Filter each agent's log to 4xx responses. A recurring 403 pattern is a sign the agent is attempting endpoints outside its permitted scope. This either means the agent's prompt is directing it to unauthorized paths, or its collection assignments need review. A recurring 429 indicates the agent is hitting its rate limit, which may signal a prompt design issue or a quota that needs adjustment.

4. Verify scope adherence. Pull the list of collections assigned to each agent client from the client detail page. Cross-reference with the unique paths in the agent's request log. Every path in the log should map to a proxy within an assigned collection. A path that does not match should not be accessible; if it returns 200, that is a misconfiguration in the collection assignment.

5. Package the evidence. Export the filtered log views by sharing the URL (which encodes all active filters) with your compliance team, or query the Logs API endpoint programmatically to extract records as structured JSON. The JSON format is compatible with Splunk, Elastic SIEM, Microsoft Sentinel, and similar SIEM platforms for long-term retention and alerting.

Connecting runtime logs to the management audit log

Runtime request logs and management audit logs answer different compliance questions. Both are necessary.

Runtime request logs answer: what did this agent call, when, with what payload, and what came back? This is the evidence layer for AI agent API behavior.

Management audit logs answer: who provisioned this agent's access, when was its rate limit changed, and who rotated its credentials? This is the evidence layer for administrative governance actions.

For a complete compliance picture of an AI agent, you need both. The runtime log shows the agent operated within its approved scope. The management audit log shows the scope was approved by an authorized human with an appropriate role. Together they satisfy the full chain: authorized access was granted, and the agent only exercised that authorized access.

See Zerq's observability capabilities for the full logging model, including how request logs and audit logs integrate with your existing monitoring stack. For how client and profile identity is provisioned for AI agents, see the access control and MCP documentation.

What to check before you need it

Set up AI agent log review before an auditor asks for it, not after:

• Each AI agent has a dedicated client record with a unique Client ID; no shared credentials with human users or other agents
• Each agent's client has a dedicated profile with a unique Profile ID (separate profiles for dev, staging, and production environments)
• Rate limit policies are attached to each agent client, sized to the agent's expected call pattern
• Log retention covers your compliance requirement (financial and healthcare frameworks typically require 90 days minimum; many require longer)
• Your SIEM receives log exports for long-term retention if your log retention window is shorter than your compliance requirement
• MCP tool invocations are included in your log review; the /mcp path should appear in agent exports if the agent uses the Gateway MCP

The request log fields are populated for every request by default. The compliance workflow is a matter of knowing which filters to apply and verifying the data before you need to produce it.

What this looks like in practice

Consider a financial services team running a loan-processing AI agent that calls three internal APIs: credit scoring, identity verification, and a decision engine. The agent has a dedicated client record (agent-loan-proc-prod) with a production profile using mTLS authentication and a policy capping it at 200 requests per minute and a 50,000-request monthly quota.

At the end of Q2, their compliance officer asks for evidence that the agent only accessed approved systems and operated within policy. The platform engineer opens the Logs view, sets Client ID to the agent's UUID, sets the time range to April 1 through June 30, and runs the query. The result shows 34,721 requests: 34,208 with status 200, 513 with status 429 (rate limit hits during peak processing windows), and 0 with status 403. The paths are exclusively /credit/score, /identity/verify, and /decisions/evaluate — the three endpoints the agent is authorized to call.

The compliance officer has what they need: complete traffic data, confirmed scope adherence, and evidence that the rate policy was enforced throughout the quarter. No custom reporting. No data pipeline. A filter and a time range.

Zerq is an enterprise API gateway built for regulated industries — one platform for API management, AI agent access, compliance audit, and developer portal, running entirely in your own infrastructure. See how it works or request a demo to walk through your specific requirements.