Two layers decide what a desktop agent touches. The prompt layer says what to do. The permission layer says what is allowed. RuntimeWire's review of the packaged code found that the override replaces the composed system prompt for new conversations while tool permissions stay separately enforced [8]. That split is the finding. The permission layer classifies by tool class, not by path, and Kimi Code's own built-in tool documentation marks Read, Grep, Glob and ReadMediaFile automatically allowed while writes, edits and shell commands require approval [11]. That is four read-class tools with nothing standing in front of them [2]. Text in the prompt layer is therefore sufficient to move bytes off disk and into an answer.
The write test is the part that convinced me the mechanism is understood rather than guessed. RuntimeWire denied a Write action, watched the agent attempt an alternate route, and saw the permission system block both attempts [18]. The gate works as specified. That specification places it in front of writes and shell only [11]. Read is the tool that never asks for approval, and once the instructions in the prompt are not the user's own, that is the problem.
Timing sets the severity. Moonshot released 3.2.4 for Windows on August 31st [6], and RuntimeWire's test ran on September 2nd [5], two days after ship [1]. The tested stack is named down to the component: @kimi/daimon 0.5.64, @moonshot-ai/agent-core 0.15.7, bundled Kimi Code 0.36.0 [7]. This is a general-availability desktop build, in a product Moonshot describes as running on the Kimi Code kernel [12] and markets as a system-level digital employee that organizes folders, analyzes local data, drives a browser and produces documents [13].
Treat the result as a claim about someone else's configuration until you check three things in your own. Does your agent's permission table mark read-class tools auto-allow? Is the workspace root enforced inside the tool implementation, or only described to the model in the prompt? And can anything other than the end user set that prompt, such as a shared template, an org policy field or a packaged default? If all three hold, the folder picker organizes where the agent looks; it does not limit where the agent can actually read, and no approval dialog will tell you that.
On evidence quality: the A/B ran in separate new conversations with the user prompt, workspace and permission mode held constant, using disposable files carrying unique synthetic canaries [19]. With the override active, an ordinary math question produced one tool call and returned the exact contents of a file outside the selected workspace [3]. With the default prompt restored, the identical question produced no tool call and no canary [4]. Packages, screenshots and hashes were preserved, including app(9).asar and the daimon bundle [16], no real credentials were touched, and RuntimeWire's localhost listener recorded zero requests [17]. That last detail is worth reading carefully: the canary reached the model's context, and the test establishes a local read rather than a network egress.
This is single-sourced reverse engineering, by RuntimeWire's own account [2]. Activation details, operational prompts and public reproduction steps are withheld pending vendor review [15], and Moonshot had not responded to a request for comment by publication [14]. So you cannot run it yourself yet. You can read your agent's tool table today, which in my context is where the boundary now lives: the agent gets its own OS user, and secrets live somewhere that user cannot read.
