{"slug": "kimi-quietly-sends-full-user-prompts-into-bytedances-china-based-analytics", "title": "Kimi quietly sends full user prompts into ByteDance’s China-based analytics pipeline", "summary": "RuntimeWire found that Kimi Work 3.2.7 copied a complete user prompt verbatim into a kimi_work_send_message product-analytics event sent to gator.volces.com, a Volcano Engine DataFinder reporting endpoint. The finding came from a controlled HTTPS capture, static analysis of the app.asar archive, and inspection of 213 outbound HTTPS requests using the synthetic token RUNTIMEWIRE-KIMI-PRIVACY-35352689, with the tested package recorded by SHA-256 as c0f672d96c12d4a5028913c426ce847523ee78bfb78e8c39321f355ce590c4f4. RuntimeWire requested comment from Moonshot AI, the company behind Kimi, which had not responded by publication time; the disclosure follows Anthropic's report that Moonshot AI relayed almost 300,000 customer requests through Claude over one ten-day period.", "body_md": "# Kimi quietly sends full user prompts into ByteDance’s China-based analytics pipeline\n\n**I intercepted a verbatim Kimi Work 3.2.7 prompt inside a `kimi_work_send_message` event uploaded to Volcano Engine's DataFinder analytics system, alongside user, conversation and device identifiers. The company's specific disclosure for the analytics SDK lists device, network, location and application information, without specifically naming conversation text.**\n\n        By [Ryan Merket](/author/ryan-merket)\n        · Published \n\n**RUNTIMEWIRE INVESTIGATION** — Exclusive\n\nOriginal reporting by RuntimeWire, based on documents, testing, reverse engineering.\n\n## Why it matters\n\nAI prompts can contain the crown jewels of a company: source code, credentials, contracts, customer data and unreleased plans. Copying that text into analytics turns a conversation into an additional behavioral-data record, expanding the privacy and security exposure around material users may assume is only being processed to answer them.\n\n## Reporting record\n\n### Finding\n\nRuntimeWire established that Kimi Work 3.2.7 copied a complete user prompt into a kimi_work_send_message product-analytics event sent to gator.volces.com.\n\n### How we verified\n\nMethods: documents, testing, reverse engineering.\n\nA controlled HTTPS capture showed the synthetic prompt verbatim in the query property of a kimi_work_send_message event; static analysis of the Kimi Work 3.2.7 app.asar traced input.query to that event and the gator.volces.com analytics endpoint; Volcano Engine documentation identifies the endpoint as a DataFinder reporting address.\n\nRuntimeWire unpacked and analyzed the Kimi Work 3.2.7 app.asar archive, traced its analytics code, routed the Windows client through an HTTPS inspection proxy, entered a unique synthetic prompt in a fresh conversation, and inspected 213 outbound HTTPS requests, including the captured analytics payload.\n\nTested versions: Kimi Work 3.2.7.\n\n### Reproduction\n\nRuntimeWire independently reproduced the core finding.\n\nUse the tested Kimi Work 3.2.7 application package, recorded by SHA-256 as c0f672d96c12d4a5028913c426ce847523ee78bfb78e8c39321f355ce590c4f4. Route the Windows application through an HTTPS inspection proxy, enter the synthetic prompt containing RUNTIMEWIRE-KIMI-PRIVACY-35352689 in a fresh conversation, and inspect outbound traffic for a POST to https://gator.volces.com/list containing a kimi_work_send_message event with the prompt in its query property.\n\n### Company response\n\nRuntimeWire requested comment; the company had not responded by publication time.\n\n*Original reporting by me for RuntimeWire, based on reverse engineering, controlled network interception and primary-source documentation.*\n\nI had been using Kimi as my daily driver.\n\nThat changed this week.\n\nA day earlier, [Anthropic disclosed](https://www.anthropic.com/threat-intelligence-report-september-2026) that Moonshot AI, the company behind Kimi, had secretly routed some Kimi customer requests through Claude. Anthropic said it observed almost 300,000 customer requests relayed over one ten-day period, including requests containing surveillance material, internal corporate source code and live credentials. Moonshot saved at least some of those exchanges and used them in a chain-of-thought extraction pipeline, according to Anthropic.\n\nAfter reading that report, I took apart the newest Kimi Windows client and asked a narrower question:\n\n**When I type something into Kimi Work and press Send, where else does the text go?**\n\nI found another destination.\n\nIn a controlled test of Kimi Work 3.2.7, I entered a unique synthetic message into a fresh conversation:\n\n```\nPlease reply with exactly RECEIVED.\nTest token: RUNTIMEWIRE-KIMI-PRIVACY-35352689\n```\n\nI routed the Windows application through an HTTPS inspection proxy running on my own test machine.\n\nAt 14:34:20 UTC, Kimi made this request:\n\n```\nPOST https://gator.volces.com/list\nContent-Type: application/json; charset=UTF-8\n```\n\nInside it was an analytics event named:\n\n```\nkimi_work_send_message\n```\n\nAnd inside that event was this property:\n\n```\n\"query\":\"Please reply with exactly RECEIVED. Test token: RUNTIMEWIRE-KIMI-PRIVACY-35352689\"\n```\n\nThe phrase was my randomly generated canary. I had entered it once, into Kimi.\n\n**The complete prompt had been copied into a product-analytics event and sent to Volcano Engine, ByteDance's enterprise cloud business.**\n\nThe same event carried persistent user, browser and conversation identifiers, Kimi membership status, the selected model, agent mode, Windows version, computer model and other device metadata.\n\nThat traffic went to `gator.volces.com`, which [Volcano Engine documents as the reporting address](https://www.volcengine.com/docs/6287/1544684?lang=zh&utm_source=chatgpt.com) for its North China DataFinder analytics environment.\n\n### I watched the prompt leave the machine\n\nFor the test, I generated a phrase unlikely to exist anywhere else:\n\n```\nRUNTIMEWIRE-KIMI-PRIVACY-35352689\n```\n\nThat matters because it gave me an unusually clean provenance chain.\n\nI typed the token into Kimi. I did not place it in a filename, environment variable, web page or any other application. Then I inspected outbound traffic generated by Kimi itself.\n\nThe resulting analytics request was 1,756 bytes.\n\nA redacted version of the important portion looks like this:\n\n```\n{\n  \"events\": [\n    {\n      \"event\": \"kimi_work_send_message\",\n      \"params\": {\n        \"pc_source\": \"kimi_work\",\n        \"user_id\": \"[REDACTED]\",\n        \"membership\": \"Vivace\",\n\n        \"query\": \"Please reply with exactly RECEIVED. Test token: RUNTIMEWIRE-KIMI-PRIVACY-35352689\",\n\n        \"agent_mode\": \"agent\",\n        \"is_first_message\": true,\n        \"model_name\": \"k2d6-agent\",\n        \"context_window\": 262144,\n        \"skills\": [],\n        \"plugins\": [],\n        \"permission_mode\": \"full_permission\",\n        \"chat_id\": \"[REDACTED]\"\n      }\n    }\n  ],\n\n  \"user\": {\n    \"user_unique_id\": \"[REDACTED]\",\n    \"web_id\": \"[REDACTED]\"\n  },\n\n  \"header\": {\n    \"app_id\": 20001731,\n    \"app_version\": \"3.2.7\",\n    \"os_name\": \"windows\",\n    \"os_version\": \"10\",\n    \"device_brand\": \"HP\",\n    \"platform\": \"desktop\",\n    \"sdk_version\": \"5.1.12_tob\",\n    \"sdk_lib\": \"js\",\n    \"language\": \"en-US\"\n  }\n}\n```\n\nI redacted my persistent account, session and conversation identifiers.\n\n`permission_mode:\"full_permission\"` in this packet appears to describe Kimi Work's agent execution mode. I found no evidence that it represents consent to analytics collection, and I am not treating it as such. [Kimi separately documents permission modes](https://www.kimi.ai/help/kimi-work/kimi-work-faq?utm_source=chatgpt.com) controlling what its local agent can do to files and the computer.\n\nDuring the session, my proxy indexed **213 HTTPS requests** from the test environment. Forty-one went to `gator.volces.com`.\n\nOnly **one** captured request contained my canary prompt.\n\nSo my finding is not that Kimi transmitted the prompt 41 times. It is that among the client's normal analytics traffic, one event contained the entire message I had entered into the conversation.\n\n### `/list` is an analytics ingestion endpoint\n\nThe URL deserves explanation.\n\nTyping `https://gator.volces.com/list` into a browser is not supposed to display a dashboard or a directory of data. It is an **ingestion endpoint**: software sends batches of tracked events to it with an HTTP POST.\n\nVolcano Engine's DataFinder stack uses an event model built around `user`, `header` and `events`, with `params` carrying properties associated with an event. [DataFinder's documented server-side counterpart](https://docs.byteplus.com/en/docs/DataFinder/HTTP_API) accepts single events at `/v2/event/json` and batches at `/v2/event/list`.\n\nIn ordinary product analytics, an application might report something like:\n\n```\n{\n  \"event\": \"message_sent\",\n  \"model\": \"k3\",\n  \"platform\": \"windows\",\n  \"message_length\": 87\n}\n```\n\nKimi's event included:\n\n```\n{\n  \"event\": \"kimi_work_send_message\",\n  \"query\": \"the complete text the user typed\"\n}\n```\n\nA useful American comparison is **Amplitude or Mixpanel**. DataFinder performs the same broad product-analytics job: applications report events and properties, and teams use those events to understand behavior, conversion, retention and users. Volcano Engine describes DataFinder as part of its data-intelligence offering and [shows customers using it](https://www.volcengine.com/docs/6281/1264549?utm_source=chatgpt.com) to study user behavior and optimize conversion.\n\nVolcano Engine itself is much larger. [The company's website identifies it](https://www.volcengine.com/about?utm_source=chatgpt.com) as ByteDance's cloud-service platform, commercializing technology and growth systems developed inside ByteDance.\n\nCalling Volcano Engine \"the Chinese Amplitude\" would therefore be misleading. **DataFinder** is the Amplitude-like piece inside a broader ByteDance cloud and data stack.\n\n### Kimi's own code tells the same story\n\nThe packet capture did not come out of nowhere.\n\nBefore intercepting the traffic, I unpacked the `app.asar` archive distributed with Kimi Work 3.2.7 and traced the relevant telemetry path.\n\nThe packaged application defines:\n\n```\nSEND_MESSAGE_EVENT = \"kimi_work_send_message\"\n```\n\nIts send-message analytics builder takes the user's submitted query and places it directly into the event:\n\n```\n{\n  query: input.query,\n  filename: ...,\n  filetype: ...,\n  work_dir: ...,\n  project_name: input.projectName,\n  agent_mode: ...,\n  model_name: ...,\n  context_window: input.contextWindow,\n  skills: [...],\n  plugins: [...],\n  permission_mode: input.permissionMode,\n  chat_id: ...\n}\n```\n\nThat object is attached to:\n\n```\nkimi_work_send_message\n```\n\nThe same application initializes an analytics tracker with:\n\n```\napp_id: 20001731\nchannel_domain: \"https://gator.volces.com\"\n```\n\nand ultimately reports events through:\n\n```\nwindow.collectEvent(...)\n```\n\nMy static analysis therefore predicted a path that looked like this:\n\n``` php\nsubmitted user query\n        ->\nquery: input.query\n        ->\nkimi_work_send_message\n        ->\ncollectEvent(...)\n        ->\ngator.volces.com\n```\n\nThe live network test then produced exactly that path.\n\nI recorded the tested `app.asar` archive with SHA-256:\n\n```\nc0f672d96c12d4a5028913c426ce847523ee78bfb78e8c39321f355ce590c4f4\n```\n\nThat makes the result reproducible against the specific application package I examined.\n\n### My U.S. test went to Volcano Engine's North China analytics endpoint\n\nThere was another detail in the hostname.\n\nVolcano Engine documents different reporting addresses for different DataFinder environments.\n\nFor Windows, Web JS and other clients, [its reporting-address documentation](https://www.volcengine.com/docs/6287/1544684?lang=zh&utm_source=chatgpt.com) identifies:\n\n```\nhttps://gator.volces.com\n```\n\nas the SaaS cloud-native North China reporting address.\n\nThe same documentation separately gives:\n\n```\nhttps://gator.uba.ap-southeast-1.volces.com\n```\n\nfor its overseas SaaS environment in Southeast Asia/Johor. For the domestic HTTP environment, the documentation specifies **North China 2 - Beijing**.\n\nI conducted my test in the United States.\n\nKimi nevertheless configured the Windows client I examined to send its analytics to:\n\n```\ngator.volces.com\n```\n\nI am describing the **service region documented by Volcano Engine**, rather than claiming that my packet capture establishes the physical location of a particular server.\n\nThis routing is consistent with [Kimi's general privacy policy](https://www.kimi.com/user/agreement/userPrivacy?version=v2), which says personal information is stored within the People's Republic of China and will not be provided outside China without separate consent and compliance with applicable rules.\n\nSo the China-region endpoint itself is not evidence of a hidden cross-border transfer.\n\nIt does establish where Kimi configured this analytics stream to go.\n\n### Kimi tells users it collects conversations. The analytics disclosure is narrower.\n\nKimi does not promise that conversations remain entirely on a user's computer.\n\n[Its current privacy policy](https://www.kimi.com/user/agreement/userPrivacy?version=v2) explicitly says it collects conversation information, including text and other content users input and receive. Its description of device and log information even includes user IDs, conversation IDs and \"conversation content.\"\n\nKimi's current privacy policy was updated August 24th and took effect August 31st, after the May-July period covered by Anthropic's findings; RuntimeWire is evaluating the current Windows client against the disclosures in force during our September test, not retroactively applying the current policy to that earlier conduct.\n\nThe policy also permits third-party service providers to process personal information for functions including technical support and data analysis, while saying those processors should receive only the information necessary for their duties.\n\nThat matters for fairness: **my finding should not be read as evidence that Kimi secretly receives the messages users send to Kimi.** A cloud AI service necessarily processes user inputs, and Kimi's policy acknowledges that.\n\nThe more specific disclosure is where things get interesting.\n\nKimi maintains a [Third-Party Information Sharing List](https://www.kimi.com/user/agreement/SDKSharing?version=v2) describing individual SDKs and service providers.\n\nFor the **Growth Marketing Suite SDK**, Kimi lists:\n\n- purpose: automated marketing management;\n- use scenario: data analysis and precision marketing;\n- third party: Beijing Volcano Engine Technology Co., Ltd.;\n- personal information involved: device identifiers, device hardware information, operating-system information, network information, IP and Wi-Fi information, precise location information, application information and related categories.\n\nThe entry does **not specifically name user prompts or conversation content** among the information involved.\n\nKimi's disclosure is capable of being specific about content: elsewhere on the same page it explicitly says Volcano's speech API receives uploaded audio files and that a contract-review provider receives uploaded files and contracts. The Growth Marketing Suite entry does not similarly identify prompts or conversation text.\n\nMy network test found the exact contents of a Kimi Work prompt inside an event going to that company's analytics infrastructure.\n\nKimi's general privacy policy is broader, and the SDK list itself ends its enumeration with \"etc.\" I am therefore **not asserting that the omission, by itself, establishes a legal violation**.\n\nIt does create an obvious disclosure question: why does the specific analytics-SDK entry describe device, network, location and application information without telling users that the text they enter into Kimi can also become an analytics event property?\n\nThere is another wrinkle. [Kimi's policy says](https://www.kimi.com/user/agreement/userPrivacy?version=v2) it will not provide advertising partners with conversation content, input/output files or other information reflecting a user's specific usage.\n\nVolcano Engine may be acting here as an entrusted data processor rather than an \"advertising partner\" under that policy, so the sentence does not automatically conflict with my capture. The distinction is exactly the kind of thing Moonshot should explain.\n\n#### [COMPANY RESPONSE PLACEHOLDER]\n\n### DataFinder is designed to look at individual users, too\n\nAn analytics event is not necessarily anonymous simply because it lives in an analytics system.\n\nThe request I captured paired the prompt with values including:\n\n```\nuser_unique_id\nweb_id\nsession_id\nchat_id\n```\n\nVolcano Engine's own DataFinder documentation describes **user-level drilldown** that can locate users using identifiers including UUID and `WEB_ID`, then display an individual's behavior flow in chronological order. It also documents custom identifiers and AI-assisted analysis of an individual user's behavior.\n\nDataFinder's underlying event model describes properties as dimensions attached to events, including custom business properties reported through `params`.\n\nThat does **not** prove a Kimi employee can open DataFinder today and browse raw prompts.\n\nI do not have access to Moonshot's DataFinder account, its permissions, its retention settings or any internal dashboards.\n\nIt does show that Kimi sends the `query` into a system designed for event-property analysis and per-user behavior inspection, alongside identifiers that DataFinder knows how to use.\n\nThat makes access and retention important unanswered questions.\n\n### The raw prompt is a choice in Kimi's instrumentation\n\n[Volcano Engine's Web/JS documentation](https://www.volcengine.com/docs/84129/1582317?lang=zh&utm_source=chatgpt.com) exposes a `filterEvent` hook that processes event data **before reporting**. Developers can modify an event before it is sent.\n\nKimi's packaged code then makes its own behavior quite explicit:\n\n```\nquery: input.query\n```\n\nIn other words, DataFinder does not require the semantic contents of an AI conversation merely to record that the user pressed Send.\n\nKimi chose to make the submitted text a property of `kimi_work_send_message`.\n\nFor ordinary usage measurement, an event could carry information such as:\n\n```\nmessage sent\nmodel used\nmessage length\nlatency\ntokens\nagent mode\nsuccess or failure\n```\n\nThere are legitimate product-analysis reasons a company may want message content as well: classifying requests, understanding feature usage, debugging failures or measuring response quality.\n\nThose purposes come with a different privacy profile because the event can contain whatever the user typed.\n\nI asked Moonshot why the full query is needed, how long it is retained and whether users can prevent prompt content from entering this analytics stream.\n\n### Kimi is built for material people normally consider sensitive\n\nThis would be a smaller finding if Kimi were marketed primarily as a toy chatbot.\n\nKimi Work is explicitly sold as a desktop agent for serious knowledge work.\n\n[Moonshot's own examples](https://www.kimi.com/en/help/kimi-work/use-cases) tell users to have Kimi analyze their investment holdings, clean locally stored research datasets, and read **product plans, industrial-design prototypes and GTM plans** from local folders before logging into subscription databases to prepare a client-facing report.\n\n[Kimi's product page](https://www.kimi.ai/products/kimi-work?utm_source=chatgpt.com) describes the agent as \"deeply connected\" to local files and pitches it for financial analysis, earnings reports and spreadsheet reconciliation. Its broader product documentation says Kimi Work can access local datasets and produce executive reports from company sales records.\n\nThose are the kinds of jobs where prompts naturally acquire business context.\n\nPublic users are already describing exactly that kind of usage.\n\nA Japanese-language writer [described using Kimi](https://note.com/yarxaria/n/n9c0077fe6135?hl=en) on a Q2 sales CSV to generate a strategy presentation, checking contracts with Kimi before sending them to an outside law firm, automating monthly reports from roughly ten CSV files, and using it to summarize meeting minutes. The same writer cautioned that Kimi Work accesses the computer and recommended carefully managing folders containing confidential information.\n\nAn English-language Kimi API user [wrote in July that they \"work with sensitive files\"](https://www.reddit.com/r/kimi/comments/1vadksy/kimis_file_handing_via_their_api_is_a_security/?utm_source=chatgpt.com) and complained that an erroneous line of code had uploaded dozens of copies of a sensitive PDF to Kimi's cloud. That report concerns Kimi's API file workflow rather than the Kimi Work analytics path I tested, but it is another real-world example of users entrusting sensitive material to the Kimi product family.\n\nAnd I had been using Kimi as my own daily driver.\n\nAfter seeing the request I captured in this investigation, I am not doing that anymore.\n\n### Anthropic's report is why I looked\n\nThis investigation began after a far more dramatic allegation.\n\n[Anthropic said this month](https://www.anthropic.com/threat-intelligence-report-september-2026) that Moonshot had secretly forwarded Kimi customer requests to Claude and returned Claude's responses to users who thought they were interacting with Kimi.\n\nAnthropic said one ten-day period included almost **300,000 customer requests**, most routed to Opus through a proxy network of **5,380 fraudulent accounts**. It said Moonshot saved at least some of the exchanges and built a chain-of-thought extraction pipeline from the captured material.\n\nAnthropic also said the relayed requests exposed sensitive material.\n\nAccording to the report, one apparent PLA-affiliated user submitted surveillance data from hundreds of CCTV cameras while believing Kimi was processing it. In another case, an engineer working on an internal system for a major Chinese state-owned enterprise exposed internal code and live credentials. Anthropic said the user had no way to know those requests were being sent to Claude.\n\nAcross May through July, Anthropic attributed **more than 23 million exchanges** to Moonshot's distillation activity.\n\nI found **no evidence that Volcano Engine was involved in that Claude-routing operation**.\n\nThe paths are separate:\n\n``` php\nAnthropic's finding:\n\nKimi customer\n     ->\nMoonshot\n     ->\nClaude / Anthropic\n```\n\nMy finding:\n\n``` php\nMy test\n     ->\nKimi Work 3.2.7\n     ->\nkimi_work_send_message\n     ->\nVolcano Engine DataFinder\n```\n\nThe connection is governance of the same unusually sensitive object: **the user's prompt**.\n\nAfter Anthropic showed that some Kimi users could not tell which AI company was receiving their requests, I wanted to know what other systems receive data from the Windows client.\n\nThe analytics stream was sitting inside the application.\n\n### Sending AI content to analytics is not unheard of\n\nThere is useful industry context here.\n\nAmplitude, one of the best-known U.S. product-analytics companies, now sells an Agent Analytics product specifically for AI applications. [Its setup documentation](https://www.amplitude.com/docs/amplitude-ai/agent-analytics/setup) openly provides three privacy modes.\n\nIn its `full` mode, message content, system prompts and tool inputs and outputs can be sent to Amplitude. A `metadata_only` mode sends tokens, cost, latency, model and session information while keeping message content out. Amplitude says PII redaction is enabled by default in full mode and says regulated environments typically use one of the modes that does not send raw content.\n\nSo the industry comparison is not \"analytics systems never receive AI conversations.\"\n\nSome do.\n\nThe interesting variables are **what gets collected, how explicitly that is disclosed, what redaction exists, who can query the content, how long it remains there and whether customers can choose a metadata-only configuration**.\n\nKimi's Windows client, in the test I performed, sent my full prompt.\n\nI have not yet found evidence establishing equivalent behavior - or its absence - in ChatGPT, Claude, Gemini or Copilot desktop clients. A proper competitor comparison requires instrumenting each product rather than reading privacy policies and assuming their network behavior.\n\n### What my test establishes\n\nI can directly support the following findings:\n\n| Finding | Status | \n|---|---|\n| Kimi Work 3.2.7 generated a `kimi_work_send_message` analytics event | **Confirmed** | \n| The event's `query` property contained my entire submitted prompt | **Confirmed** | \n| The event was POSTed to `gator.volces.com/list` | **Confirmed** | \n| The event carried user, conversation/session and device identifiers | **Confirmed** | \n| Kimi's packaged code explicitly populates `query` from the submitted user query | **Confirmed** | \n| The app configures the analytics tracker with `gator.volces.com` | **Confirmed** | \n| [Volcano Engine documents `gator.volces.com` for its North China DataFinder environment](https://www.volcengine.com/docs/6287/1544684?lang=zh&utm_source=chatgpt.com) | **Confirmed** | \n| [Kimi's Growth Marketing Suite disclosure names Volcano Engine and data analysis/precision marketing](https://www.kimi.com/user/agreement/SDKSharing?version=v2) | **Confirmed** | \n\nThere are also important things this experiment does **not** establish.\n\nI have not yet shown that every Kimi message is copied to DataFinder. The captured event contained:\n\n```\n\"is_first_message\": true\n```\n\nI need a second-message control before saying this happens on every turn.\n\nI have not established the same behavior in Kimi's normal Chat mode, web app, macOS app or mobile apps.\n\nI do not know Kimi's retention configuration for this event.\n\nI do not know which Moonshot employees can access the `query` property.\n\nI do not know whether Volcano Engine personnel can access it.\n\nI have not shown the prompt being used for advertising, audience construction, model training, recommendation systems or any downstream VeDI product.\n\nI have not shown Volcano Engine forwarding it anywhere else.\n\n### Questions Moonshot still needs to answer\n\nRuntimeWire asked Moonshot why Kimi Work sends the complete user query into its Volcano Engine analytics stream, whether the behavior applies to every message and other Kimi clients, how long the text is retained, who can access it, and whether users can disable it.\n\nWe also asked Volcano Engine whether Kimi's query field is available inside DataFinder, how it is classified and retained, whether Volcano personnel can access it, and whether the data can flow into other VeDI services.\n\nRuntimeWire reached out to Moonshot AI and Volcano Engine for comment. We will update this story when we hear back.\n\n### This is why analytics architecture matters for AI\n\nFor years, product analytics has been built around interactions:\n\n```\nopened app\nclicked button\nstarted trial\nfinished checkout\nreturned seven days later\n```\n\nGenerative AI changes the payload.\n\nThe interaction itself may be:\n\n```\nHere is our unreleased acquisition plan.\nTell me what could derail the deal.\n```\n\nor:\n\n```\nI pasted the production error below.\nFind the bug.\n```\n\nor:\n\n```\nRead these product plans and build the GTM deck.\n```\n\nFor an agent that can operate on local files, browser sessions and professional datasets, the text surrounding a \"send message\" event can contain much richer information than an ordinary button click.\n\n[Kimi's own marketing encourages precisely those workflows](https://www.kimi.com/en/help/kimi-work/use-cases).\n\nThat makes one field in my packet unusually consequential:\n\n```\n\"query\":\"...\"\n```\n\nThe analytics system did not receive a count of messages.\n\nIt received the message I typed.\n\nAnd after Anthropic's disclosure about where some Kimi customer requests had already gone, that is something Kimi users deserve to understand.", "url": "https://wpnews.pro/news/kimi-quietly-sends-full-user-prompts-into-bytedances-china-based-analytics", "canonical_source": "https://runtimewire.com/article/kimi-quietly-sends-full-user-prompts-into-bytedance-s-china-based-analytics-pipe", "published_at": "2026-09-11 16:52:10+00:00", "updated_at": "2026-09-11 17:13:26.782543+00:00", "lang": "en", "topics": ["ai-policy", "ai-ethics", "ai-products"], "entities": ["Kimi", "Kimi Work 3.2.7", "Moonshot AI", "ByteDance", "Volcano Engine", "DataFinder", "Anthropic", "RuntimeWire"], "alternates": {"html": "https://wpnews.pro/news/kimi-quietly-sends-full-user-prompts-into-bytedances-china-based-analytics", "markdown": "https://wpnews.pro/news/kimi-quietly-sends-full-user-prompts-into-bytedances-china-based-analytics.md", "text": "https://wpnews.pro/news/kimi-quietly-sends-full-user-prompts-into-bytedances-china-based-analytics.txt", "jsonld": "https://wpnews.pro/news/kimi-quietly-sends-full-user-prompts-into-bytedances-china-based-analytics.jsonld"}}