Kimi Work 3.2.4's hidden system prompt override triggered local file reads without approval

A controlled Windows test reproduced the read in Manual approval mode; a restored-default control stayed clean, and no network transmission occurred.

By · Published · Updated

RUNTIMEWIRE INVESTIGATION — Scoop

Original reporting by RuntimeWire, based on reverse engineering.

Why it matters

Kimi Work's docs promise that Manual approval prevents action without consent. Auto-approved reads let system-level instructions expose local data before users see a gate.

Reporting record

Finding

Kimi Work 3.2.4 contains an undocumented system-prompt override that caused an unrelated request to trigger a local-file read outside the selected workspace, while separate permission controls continued to block write and shell actions.

How we verified

Methods: reverse engineering.

RuntimeWire reviewed first-party packaged components and conducted controlled A/B tests using synthetic data. With the override active, an ordinary math question triggered one tool call and returned the exact contents of a synthetic file outside the selected workspace. After restoring the default prompt and opening a new conversation, the identical question produced no tool call and no canary. A separate test showed the agent attempting an alternate route after a denied Write action; the permission system blocked both attempts. Original packages, screenshots, test materials and cryptographic hashes were preserved. No real credentials were accessed, and the localhost listener recorded zero requests.

RuntimeWire compared default and override-enabled configurations in separate new conversations while keeping the user prompt, workspace and permission mode constant. Testing used disposable files containing unique synthetic canaries. Potentially modifying actions were rejected. Packaged-code review independently confirmed that the setting replaces the composed system prompt for new conversations while tool permissions remain separately enforced. Activation details, operational prompts and internal interfaces are withheld pending vendor review.

Tested versions: Kimi Work for Windows 3.2.4, @kimi/daimon 0.5.64, @moonshot-ai/agent-core 0.15.7, bundled Kimi Code 0.36.0.

Reproduction

RuntimeWire independently reproduced the core finding.

Reproduced internally using controlled synthetic data. Public reproduction instructions are withheld because they would disclose the feature’s activation mechanism and operational prompts. Full details can be provided privately to the vendor or an editor under embargo.

File hashes

  • sha256:6ec2f17949cceedc325857bc6a38afa48a2cd979e748d444e998865cd3020d78 app(9).asar
  • sha256:8e26364ab4a0f33c4284cca083cf94b5f48622bf6e3960067b4100e18ed1b670 daimon-bundle.tar(1).gz

Company response

RuntimeWire requested comment; the company had not responded by publication time.

A computer screen displays a chat application answering a math question, while lines of text suggesting local file access flicker subtly in the background.

Moonshot AI co-founder and CEO Yang Zhilin has a permission problem inside Kimi Work: RuntimeWire testing on September 2nd found that a buried system-prompt override could make the desktop agent read an unrelated local file while answering a benign math question, without showing a read-approval dialog.

The finding was reproduced on Kimi Work 3.2.4 for Windows, which Moonshot released on August 31st. The test used a synthetic canary file and an A/B control. With the custom instruction enabled, Kimi made one local-file tool call and returned the canary. After restoring the default prompt, opening a new conversation and submitting the identical math question, Kimi made no tool call and returned no canary.

That control isolates the custom system instruction as the cause. It also exposes a conflict between Kimi Work's interface and Moonshot's description of what its strictest interactive permission setting does.

Manual approval does not cover reads

Kimi Work offers Default, Manual approval and Fully automatic permission levels. Moonshot's privacy FAQ says that under Manual approval, "nothing happens without your consent." The test showed that local reads can happen without that consent.

The reason is visible in the developer documentation for the underlying agent runtime. Moonshot describes Kimi Work as running on the Kimi Code kernel. Kimi Code's built-in tool documentation designates Read, Grep, Glob and ReadMediaFile as automatically allowed. File writes, edits and shell commands require approval by default.

That division can be defensible for a coding agent operating inside a repository the user deliberately opened. It is harder to reconcile with a desktop product marketed to knowledge workers and described by Moonshot as a "system-level digital employee." Kimi Work is designed to organize folders, analyze local data, operate a browser and produce documents. An auto-approved read therefore reaches material far beyond source code: financial models, client documents, research files and personal records can all sit inside the agent's accessible workspace.

Manual approval still provided protection at other boundaries during RuntimeWire's test. A denied write operation did not proceed. A separate attempt to send the synthetic canary to a listener bound to 127.0.0.1:8765 produced zero captured requests. The testing supports a local-read finding. It does not establish data exfiltration, remote code execution or a bypass of every permission check.

A powerful setting with little context

The prompt override was reachable through a five-click path in Kimi Work's settings and could be saved as an enabled replacement for the agent's normal instructions. Once active, it persisted into a new conversation and influenced tool selection even when the user's request had no relationship to local files.

Moonshot does document a comparable mechanism for developers. Kimi Code supports a SYSTEM.md override that can permanently replace the main agent's built-in system prompt. Those docs explain the precedence rules, warn that the file owns the entire prompt unless it includes specific template variables, and frame the capability as explicit agent configuration.

Kimi Work puts the same class of control into a graphical desktop product whose users may never see a terminal or inspect a prompt file. The desktop release notes for 3.2.4 mention citation display, typography, Windows process monitoring and general stability fixes. They do not describe the prompt-override control or its interaction with file permissions. RuntimeWire verified the behavior in 3.2.4 and has not established which earlier desktop build introduced the setting.

The mechanism also differs from a conventional prompt-injection attack. The test instruction was deliberately entered through Kimi Work's own settings by a person with local access. There is no evidence that an external webpage, document or remote user can switch on the override. The exposure arises after the setting is enabled: custom text receives system-level authority, while local read tools remain available without per-operation consent.

Moonshot is moving from models into machines

Yang's career has centered on giving language models longer memory and broader operating range. He earned a Ph.D. from Carnegie Mellon University in 2019, worked at Google Brain and Meta AI, and co-authored Transformer-XL and XLNet. Moonshot has since pushed Kimi from a chat interface into a local agent that can manipulate files, run code and operate browsers.

Kimi Work launched on June 3rd and remains in beta. Moonshot added the three global permission levels in version 3.2.2 on August 26th, less than a week before the tested release. The company is iterating quickly: six numbered Kimi Work updates landed between August 19th and August 31st.

That pace makes precise permission language essential. Users selecting Manual approval are making a security decision, not adjusting a convenience preference. Kimi Work's broker distinguishes reads from writes, while its privacy documentation tells users that every action waits for consent. RuntimeWire's canary test shows the practical consequence of that mismatch: an instruction the user cannot see in the conversation can make the agent retrieve unrelated local data before the interface asks anything at all.

Reader comments

Conversation for this story loads after sign-in.