Do Son 
A developer at RuntimeWire recently identified a privacy issue within Moonshot AI’s Kimi Work desktop client. When a user submits a feedback report inside the application, the client uploads not only the necessary diagnostic logs but also automatically packages and transmits the five most recently updated agent session records. Critically, the feedback interface never explicitly discloses these session attachments, nor does it offer any option to opt out of the upload individually.
Submitting Feedback Can Inadvertently Expose Unrelated Work
The developer’s analysis focused on Kimi Work for Windows v3.1.5, the official Kimi desktop client, along with its automatically installed Daimon 0.5.49 background component. The investigation revealed that upon feedback submission, the client reads the full list of Kimi Work sessions, sorts them by last update time, and selects the five most recently modified sessions – rather than uploading only the specific session the user is currently reporting an issue about.
This means that even when a user submits feedback about a minor, unrelated software glitch, other recent work – separate coding projects, document processing tasks, or unrelated agent automation runs – may be automatically bundled and sent to the Kimi team for analysis. This behavior is triggered only when a user actively clicks the feedback button within the app; sessions are not uploaded if feedback is never submitted.
Uploaded Sessions Contain Full Raw Execution Data
Notably, the uploaded data extends well beyond ordinary chat text. Kimi Work reads the raw execution records from each agent session, which can include model requests, tool definitions, MCP tool metadata, and data generated as the agent invokes tools and carries out tasks.
According to the developer’s analysis, each session can include up to 100 record files, with a maximum of the last 500 JSONL entries read from each file, and a compressed data cap of roughly 8MB per session. In theory, this means five sessions could produce up to approximately 40MB of raw session data – on top of the client’s separately uploaded diagnostic logs.
The client does apply some filtering during upload – for instance, stripping out large Base64-encoded data blocks and truncating excessively long strings – but this filtering is based purely on data size. It does not actively detect or exclude passwords, other sensitive data, or file paths. Consequently, if sensitive information appears as plain text within an agent’s execution logs, it could be swept up and transmitted along with the feedback data.
The Core Problem: No Disclosure Before Upload
It is important to note that no evidence currently suggests this constitutes a security vulnerability in the traditional sense. The core issue instead concerns the scope of data collection and whether users are adequately informed. At present, Kimi Work’s feedback window prompts users to describe their issue and optionally attach a screenshot, but it never explicitly lists the five most recent agent sessions that are about to be uploaded alongside the report – nor does it offer an attachment preview, individual selection controls, or a way to disable session uploads entirely.
For an ordinary application, automatically uploading diagnostic logs to assist with troubleshooting is standard and unremarkable practice. However, a desktop AI agent application has access to a considerably broader scope of user data. A more appropriate design would have Kimi Work clearly display exactly which sessions and files are about to be uploaded before a user submits feedback, allowing them to review, select, or fully disable this data transmission on their own terms.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
