该被写进选型表的是修复节奏
编码 agent 出漏洞不算新闻了，本站 9 月 7 日写过 Manifold 披露的 GitSpawn，9 月 8 日写过 LiteLLM 被 CISA 列入在野利用目录。这条的价值在别处：它把同一类问题在不同厂商那里的处理速度摆在一起——约一周，对约 50 天。 这个对比之所以重要，是因为它衡量的不是某个版本有没有 bug，而是厂商的响应机制。把编码 agent 放进日常开发流程的团队，实际承担的风险不是「它有没有漏洞」（一定有），而是「报上去之后多久能修好」。而这个指标从不出现在任何功能对比表、定价页或评测榜单里。 50 天里发了约 30 个更新这个细节尤其刺眼：它说明产品迭代在正常推进，积压的不是工程资源，是优先级。
两处要标清楚的边界
第一，披露方有商业动机。Accomplish 是一家处于隐身期的安全创业公司，公开竞品生态的问题同时也在给自己建立叙事。这不削弱技术发现的有效性，但「厂商修得慢」这个结论出自一个正在做这门生意的人，读的时候该知道。 第二，Avner 关于「攻击者可能已在那段窗口里利用」的说法，目前没有公开证据支撑。按本站惯例，这属于未证实的推断，不能写成事实。真正确证的只有三件事：漏洞存在、已私下通报、修复耗时不同。
四家团队指向同一个结构问题
把同窗口的几份披露并排看，会发现它们说的是一件事。Manifold 的 GitSpawn 是仓库自带的 git 配置指定一条命令、由 agent 在后台调用时执行；Pillar Security 盯的是 agent 自己生成的文件随后被受信任的宿主软件处理，研究者明确说这是信任问题而非经典的沙箱逃逸；Cymulate 则总结为隔离、配置与「信任模型或用户可控输入」上的系统性弱点。 共同点是：这些边界都是按「模型会不会请求权限」画的，而不是按「这条链路上究竟是谁在执行」画的。所以沙箱看起来在，实际漏。 对团队可执行的几条：把编码 agent 当成一个会执行不可信输入的服务来对待——给它独立的凭据而不是你的个人凭据、按最小权限配、出网走白名单、不要在能直接访问生产凭据的机器上打开外部交付的代码库。另外把「厂商的漏洞响应时间」加进采购问题清单：有没有公开的安全联系渠道、有没有承诺的响应与修复时限。这两条比追某一个 CVE 更省事。
via: Upstarts Media 报道、Cymulate 关于配置型沙箱逃逸的研究、Cloud Security Alliance 关于编码 agent 沙箱逃逸的研究笔记