数据线索来自 AI HOT；事实核验以 Noma Labs、Ars Technica、zkSecurity、Anthropic、OpenAI 等原始来源为准。

一句话结论

AI 代理安全正在跨过一个分界线：过去大家担心的是“模型会不会回答危险问题”，现在真正危险的是模型在一个被污染的工作环境里，带着真实权限替人做事。

这会把安全边界从传统的账号、API key 和网络隔离，推向一个更难管理的新层面：上下文是否可信，工具调用是否可控，外部输入是否能变成指令，代理执行结果是否可审计。

最近几条新闻看似分散，其实都在讲同一件事：AI 代理越像员工，安全系统就越不能只把它当聊天框。

这不是“提示词越狱”的老问题

过去讨论 AI 安全时，主角通常是提示词越狱：用户诱导模型绕过规则，让它输出不该输出的内容。

但智能体不一样。它不是只输出文字，而是会读取仓库、搜索网页、调用工具、创建 issue、写文件、提交代码、访问内部系统。攻击者不一定要让模型“变坏”，只需要让它在正确权限下执行错误任务。

这就是 GitLost 最值得警惕的地方。

Noma Labs 披露的 GitLost 漏洞里，攻击者不需要拿到目标组织的凭据，也不需要入侵私有仓库。只要在同一组织下的公共仓库创建一个带恶意指令的 issue，就可能诱导 GitHub 的 AI 代理读取并泄露私有仓库内容。攻击的核心不是传统意义上的远程代码执行，而是把“公共 issue”伪装成代理应该遵循的工作上下文。

这说明 AI 代理的攻击面有一个新特点：输入不再只是数据，输入可能被模型误认为任务指令。

传统系统里，issue 内容通常只是数据库里的文本；到了智能体工作流里，它可能变成代理计划的一部分。安全边界因此从“谁能访问仓库”扩展到“哪些文本可以影响代理行为”。

上下文污染会成为 Agent 时代的 SQL 注入

SQL 注入的本质，是程序把用户输入当成了可执行语句。提示词注入的本质类似：代理把不可信输入当成了更高优先级的指令。

差别在于，SQL 注入通常发生在清晰的输入框、参数和数据库之间；AI 代理的上下文污染更隐蔽。恶意指令可以藏在 issue、网页、README、邮件、日志、文档、评论、依赖包说明、甚至模型自己生成的中间笔记里。

HalluSquatting 进一步放大了这个问题。Ars Technica 报道的研究指出，攻击者可以利用 AI 工具在资源标识符、依赖名、命令或包名上的幻觉，诱导代理访问攻击者控制的资源，并把多个流行 AI 工具串成更大规模的攻击链。这里的关键不只是“模型会编错名字”，而是代理会把编出来的名字拿去执行。

一旦代理有安装依赖、下载脚本、调用网络资源或运行命令的权限，幻觉就不再只是答案质量问题，而会变成供应链入口。

这也是为什么“让模型更聪明”不能单独解决安全问题。更聪明的模型仍然会面对不可信输入、过宽权限和复杂工具链。真正需要的是让系统默认假设：外部上下文可能有毒，模型输出也不能直接获得执行权。

AI 也在成为防御者，但它需要被审计

值得注意的是，最近的安全新闻并不全是坏消息。

zkSecurity 披露的案例显示，AI 审计代理 zkao 持续扫描 Cloudflare 的 CIRCL 密码学库，发现并确认了 7 个真实漏洞。其中包括阈值 RSA 中的 float64 精度问题，以及属性基加密访问控制失效等高风险问题。文章强调，AI 生成的候选发现仍需要人工验证，但代理已经能够自动完成大量验证工作。

这说明同一类能力可以同时服务进攻和防御。

如果代理能读代码、构造测试、运行验证、追踪漏洞，它当然也能帮助防守方扩大审计覆盖面。对开源项目和企业安全团队来说，AI 审计代理的价值很现实：它可以持续运行，不知疲倦地检查边界条件，并把人类专家的注意力集中到更高价值的确认和修复环节。

但这里也有一个反直觉的结论：越是用于安全的 AI 代理，越需要被安全地运行。

一个审计代理通常需要读取大量代码、运行测试、访问依赖、生成漏洞假设，有时还会触碰敏感实现细节。如果它的工具权限、网络出口、日志存储和报告渠道没有隔离，本来用于防御的系统也可能变成数据泄露通道。

所以，AI 安全不会简单分成“坏代理”和“好代理”。真正的问题是：代理处在什么权限环境里，它能接触什么数据，它的输出如何进入下一步流程。

模型公司开始把“能力”做成可拆卸对象

Anthropic 和 AE Studio 提出的 GRAM 方法，提供了另一个方向：把双重用途知识路由到可移除模块里。

按照 Anthropic 的介绍，GRAM 会在 Transformer 每层加入可移除的辅助模块，让模型在训练时把病毒学、网络安全、核物理、专业编程语言等双重用途知识更多路由到对应模块，而不是扩散到全局参数。部署时，如果不希望模型具备某类高风险能力，可以移除模块；如果是在可信场景里，可以保留。

这还不是万能答案，但它代表了一个重要变化：模型安全不再只靠“提示词政策”和“拒答训练”，而是在尝试把能力本身结构化、模块化、可治理化。

过去的安全对齐更像是在模型出口处加一道门：用户问了什么，模型能不能回答。GRAM 这类方法更像是在模型内部和部署配置上做能力分区：某些知识能否被调用、在什么场景下被调用、是否可以从部署版本里拆掉。

这和智能体系统面临的问题是同构的。Agent 也需要把能力拆开：读权限、写权限、执行权限、网络权限、凭据权限、跨仓库权限、外部发布权限，都不应该被打包成一个“允许代理工作”的总开关。

国家安全和企业部署会推动同一套治理语言

OpenAI 最近发布政府与国家安全合作伙伴原则，强调 AI 可以用于网络防御、关键基础设施保护、公共服务和生物安全等场景，同时明确需要民主问责、人类判断、法治边界，并排除大规模国内监控、自主武器系统和高风险自动化决策等用途。

这类声明通常会被看作政策新闻，但它对企业同样有启发。

政府场景只是把问题放大了：AI 系统接触更敏感的数据、更强的工具、更高风险的决策链。企业内部的代码代理、客服代理、财务代理、法务代理，本质上也在面对同一种问题，只是规模和后果不同。

当 AI 代理进入真实组织，治理语言会越来越接近安全工程而不是产品体验：

  • 哪些任务必须有人类确认？
  • 哪些工具只能在沙箱里运行？
  • 哪些数据可以进入模型上下文？
  • 哪些输出可以直接影响外部系统？
  • 哪些行为必须留下审计日志？
  • 哪些权限需要按任务临时授予、用完即收回？

这些问题不会因为模型升级而消失。相反，模型越强，组织越愿意把真实权限交给它，治理要求就越高。

我的判断：Agent 安全的核心不是“禁止”，而是分层

如果把 AI 代理一律锁死，它就无法创造价值；如果给它完整权限，它又会把所有上下文污染、幻觉和工具链风险放大成真实事故。

可行路径一定是分层。

第一层：上下文分级

系统必须区分哪些内容是用户指令，哪些是外部材料，哪些是历史记录，哪些是工具返回值，哪些是不可信网页或 issue 评论。模型可以读取不可信内容，但不应该把它们当成同等级命令。

这需要产品在上下文结构上做显式标注，而不是把所有文本拼在一起交给模型。

第二层：工具权限最小化

代理不应该默认拥有完整工作区和网络权限。读文件、写文件、运行命令、访问互联网、读取密钥、提交 PR、发布内容，应当是不同权限。

更重要的是，权限应该与任务绑定，而不是与代理身份永久绑定。完成任务后权限自动回收，才符合最小权限原则。

第三层：执行前验证

模型提出的操作计划不能天然可信。安装依赖、运行远程脚本、修改配置、删除文件、发布内容、访问私有仓库等动作，应该在执行前经过规则、沙箱或人工确认。

这里的重点不是“每一步都问人”，而是把高风险动作识别出来。

第四层：输出可追溯

代理做了什么、读了什么、调用了哪些工具、根据哪些输入做决策，必须可回放。否则出了问题后，团队只能看到最终结果，看不到事故路径。

这也是 AI 审计代理能否进入企业的关键：企业不仅要结果，还要证据链。

对团队的现实建议

如果一个团队现在已经在用编码代理、研究代理或内部办公代理，我建议优先做五件事。

第一，把“外部输入不可信”写进默认规则。issue、网页、邮件、Slack 消息、客户文档都不应该直接成为高优先级指令。

第二，把代理账号和人类账号分开。不要让代理继承员工的完整权限，更不要共享个人长期凭据。

第三，把工具按风险分级。只读检索、写文件、运行测试、访问网络、发布到外部系统，是完全不同的安全等级。

第四，为代理建立默认沙箱。尤其是安装依赖、运行命令、处理未知仓库和访问网页时，沙箱应该是默认而不是例外。

第五，要求重要任务留下验证证据。测试输出、diff、日志、引用来源、执行命令和人工确认记录，都应该成为交付物的一部分。

这些做法听起来不像“AI 产品功能”，但它们会决定组织是否敢把更复杂的工作交给代理。

最后

AI 代理的安全问题，不是模型安全团队可以单独解决的，也不是提示词工程能彻底解决的。

它更像是软件工程、权限管理、供应链安全、产品设计和组织流程的交叉问题。

GitLost 告诉我们，公共上下文可以变成攻击入口；HalluSquatting 告诉我们，模型幻觉可以变成供应链入口；AI 审计代理告诉我们，同样的能力也能用于防御；GRAM 和政府安全原则告诉我们，高风险能力正在被重新设计成可治理对象。

下一阶段的 AI 竞争，不会只看谁的模型更会思考，也会看谁能把代理放进真实组织里，并且让它在复杂、污染、带权限的环境中仍然可控。

真正的安全边界，正在从“模型能不能说”转向“代理能不能做”。

主要来源

深度分析 · 作者：钟懿 · 2026 年 7 月 9 日