Kimi Work secretly attaches raw records from five recent agent sessions to feedback reports

RUNTIMEWIRE INVESTIGATION — Scoop

Original reporting by RuntimeWire, based on reverse engineering, testing.

Why it matters

Kimi Work can handle private files, source code and shell output. Packaging five recent sessions without listing them prevents users from reviewing the data attached to feedback.

Reporting record

Moonshot AI's Kimi Work desktop app is designed to attach raw diagnostic records from five recent agent conversations whenever a user submits feedback, a RuntimeWire analysis of the Windows application found.

The collection reaches beyond the task a user is reporting. Kimi Desktop sorts every locally registered Work conversation by its last update time, takes the newest five and asks a bundled background service to create a separate ZIP archive for each one. It uploads those archives alongside a desktop diagnostic-log package before sending the feedback text.

RuntimeWire confirmed the behavior on an installed copy of Kimi Desktop 3.1.5 using a Windows firewall rule that blocked outbound traffic from Kimi.exe. The test opened feedback from Kimi Work's Plugins page and submitted the harmless phrase "RuntimeWire test." Kimi immediately attempted a multipart upload containing its diagnostic archive. It then tried to upload raw-record archives associated with five distinct recent conversation IDs.

All five attempts failed with net::ERR_NETWORK_ACCESS_DENIED, as intended. Kimi's own main-process log recorded five failures within five milliseconds, followed by:

[FeedbackRawRecords] ok: 0/5 archives uploaded in 166ms

The firewall kept the records from leaving the machine and confirmed production execution of the handler.

A generic feedback form reaches across recent work

The Plugins feedback screen was a particularly revealing entry point. Its internal metadata identified the report as coming from the plugin hub, and that version of the form disables user image attachments. Submitting it still invoked the same global collection routine used by feedback from the account menu, an active conversation and Kimi's generated-website preview.

The renderer starts two background operations before it submits the report:

Promise.allSettled([
  feedbackUploadLogs(),
  feedbackUploadRawRecords()
])

The raw-record handler calls conversations.list, sorts the returned conversations by updatedAt, and applies .slice(0, 5). It does not receive the current conversation as an argument. An internal comment in Kimi's shipped preload code describes the method as exporting and uploading the five most recent sessions, with the selection fixed in the desktop main process.

Each completed upload returns an object name. Kimi places those identifiers in a hidden metadata prefix inside the feedback body under rawRecordsObjectNames. The normal file_object_names attachment field is reserved for images the user selected.

That division matters at the interface. The English form invites the user to describe a problem and says images can be uploaded or pasted. It does not list the diagnostic archive, the five conversation archives or their combined potential size. There is no attachment preview, consent box or control for selecting a relevant session.

Kimi's public help page says in-product reports automatically attach "device and account context." It does not mention raw records from recent agent sessions. The company's help documentation was current when RuntimeWire reviewed it on August 15.

What Kimi puts in a raw-record archive

Kimi Work uses a bundled background component named Daimon. The Windows package RuntimeWire examined was version 0.5.49, created July 24. It advertises and registers a production control method called conversations.getRawRecordsArchive, then wires that route to the archive generator used during feedback submission.

For each selected conversation, Daimon discovers the main agent's wire.jsonl file and records belonging to any subagents. It can include as many as 100 record files in one conversation archive and reads the last 500 JSONL records from each file. A single compressed ZIP is capped at 8 MiB, making the client-side ceiling 40 MiB across five raw-record archives, plus the separate desktop log package.

Kimi's own documentation describes agents/main/wire.jsonl as the main agent's "complete communication record." The files support session recovery and replay. They also carry request traces containing tool schemas, request parameters and MCP tool listings, according to the company's session documentation.

Daimon does apply bounded sanitization. It removes strings that look like large base64 blobs, replaces oversized values with length-and-hash markers and limits ordinary strings to 8,192 characters. Those checks are based on size and encoding. The code does not look for passwords, API keys, access tokens, private source code, shell output or sensitive file paths. An ordinary string within the size limit is retained verbatim.

Malformed or unusually large JSONL records receive a diagnostic replacement containing a 256-character preview. The archive manifest also records local session paths, record paths, identifiers and processing statistics.

Kimi's CLI offers a separate, explicit session-export flow. Its documentation warns that exported files may contain code, command output and file paths and tells users to review the contents before sharing. The feedback workflow provides no comparable warning or review step.

What the privacy policy says

Moonshot AI's privacy policy, effective August 4, says the company may collect conversation information, feedback data and logs that can include conversation content. That language covers broad categories of information handled by Kimi.

The implementation makes a narrower product choice that users cannot see at submission: a plugin report, website-preview report or general account report can carry bounded records from five unrelated recent Work sessions. Those sessions may involve different projects, folders, clients or credentials.

The shipping client performs the collection as part of its ordinary feedback handler. This is a collection-scope and disclosure problem. The test did not uncover a remote exploitation path.

RuntimeWire found no public documentation of the five-session selection and no previous public result for the internal method name conversations.getRawRecordsArchive or the logging tag FeedbackRawRecords.

Moonshot AI should explain when the behavior shipped, which desktop versions and platforms include it, how long uploaded archives are retained, who can access them and whether the server performs additional redaction. Users also need a way to inspect the proposed attachments, limit collection to the session being reported and submit feedback without providing conversation records.

How RuntimeWire tested it

RuntimeWire examined the production ASAR from Kimi Desktop 3.1.5 and a Windows x64 Daimon 0.5.49 bundle. Static analysis traced the feedback button from the renderer through Electron IPC, ZIP generation, /file/upload_simple and /user/feedback.

For the runtime test, outbound Windows Firewall access was blocked for the signed Kimi.exe executable before the application was started. RuntimeWire submitted harmless plugin feedback and observed the resulting local logs. The application selected five conversation IDs and reached the upload stage for each archive. Every external request failed with ERR_NETWORK_ACCESS_DENIED. RuntimeWire did not inspect or transmit the conversations' record contents.

The principal file hashes and detailed limits are available in RuntimeWire's reporter notes.