Kimi Audit Logs: Separate Control-Plane Events From Model Requests

Kimi splits its evidence across two systems. The organization audit feed records console management and login events. It also records Admin API operations. A separate request-details feed records model usage by project and credential. Security teams need both. A credential-rotation event and an inference request answer different questions.

I would reject an audit pack that exports one feed and labels it complete. A complete record has to connect the administrative change and the model request to the enterprise policy decision that allowed the request to leave.

TL;DR

• Kimi audit logs cover organization events such as credential changes, member changes, login results, project changes, and IP whitelist updates.
• Kimi request details identify the model, project, inference credential, token counts, and a client request ID, with a 90-day retention window.
• Neither feed records the enterprise user behind a shared application credential. It also omits the prompt data class and the policy decision applied before inference.
• Correlate both Kimi feeds with an independent request record captured on the authenticated HTTP route to the model.

Kimi exposes two evidence planes

The Kimi Admin API overview calls the service a control-plane API. Its credentials manage organization resources. They also query billing and usage alongside audit data. Those admin credentials cannot call inference endpoints, while inference credentials cannot call the Admin API.

The control-plane feed answers who changed a project, member, credential, rate limit, or IP whitelist. The inference-usage feed answers which project and credential called a model, how many tokens passed, and when the request was recorded. A screenshot with 20 rows in the console can look complete while still covering only one plane.

The organization audit feed starts when an admin enables it

Kimi's audit log endpoint requires an Admin API key with the audit:read scope. An organization administrator must also enable audit logging in the console. While logging is disabled, the endpoint returns an empty list that looks identical to a period with no events.

Enabling the feature starts collection at that moment. Kimi says earlier activity is not backfilled, and gaps created while logging is disabled are unrecoverable. The first review step should therefore capture the enablement event and the earliest available timestamp, rather than treating an empty response as proof that nothing happened.

The event list covers inference credentials and Admin API credentials. It also covers members, projects, spend limits, rate limits, and the IP whitelist. Separate event types capture successful and failed logins. Querying the feed creates an audit_log.read event, which gives the export process its own trail.

Kimi limits one audit-log query to a 31-day window. Pagination returns at most 100 events per page, newest first. An evidence collector has to restate the same filters on every page because the cursor stores position rather than validating the query. Changing a filter while reusing the cursor can mix results from different searches.

Request details provide correlation without prompt context

The request-details endpoint produces one row per inference request. Each row identifies the Kimi request, time, model, and inference key, plus the project. It reports prompt and completion token counts. Cached-token counts and a client request ID are included too.

The client request ID is the strongest bridge in the current API. Kimi tells callers to send X-Msh-Client-Request-Id with the inference request. The platform persists that value as client_request_id, which lets a gateway or application match its own record to Kimi's row without guessing from a timestamp and token count.

Request details arrive on a delay. Data for day T becomes available at 07:00 UTC+8 on day T+1. Kimi retains these rows for 90 days and caps one query at 31 days. The operational consequence is plain: export before day 90. Preserve the client request ID with the provider row and the enterprise record it matches. The LLM audit-log retention guide explains why provider windows and regulatory evidence periods need separate records.

The row omits prompt text, response text, upstream employee identity, prompt classification, and the enterprise policy result. That omission is sensible for a billing feed. It also means the feed cannot prove that a specific employee was allowed to send a restricted data class to Kimi K2 at 14:07.

Shared credentials weaken attribution

Kimi organizes access as organizations and projects, with API credentials attached to that structure. Its organization guide recommends separate credentials for each project member and says removing a member invalidates every credential that person created. It also supports project budgets and token-per-minute limits. An organization-wide IPv4 whitelist is available.

These controls improve attribution only when the credential maps cleanly to a workload or person. A backend service that handles 400 employees can still send every request through one project credential. Kimi then identifies the project and credential accurately, while the initiating employee remains upstream.

Picture the incident review: one browser tab shows a request-details row with a project ID and 8,214 prompt tokens beside a client request ID. Another tab shows the application login. The useful evidence is the join between those two tabs, plus the policy record that says why the request was allowed. Without the join, the provider row names infrastructure rather than the person or agent that caused the call.

I think every production model request should carry a caller-generated correlation ID. Timestamp matching is an avoidable source of false attribution.

Retention and zero-data-retention need separate tests

Kimi's zero data retention documentation says enterprise customers can request a mode that deletes prompts and responses after the response returns. The same page excludes operational data such as security logs and billing records from zero data retention. It also excludes Batch API jobs and directly uploaded images or videos. Data processed by third-party models or connectors, plus plugins, is excluded as well.

Prompt and response content may disappear immediately under the approved configuration, while request metadata remains available for security and billing. Kimi also warns that it cannot troubleshoot individual request content after deletion. It tells customers to retain their own request logs.

A procurement review should capture the signed enterprise arrangement and enabled scope. It should also capture excluded services and a test request. The Kimi OpenPlatform terms dated July 30, 2026 say customer content may be used to provide, maintain, develop, support, improve, secure, and police the service unless a separate written agreement changes those terms. The product documentation describes enterprise training and retention protections. Keep the executed agreement beside the technical setting instead of inferring contract scope from a public page.

Build the audit package around one request

Start with one known model call and preserve its client request ID. Export the matching Kimi request-details row after the provider's next-day availability point. Record the project, inference credential, model, token counts, and Kimi request ID.

Next, export the control-plane events around the same deployment window. Review credential creation and rotation, plus member updates and edited projects. Check rate limits, whitelist updates, and audit-log enablement separately. Preserve the query start, end, filters, cursor sequence, and export time.

Then attach the enterprise-side request record. It should identify the authenticated person or agent, application route, data classification, destination model, policy version, allow or deny result, and correlation ID. The AI gateway architecture places that record on the routed model call. Test a missing identity, an unapproved model, a restricted data class, and a direct call that bypasses the approved route.

Kimi's IP whitelist can constrain calls to approved public IPv4 egress addresses. It supports up to 20 addresses or ranges and currently excludes IPv6. That control can narrow the network path, but it still identifies the organization's egress rather than the employee behind a shared application.

Product boundary

Kimi's Admin API and member lifecycle stay with Moonshot AI and the customer's platform team. So do project budgets, credential rotation, IP whitelist, and provider retention. Kimi Code CLI execution and local files also remain outside an HTTP policy gateway, along with shell commands and credentials.

DeepInspect applies when an authenticated user or agent sends a model request through the configured proxy to the Kimi API. It can evaluate the supplied identity, role, route, model, and prompt classification before forwarding the request. The resulting decision record can carry the same client request ID used to reconcile Kimi's request-details row.

Direct calls that bypass the proxy remain outside that evidence path. The release test has to prove that the approved application uses the routed endpoint and that unapproved direct egress is blocked by a separate network control.

DeepInspect

DeepInspect can sit inline on a deliberately routed Kimi API connection. It evaluates identity and data policy before the prompt reaches the model, then records the decision independently with the client request ID, policy version, model route, and outcome.

That record complements Kimi's two feeds. The Admin API shows who changed provider-side controls. Request details show which credential and project called which model. DeepInspect supplies the authenticated caller and prompt classification. It also supplies the enterprise policy decision for the routed request. Book a technical deep dive at deepinspect.ai.