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

Moonshot AI's Kimi Work desktop app attaches raw diagnostic records from the five most recent agent conversations to every user feedback submission, according to a RuntimeWire analysis of Kimi Desktop 3.1.5. The app uploads ZIP archives of these conversations alongside a diagnostic log package, with no consent or disclosure, and the company's help page does not mention this data collection. The behavior was confirmed via a firewall test that blocked the uploads, logging 'ok: 0/5 archives uploaded in 166ms'.

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 https://www.kimi.com/help/membership/membership-contact 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 https://www.kimi.com/code/docs/en/kimi-code-cli/guides/sessions.html . 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 https://www.kimi.com/user/agreement/userPrivacy?version=v2 , 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.