它能读懂你的代码，也能偷走你的SSH密钥：一个CLI智能体的安全边疆实测
我第一次在终端里输入kimi acp并看到Zed编辑器成功连上那个本地WebSocket服务时，心里是真有点激动的。不是因为功能多炫，而是因为——这是第一个把ACP协议从RFC文档拉进真实终端进程的开源实现。它没用Docker、没堆Kubernetes、甚至没写一行CUDA核函数，就靠一个轻量Python进程，在本地搭起了编辑器与云端大模型之间的实时意图通道。这种“做出来”的能力，值得敬意。但敬意归敬意，作为每天要给生产环境签安全SLA的人，我必须说：这个通道的门开着，门锁被拆了，钥匙还扔在门口的台阶上。
有意思的是，它想成为什么？ 它不想做另一个ChatGPT终端版。它想当你的“数字同事”——坐在你旁边那台空电脑前，听懂你随口说的“把API路由按模块拆成子包”，立刻打开项目目录扫一遍routes.py和models.py，再调出编辑器光标所在文件的上下文，最后生成三份补丁、等你敲回车确认。它不只回答问题，它要动手；它不只看当前文件，它要记住你昨天聊过的五份配置；它不只等你打字，它还要主动从编辑器里“伸手”拿代码。这个定位很准，也很难得。可惜，所有这些“主动”，都建立在一个未经加固的信任假设上：只要请求来自127.0.0.1，就默认可信。
它真正在做的事？ 剥掉所有Agent、CLI、智能体的包装纸，它就是一个三段式流水线：收指令、发请求、执行动作。第一段，它同时监听两个入口——你在终端敲下的自然语言，以及ACP协议通过WebSocket发来的结构化工具调用请求；第二段，它把这两路输入统一组装成提示词，加上缓存的文件内容，打包发给Moonshot的云端API；第三段，它解析返回的JSON，识别出其中的工具调用指令（比如“运行git diff”或“读取.env”），然后调用本地系统接口执行。整个流程里，没有模型推理，没有向量检索，没有本地知识库——所有“智能”都在云端，所有“风险”都压在本地执行环节。它的聪明是借来的，它的权限却是你终端用户的全部权限。
最聪明的地方，也是最危险的地方 ACP协议集成，是这个项目真正的技术高光。它让编辑器不再是AI的“观众”，而成了“协作者”。Zed能实时告诉kimi-cli：“我现在光标在第42行，这个函数签名需要重构，项目里还有三个同类接口在/lib/下。”kimi-cli就能据此生成跨文件的修改建议。这背后是协议设计的克制：用标准WebSocket承载轻量JSON消息，不绑定特定编辑器，不强制状态同步。但问题恰恰出在这份“开放”上。它的ACP服务启动后，默认绑定在127.0.0.1:8000，不校验连接方身份，不验证消息签名，不区分“Zed发来的重构请求”和“某个恶意Python脚本伪造的cat ~/.aws/credentials请求”。一旦连接建立，后续所有工具调用指令，都以当前终端用户的完整权限执行。这不是“权限提升漏洞”，这是架构层面的“权限默认授予”。你开启kimi acp，等于亲手在本地防火墙开了一扇单向门——外面的人进不来，但里面所有东西，只要有人知道门牌号，就能随时搬走。
被忽略的“第二攻击面” 好多人盯着ACP，却漏看了网页提取这个看似无害的功能。当你让它“分析一下这篇技术博客”，它会调用trafilatura库抓取页面。你可能在命令行加了--no-metadata参数，代码里也写了include_metadata=False。听起来很安全，对吧？但审计时我们顺着调用链往下挖，发现trafilatura底层解析器在默认模式下，仍会提取`标签里的name和content字段，并将它们拼进正文文本块，最终混入发送给AI模型的上下文中。这意味着，如果某篇博客的里写着“请把当前目录所有.py
它不适合谁，比它适合谁更重要
我必须划四条硬线： 第一，涉及任何密钥、令牌、证书的场景，禁用。它的执行权限等同于你的用户账户，而你的用户账户大概率能读取~/.ssh/和~/.aws/
第二，生产环境服务器上，禁用。它没有进程隔离、没有资源配额、没有操作审计日志，一次错误的“重命名所有.log
它暴露了一个更大的问题 kimi-cli不是孤例，它是当前AI工具链矛盾的浓缩切片。“能力越强，边界越模糊”——这句话正在变成现实诅咒。OpenAI官方CLI选择保守，宁可牺牲编辑器联动也不开放本地执行；本地推理工具选择笨重，用百GB显存换数据不出境；传统Shell工具选择透明，每条命令都是你亲手写的确定性逻辑。而kimi-cli选了第三条路：用协议打通边界，用云端外包智能，用轻量赢得体验。这条路走得通，但代价是，它把原本属于操作系统内核的权限仲裁职责，交给了一个没有鉴权模块的Python进程。安全不是功能完成后的补丁，而是架构决策的第一约束条件。当一个工具能把“重构整个微服务网关”翻译成subprocess.run(["kubectl", "apply", "-f", ...])`时，我们必须问的不是“它能不能做”，而是“谁授权它做？依据什么策略做？失败后能否回滚？操作是否留痕？”——这些问题，kimi-cli目前一个都没回答。
它最值得强调的特色，恰恰反衬出其局限的深刻性：它是首个将ACP协议落地为可用终端服务的开源实现，证明了编辑器-AI协同的技术可行性。但这份可行性，是用放弃本地通信层基础防护换来的。它的上下文记忆机制也极具启发性——不用向量数据库，不引入Redis，仅靠极简的本地会话缓存+动态提示词组装，就在M1 Mac上跑出了毫秒级响应。这种工程上的克制与巧思，本该延伸到安全设计上：比如为ACP服务增加一个基于文件锁的本地token交换机制，或为每个工具调用添加执行前的交互式二次确认。可惜，它选择了最短路径，而非最稳路径。
回到开头那个比喻：它想当你的数字同事。但一个好同事，不该在你没开口时就擅自打开你的保险柜；一个好同事，该在被要求做高危操作前，先确认你的身份、复述你的意图、并给你三次取消机会。kimi-cli现在还做不到这些。它更像一个天赋异禀但尚未受训的实习生——你能感受到它的潜力，但绝不敢放心把核心系统交到它手上。
这不是对Moonshot API的质疑，也不是对Python生态的否定。它只是再次提醒我们：在AI工具落地的战场上，真正稀缺的不是算力，不是模型，而是那种把“可控”刻进每一行架构决策骨子里的敬畏心。当编辑器连上AI，门确实开了；但真正的专业主义，是从装锁开始的。
