一句话：风险往往不在模型故意作恶，而在系统默认信任了它写下的东西和碰过的东西
两则近期披露的安全观察，把智能体一类很容易被忽略的「非主动」风险摆到了台前。其一，安全研究者发现，AI 编码助手会生成并不存在的依赖包名，攻击者只要抢先注册同名恶意包，就能在开发者或智能体自动安装时完成投毒；其二，一份来自 Glow 的报告指出，智能体在 GitHub 上泄露了超过 1.3 万张企业内部图像。两者看似无关，内核却一致：模型既不清楚自己写了什么，也不清楚自己碰了什么，而系统默认照单全收。
幻觉包名：一行 import 背后的供应链缺口
这一类风险的机制并不复杂，却足够阴险。编码助手在补全或生成代码时，可能写出一个它「以为」存在、实际并不存在的依赖包名。如果开发者不假思索地安装，或者更糟，让智能体自动执行安装脚本，攻击者只要在公共源上抢先注册同名包、塞入恶意代码，一次供应链投毒就完成了。它和传统的 typo 抢注（拼写相似域名或包名）是同一类威胁，但更隐蔽：typo 抢注还能靠黑名单和人工核对发现，而模型即兴编造的包名，没有人预先知道它「应该」长什么样，反而更容易从审查的缝隙里滑过去。
智能体让攻击更顺：从生成到中毒一气呵成
当这枚隐患遇上自主编码智能体，链条被进一步压短。一个被赋予执行权限的 agent，可能自己读包、写构建脚本、跑安装、再把结果外发，全程无需人在回路里逐项确认。传统供应链攻击至少要等开发者手动踩雷，而 agent 的工作流天然包含「生成依赖加自动安装」这一步，等于把攻击面从「人可能犯错」扩展到了「系统默认照做」。这也是为什么这一类问题越来越被安全社区当作智能体特有风险来研究，而不是普通软件工程的旧账。
Glow 报告：1.3 万张内部图是怎么流到公网的
第二类风险来自一份厂商报告。Glow 指出，智能体在 GitHub 上泄露了超过 1.3 万张企业内部图像。它的形态和幻觉包名互为镜像：前者是 agent 把内部资源当成公开资产提交出去，后者是 agent 把外部恶意资源当成可信依赖拉进来。两者都不需要模型「心怀恶意」——它只是在执行一个看起来无害的步骤，却因为没有对「这一步会碰到什么、会写到哪里」做审视，把内部边界悄悄抹掉了。对一个把截图、设计稿、内部快照都交给智能体处理的团队，这类泄露的代价不是答错一句，而是把本该留在墙内的东西直接摆到了公网上。
两类风险的共性：安全要从「它说什么」扩展到「它做了什么」
把两则观察并排看，会发现它们共享同一个病灶：传统安全把太多注意力放在「模型生成了什么文字」上，却很少问「模型执行的动作碰了什么」。幻觉包名是 agent 拉进了本不该出现的外部代码，内部图泄露是 agent 把本不该出去的内部资产送了出去。治理这一类风险，靠给提示词加几句话、或给输出做文本过滤，都打不到点上——因为问题不在语言，而在动作与权限。换句话说，智能体安全的审查对象，必须从一段对话，扩展到一段会读写真实系统的执行轨迹。
企业侧能先落地的几件事
对正在把编码智能体接进工作流的团队，有几条相对低成本的防线值得先做。依赖层面，锁定版本、走私有源或受信镜像，禁止 agent 从无鉴权的公网源自动拉包；权限层面，给 agent 最小可读可写范围，尤其是密钥、凭据与内部存储要隔离；提交层面，在 push 之前加一道扫描，识别并拦截疑似内部资产外流；网络层面，不让 agent 直连公网执行安装与外发。这些动作不依赖某个新框架，而是把「动作前审查」与「边界」重新放回系统里。
边界：数据来自研究者与厂商报告，规模因环境而异
也要把话说回来。幻觉包名与内部图泄露，目前更多来自研究者演示与厂商报告，具体规模与行业分布会因企业环境差异很大，不能简单外推到你的系统；Glow 报告里被点名的 1.3 万张图，具体构成与影响范围仍需进一步核验。关于智能体在更复杂业务、跨更长链路下的投毒与泄露概率，官方及行业暂未披露更多细节。把它们当作风险清单而非定论，更稳妥。
结语
智能体带来的安全课题，正从「它会不会说错话」滑向「它会不会做错事、碰错东西」。幻觉包名让外部恶意顺着自动安装溜进来，内部图泄露让内部资产顺着自动提交溜出去——两扇门，开在同一面墙上。真正该补的，不是更聪明的过滤器，而是让 agent 的每一步动作，都被当作可能越界的行为来审视。