Kimi quietly sends full user prompts into ByteDance’s China-based analytics pipeline

RUNTIMEWIRE INVESTIGATION — Exclusive

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

Why it matters

AI 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.

Reporting record

Original reporting by me for RuntimeWire, based on reverse engineering, controlled network interception and primary-source documentation.

I had been using Kimi as my daily driver.

That changed this week.

A day earlier, Anthropic disclosed 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.

After reading that report, I took apart the newest Kimi Windows client and asked a narrower question:

When I type something into Kimi Work and press Send, where else does the text go?

I found another destination.

In a controlled test of Kimi Work 3.2.7, I entered a unique synthetic message into a fresh conversation:

Please reply with exactly RECEIVED.
Test token: RUNTIMEWIRE-KIMI-PRIVACY-35352689

I routed the Windows application through an HTTPS inspection proxy running on my own test machine.

At 14:34:20 UTC, Kimi made this request:

POST https://gator.volces.com/list
Content-Type: application/json; charset=UTF-8

Inside it was an analytics event named:

kimi_work_send_message

And inside that event was this property:

"query":"Please reply with exactly RECEIVED. Test token: RUNTIMEWIRE-KIMI-PRIVACY-35352689"

The phrase was my randomly generated canary. I had entered it once, into Kimi.

The complete prompt had been copied into a product-analytics event and sent to Volcano Engine, ByteDance's enterprise cloud business.

The 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.

That traffic went to gator.volces.com, which Volcano Engine documents as the reporting address for its North China DataFinder analytics environment.

I watched the prompt leave the machine

For the test, I generated a phrase unlikely to exist anywhere else:

RUNTIMEWIRE-KIMI-PRIVACY-35352689

That matters because it gave me an unusually clean provenance chain.

I 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.

The resulting analytics request was 1,756 bytes.

A redacted version of the important portion looks like this:

{
  "events": [
    {
      "event": "kimi_work_send_message",
      "params": {
        "pc_source": "kimi_work",
        "user_id": "[REDACTED]",
        "membership": "Vivace",

        "query": "Please reply with exactly RECEIVED. Test token: RUNTIMEWIRE-KIMI-PRIVACY-35352689",

        "agent_mode": "agent",
        "is_first_message": true,
        "model_name": "k2d6-agent",
        "context_window": 262144,
        "skills": [],
        "plugins": [],
        "permission_mode": "full_permission",
        "chat_id": "[REDACTED]"
      }
    }
  ],

  "user": {
    "user_unique_id": "[REDACTED]",
    "web_id": "[REDACTED]"
  },

  "header": {
    "app_id": 20001731,
    "app_version": "3.2.7",
    "os_name": "windows",
    "os_version": "10",
    "device_brand": "HP",
    "platform": "desktop",
    "sdk_version": "5.1.12_tob",
    "sdk_lib": "js",
    "language": "en-US"
  }
}

I redacted my persistent account, session and conversation identifiers.

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 controlling what its local agent can do to files and the computer.

During the session, my proxy indexed 213 HTTPS requests from the test environment. Forty-one went to gator.volces.com.

Only one captured request contained my canary prompt.

So 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.

/list is an analytics ingestion endpoint

The URL deserves explanation.

Typing 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.

Volcano 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 accepts single events at /v2/event/json and batches at /v2/event/list.

In ordinary product analytics, an application might report something like:

{
  "event": "message_sent",
  "model": "k3",
  "platform": "windows",
  "message_length": 87
}

Kimi's event included:

{
  "event": "kimi_work_send_message",
  "query": "the complete text the user typed"
}

A 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 to study user behavior and optimize conversion.

Volcano Engine itself is much larger. The company's website identifies it as ByteDance's cloud-service platform, commercializing technology and growth systems developed inside ByteDance.

Calling Volcano Engine "the Chinese Amplitude" would therefore be misleading. DataFinder is the Amplitude-like piece inside a broader ByteDance cloud and data stack.

Kimi's own code tells the same story

The packet capture did not come out of nowhere.

Before intercepting the traffic, I unpacked the app.asar archive distributed with Kimi Work 3.2.7 and traced the relevant telemetry path.

The packaged application defines:

SEND_MESSAGE_EVENT = "kimi_work_send_message"

Its send-message analytics builder takes the user's submitted query and places it directly into the event:

{
  query: input.query,
  filename: ...,
  filetype: ...,
  work_dir: ...,
  project_name: input.projectName,
  agent_mode: ...,
  model_name: ...,
  context_window: input.contextWindow,
  skills: [...],
  plugins: [...],
  permission_mode: input.permissionMode,
  chat_id: ...
}

That object is attached to:

kimi_work_send_message

The same application initializes an analytics tracker with:

app_id: 20001731
channel_domain: "https://gator.volces.com"

and ultimately reports events through:

window.collectEvent(...)

My static analysis therefore predicted a path that looked like this:

submitted user query
        ->
query: input.query
        ->
kimi_work_send_message
        ->
collectEvent(...)
        ->
gator.volces.com

The live network test then produced exactly that path.

I recorded the tested app.asar archive with SHA-256:

c0f672d96c12d4a5028913c426ce847523ee78bfb78e8c39321f355ce590c4f4

That makes the result reproducible against the specific application package I examined.

My U.S. test went to Volcano Engine's North China analytics endpoint

There was another detail in the hostname.

Volcano Engine documents different reporting addresses for different DataFinder environments.

For Windows, Web JS and other clients, its reporting-address documentation identifies:

https://gator.volces.com

as the SaaS cloud-native North China reporting address.

The same documentation separately gives:

https://gator.uba.ap-southeast-1.volces.com

for its overseas SaaS environment in Southeast Asia/Johor. For the domestic HTTP environment, the documentation specifies North China 2 - Beijing.

I conducted my test in the United States.

Kimi nevertheless configured the Windows client I examined to send its analytics to:

gator.volces.com

I am describing the service region documented by Volcano Engine, rather than claiming that my packet capture establishes the physical location of a particular server.

This routing is consistent with Kimi's general privacy policy, 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.

So the China-region endpoint itself is not evidence of a hidden cross-border transfer.

It does establish where Kimi configured this analytics stream to go.

Kimi tells users it collects conversations. The analytics disclosure is narrower.

Kimi does not promise that conversations remain entirely on a user's computer.

Its current privacy policy 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."

Kimi'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.

The 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.

That 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.

The more specific disclosure is where things get interesting.

Kimi maintains a Third-Party Information Sharing List describing individual SDKs and service providers.

For the Growth Marketing Suite SDK, Kimi lists:

• purpose: automated marketing management;
• use scenario: data analysis and precision marketing;
• third party: Beijing Volcano Engine Technology Co., Ltd.;
• 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.

The entry does not specifically name user prompts or conversation content among the information involved.

Kimi'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.

My network test found the exact contents of a Kimi Work prompt inside an event going to that company's analytics infrastructure.

Kimi'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.

It 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?

There is another wrinkle. Kimi's policy says it will not provide advertising partners with conversation content, input/output files or other information reflecting a user's specific usage.

Volcano 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.

[COMPANY RESPONSE PLACEHOLDER]

DataFinder is designed to look at individual users, too

An analytics event is not necessarily anonymous simply because it lives in an analytics system.

The request I captured paired the prompt with values including:

user_unique_id
web_id
session_id
chat_id

Volcano 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.

DataFinder's underlying event model describes properties as dimensions attached to events, including custom business properties reported through params.

That does not prove a Kimi employee can open DataFinder today and browse raw prompts.

I do not have access to Moonshot's DataFinder account, its permissions, its retention settings or any internal dashboards.

It 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.

That makes access and retention important unanswered questions.

The raw prompt is a choice in Kimi's instrumentation

Volcano Engine's Web/JS documentation exposes a filterEvent hook that processes event data before reporting. Developers can modify an event before it is sent.

Kimi's packaged code then makes its own behavior quite explicit:

query: input.query

In other words, DataFinder does not require the semantic contents of an AI conversation merely to record that the user pressed Send.

Kimi chose to make the submitted text a property of kimi_work_send_message.

For ordinary usage measurement, an event could carry information such as:

message sent
model used
message length
latency
tokens
agent mode
success or failure

There are legitimate product-analysis reasons a company may want message content as well: classifying requests, understanding feature usage, debugging failures or measuring response quality.

Those purposes come with a different privacy profile because the event can contain whatever the user typed.

I 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.

Kimi is built for material people normally consider sensitive

This would be a smaller finding if Kimi were marketed primarily as a toy chatbot.

Kimi Work is explicitly sold as a desktop agent for serious knowledge work.

Moonshot's own examples 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.

Kimi's product page 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.

Those are the kinds of jobs where prompts naturally acquire business context.

Public users are already describing exactly that kind of usage.

A Japanese-language writer described using Kimi 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.

An English-language Kimi API user wrote in July that they "work with sensitive files" 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.

And I had been using Kimi as my own daily driver.

After seeing the request I captured in this investigation, I am not doing that anymore.

Anthropic's report is why I looked

This investigation began after a far more dramatic allegation.

Anthropic said this month that Moonshot had secretly forwarded Kimi customer requests to Claude and returned Claude's responses to users who thought they were interacting with Kimi.

Anthropic 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.

Anthropic also said the relayed requests exposed sensitive material.

According 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.

Across May through July, Anthropic attributed more than 23 million exchanges to Moonshot's distillation activity.

I found no evidence that Volcano Engine was involved in that Claude-routing operation.

The paths are separate:

Anthropic's finding:

Kimi customer
     ->
Moonshot
     ->
Claude / Anthropic

My finding:

My test
     ->
Kimi Work 3.2.7
     ->
kimi_work_send_message
     ->
Volcano Engine DataFinder

The connection is governance of the same unusually sensitive object: the user's prompt.

After 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.

The analytics stream was sitting inside the application.

Sending AI content to analytics is not unheard of

There is useful industry context here.

Amplitude, one of the best-known U.S. product-analytics companies, now sells an Agent Analytics product specifically for AI applications. Its setup documentation openly provides three privacy modes.

In 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.

So the industry comparison is not "analytics systems never receive AI conversations."

Some do.

The 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.

Kimi's Windows client, in the test I performed, sent my full prompt.

I 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.

What my test establishes

I can directly support the following findings:

There are also important things this experiment does not establish.

I have not yet shown that every Kimi message is copied to DataFinder. The captured event contained:

"is_first_message": true

I need a second-message control before saying this happens on every turn.

I have not established the same behavior in Kimi's normal Chat mode, web app, macOS app or mobile apps.

I do not know Kimi's retention configuration for this event.

I do not know which Moonshot employees can access the query property.

I do not know whether Volcano Engine personnel can access it.

I have not shown the prompt being used for advertising, audience construction, model training, recommendation systems or any downstream VeDI product.

I have not shown Volcano Engine forwarding it anywhere else.

Questions Moonshot still needs to answer

RuntimeWire 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.

We 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.

RuntimeWire reached out to Moonshot AI and Volcano Engine for comment. We will update this story when we hear back.

This is why analytics architecture matters for AI

For years, product analytics has been built around interactions:

opened app
clicked button
started trial
finished checkout
returned seven days later

Generative AI changes the payload.

The interaction itself may be:

Here is our unreleased acquisition plan.
Tell me what could derail the deal.

or:

I pasted the production error below.
Find the bug.

or:

Read these product plans and build the GTM deck.

For 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.

Kimi's own marketing encourages precisely those workflows.

That makes one field in my packet unusually consequential:

"query":"..."

The analytics system did not receive a count of messages.

It received the message I typed.

And after Anthropic's disclosure about where some Kimi customer requests had already gone, that is something Kimi users deserve to understand.