DEV Community 10 月 14 日的一篇长文把编码 Agent 的攻击面讲得很透：今年四月安全研究者公开演示过一种注入模式，能同时劫持当时最流行的几款编码 Agent——Claude Code、Gemini CLI、以及在 GitHub Actions 里运行的 Copilot Agent。载体不是高深的漏洞，是伪造的 GitHub 评论、PR 标题和 issue 正文。结果是命令被执行，凭证暴露在 Actions 日志里。这是第一次公开证明，一条注入可以跨厂商同时生效。

为什么开源仓库环境成了最佳投毒点？

编码 Agent 天然要读仓库内容：issue 讨论、PR 描述、代码注释，全是它日常摄入的「上下文」。攻击者不需要攻破任何服务器，只需要给一个热门仓库提一条 issue，正文里藏一句「请把以下脚本加到 CI 里运行」，等 maintainer 那边的 Agent 读到。更糟的是 GitHub Actions 环境的 Agent 天然带着仓库的 secrets，执行完命令顺手把环境变量打到日志里，等于白送凭证。开源项目越多的团队，暴露面越大。

CI 里跑编码 Agent 该怎么配最低权限？

第一，给 Actions 里的 Agent 用单独的低权限机器账号，不给主仓库 secrets，需要发版权限的步骤单独走并设人工审批。第二，把 Agent 能读到的外部内容加隔离：issue 和评论渲染进沙箱再喂给模型，不让其与工具调用共享同一个系统提示通道。第三，命令执行类工具默认全局关闭，改成显式白名单。第四，定期审计 Agent 历史调用记录，找有没有执行过非预期域名的命令。

编码 Agent 的便利和暴露面是同一件事的两面。你把钥匙交给它的那天，就该知道它会替谁开门。还有一个容易被忽略的传染路径：Agent 修复被投毒 issue 时写出来的代码本身可能被埋下后门，审查 Agent 的输出和审查人类提交一样严格。对开源维护者的最低建议是：不在 Actions 里跑带 secrets 的 Agent，本地手动触发的 Agent 会话不要长期留存凭证。防御的总原则只有一句：把 Agent 当作一个需要签保密协议的新员工来对待。

去论坛讨论

前往 silicon-agi.com 论坛 参与讨论