2026年8月30日——安全公司Mindgard披露了亚马逊AI编程IDE Kiro中的一个提示注入漏洞：攻击者控制的代码仓库内容可以操纵Kiro，读取开发者本地的敏感信息并将其外传。该漏洞没有CVE编号，已在Kiro IDE 0.7.45（Windows版）上得到确认，当前最新版本为1.0.337。利用难度被评为"低"，整个过程只需要开发者执行两次操作：通过菜单打开一个恶意项目，然后批准一次看似正常的智能体行为。 ## 攻击原理：项目文件变成了指令 Kiro是亚马逊推出的智能体式开发环境，其核心工作模式是：开发者提出意图，AI智能体读取项目上下文、调用工具、执行操作。这个模式的隐含假设是"项目内容是数据"——但Mindgard的发现证明，对大模型而言，读到的每一段文本都同时是潜在的指令。 攻击者的剧本很简单：在恶意项目的文件中埋入隐藏指令（比如注释、配置文件或文档中的提示词），当开发者用Kiro打开该项目并让智能体开始工作时，这些指令与开发者的合法请求一起进入模型上下文。模型无法可靠区分"用户的真实意图"与"文件里植入的伪指令"，于是后者被当作任务执行——读取本地敏感文件、访问环境变量、然后把内容发送到攻击者控制的地址。 外传通道用的是Kiro自身的"Kiro Powers"能力——本应帮开发者完成任务的合法工具调用，被劫持为数据走私的管道。整个过程不会触发任何可疑的确认弹窗，因为从Kiro的视角看，智能体做的每一步都在"批准"流程之内。 ## 智能体IDE的信任边界困境 这不是Kiro独有的问题，而是所有智能体开发工具共同的结构性困境。传统IDE里，项目文件打开就是文本，不会执行任何东西；智能体IDE里，项目文件是模型的输入，而模型连接着文件系统、终端与网络。 OWASP的LLM应用十大风险清单里，提示注入长期位居榜首。亚马逊自己的安全博客也承认："来自外部各方的文本可以重定向智能体去泄露机密、打开未授权的PR或未经用户同意调用工具。任何读取外部内容的智能体都暴露于此风险之下，无论是否使用MCP——连接工具只是扩大了影响范围。" 今年早些时候，另一家安全公司还披露过Kiro的更严重问题：通过网页中植入的隐藏指令，攻击者可以让Kiro重写自己的MCP服务器配置文件，在开发者机器上获得任意代码执行——同样不触发任何可疑的审批提示。两次发现指向同一个根源：当AI有权修改自己的配置与工具集时，"用户批准"这道安全边界可以被间接注入绕过。 ## 与供应链攻击的叠加风险 这一漏洞的现实威胁要与当下猖獗的开源供应链攻击叠加看待。攻击者不需要钓鱼邮件或恶意网站——只需要把带毒的项目发布到代码托管平台，等开发者克隆。一个README里的隐藏指令、一个配置文件中的注释，在传统审查里毫不起眼，在智能体IDE里却是一枚待触发的地雷。 对开发者个人，泄露的是SSH密钥、云凭证、环境变量；对CI环境，泄露的可能是整条构建管道的令牌。此前TanStack供应链蠕虫已经证明攻击者在积极瞄准开发者工具链——提示注入给了他们一条不依赖恶意代码的新路径。 ## 防御建议 1. 升级Kiro至最新版本，并关注厂商对智能体安全边界的改进公告； 2. 智能体IDE中打开不信任来源的项目前，先做静态审查——重点看README、配置文件、文档中任何"指令式"措辞； 3. 为智能体操作配置最小权限：沙箱化运行环境、限制文件系统访问范围、网络出口白名单； 4. 敏感凭证不要放在项目目录与环境变量默认加载路径中——智能体能读到的，注入者也能借道读走； 5. 团队层面建立"AI辅助开发的安全基线"：哪些项目可以让智能体自由操作、哪些必须人工逐步审批，应当成为明确策略而非个人习惯。 当开发工具开始"理解"项目内容，项目内容也就开始"指挥"开发工具。智能体IDE提升的每一分效率，都在悄悄重新分配开发者与攻击者之间的信息优势——这场再分配的规则说明书，至今还没写完。