当智能体写代码时，谁该拿到部署权限？
Tessl 博客提出，智能体可以写代码、提修复建议，但不应拥有部署到生产的权限，部署权限应交给 CI/CD 流水线。文章引用 Cline 仓库的案例：恶意 issue 标题可诱导其分诊智能体从攻击者 fork 安装包，并借共享构建缓存窃取 npm token 发布未授权版本。作者主张把智能体读到的一切视为不可信，用 OIDC 短期身份、哈希锁定依赖和独立校验器替代人工代码审查。
的审查，以及那些跳过审查、后来出问题的变更。你希望审查更少，变更失败率下降。 把智能体读到的一切都视为不可信 想象一个智能体，它读取问题单、日志、工单和评论，然后据此行动。其中每一项都是潜在的攻击面。考虑一份错误报告，里面埋藏着添加一个依赖并提交它的指令。人可能会一眼扫过，而智能体会执行该指令。这不是理论。2026年初， 一名研究人员展示 ，Cline 的 GitHub 仓库中一个恶意的问题标题可以使其分诊智能体从攻击者的 fork 安装一个包。该智能体没有发布密钥。它也不需要。它可以污染与夜间发布任务共享的构建缓存，而该任务的发布令牌同样适用于生产发布。据该研究人员称，另一名行为者随后利用同一路径窃取了 Cline 的 npm 令牌，并在2月发布了一个未授权版本。解决方案是把智能体读到的一切都视为不可信。确保智能体接触的任何东西都不会通向值得窃取的东西：没有密钥，没有令牌，不与任何能够发布的东西共享状态。 Cline 也移除了分诊智能体，但结构性修复是从每个会发布的流程中移除缓存。攻击发生后，它把 npm 发布迁移到 OIDC，不再有可被窃取的长期令牌。 流水线必须赢得密钥 Clin
匹配字段正文
