
研究:AI Agent 安全应靠隔离防护而非自我防御
来源标题:Secure AI Agents with Hazmat Suits, Not Self-Defense Classes
一项分析指出,多数企业在 AI Agent 安全上陷入两种失效模式,根源是业界对 Agent 安全缺乏理解和可用的心智模型。文章用旅行自保作比,认为现有网络安全手段类似“自卫课”,难以应对凭据链式泄露等风险,主张改用“防护服”式的隔离思路。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
↩博客 AI Agent 安全需要的是防护服,不是自卫课 Finn 2026年10月22日 星期四 · 9 分钟阅读 在保障 AI agent 安全方面,大多数组织都陷入了两种失败模式之一: 这是因为人们对 AI agent 安全的理解还很欠缺。目前还没有现成的操作指南,我们甚至缺乏一个良好的心智模型来理解如何保障 agent 安全(以及 agent 到底是什么)。 如果你计划前往一个危险的地方旅行,你可能会提前研究自己可能如何被抢劫或诈骗,参加自卫课程,购买防护服装,在口袋里塞满诱饵钱包等等。 许多网络安全基础设施都是这样运作的:我们知道存在哪些风险,并用工具和策略来缓解它们。 例如,攻击者经常通过一连串被泄露的凭证来访问敏感数据(比如一个被泄露的 GitHub 会话 token 暴露了硬编码的 AWS IAM token,进而让攻击者能够生成生产数据库凭证)。 网络安全措施直接针对这一模式进行反制: 这些就像自卫课程:它们帮助我们预防或应对攻击。但即使是穿着防弹衣、拥有柔道黑带和致命武器库的海豹突击队员,也可能死于致命的感染,因为人类无法感知这些威胁。 这正是我们在 agent 身上面临的安全挑战:要安全地运行 agent,就需要保护它们免受其无法感知的风险。 人类用防护服来解决这个问题:当一个区域被看不见的危险污染时,唯一有效的安全机制就是将身体与病毒、细菌或化学物质物理隔离。 即使是诺贝尔奖得主级的病毒学家也看不见致命的病毒,而 AI agent 也无法可靠地识别有风险的指令和操作。这不是缺陷,而是其架构的必然结果:agent 由概率性的 LLM 驱动。这使它们能够自主迭代并完成任务,但如果没有约束它们的安全基础设施,就不可能提供安全保障。 Agent 基本上就是一个 prompt 和输出的持续循环。如果你告诉 agent“把我网站的按钮颜色改成蓝色”,它可能会发起 LLM 调用、生成推理 token,并运行一条 grep 命令。Agent 的运行时执行该命令,输出成为 LLM 上下文,从而成为 prompt 的一部分。这个 prompt 又可能导致打开文件、修改 CSS 属性等命令。 如果 agent 为了完成任务而可能采取有害操作,这就变得危险了。改变网站按钮颜色这件事本身可能就存在问题。也许 agent 会通过阅读 Next.js 仓库上的一个 GitHub issue 来排查问题,而其中一条评论链接到了 agent 所安装的一个技能。表面上看,这个技能教 agent 如何使用 Next.js,但安装它的同时也会把每一个凭证发送到攻击者的 webhook。 任何人都会拒绝调用那个 webhook 的权限,但大多数 agent 都在无人监督的情况下运行。人们信任自己的 Claude Code/Codex 跳过权限检查,授予它完整的磁盘访问权限,让它读取任何凭证。毕竟,到目前为止还没出过事。只是“到目前为止”。 厂商会加固自己的产品以抵御攻击,但无法保证安全,因为攻击在不断演变,而且哪怕一次失误也可能是灾难性的。唯一安全的假设是:agent 可能且将会采取有害操作,因为其架构使得这些操作无法被排除。 行为防护措施是任何你可以教给对象的东西。如果你指示你的工程团队永远不要在 Slack 或邮件中分享 API 密钥,他们就会明白这个道理,也不会在 Asana 中发布它们,即使他们有一个理论上可以发到社交媒体上的 .env 文件。这就是自卫课程和防护服装的心智模型。 行为防护措施对 AI agent 并不可靠。你可能会在 agent 的系统 prompt 中加入“永远不要打开 .env 文件”,但 agent 可能通过运行 grep DATABASE_URL .env 来获取明文凭证,所以从技术上讲它从未打开过 .env。 Agent 需要架构层面的防护措施。这些是让有害操作不可能发生的措施。一台机器上没有任何凭证的 agent,无法找到变通办法来访问它们。这就是防护服。 架构层面的防护措施并不新鲜。它们支撑着许多传统的安全架构原则: 严格的架构防护措施会带来摩擦。最小权限原则可能会在某人缺少偶尔才需要的凭证时阻碍其工作。组织不愿承认这一点,但架构防护措施是高效运营与安全之间的权衡。 一个偏执的组织可以通过发放凌晨 12 点恢复出厂设置、每天接收一批严格必要文件的离线公司笔记本电脑来确保安全。但这会让人类的工作无法进行。 但 AI agent 不会在工作场所幸福感调查中痛骂你,而且正如我们所看到的,它们需要架构层面的防护措施,因为一个被攻陷的 AI agent 是一个极其耐心的攻击者。 这就是为什么大多数 AI agent 安全基础设施需要提供架构层面的护栏。默认技术栈尚未定型,但有几项正在形成共识。以下所有组件都能让 AI agent 在完成任务的同时提供确定性的安全保障。 沙箱是 agent 运行所在的隔离环境(VM、gVisor、容器等)。组织可以在机器层面配置安全措施。禁止 agent 读取某些文件的行为护栏容易被绕过,但沙箱不会,因为这些文件在机器上根本不存在。 组织可能会使用多种类型的沙箱。开发者的编码 agent 可能会在每次会话中启动一个相对宽松的沙箱,而客服 agent 可能会获得一个持久化的沙箱,只能通过互联网调用组织的文档 MCP。 沙箱并非新颖的 AI 技术。它们早已存在,用于隔离工作负载,但与 AI agent 天然契合。 要发挥其威力,agent 通常需要访问 API、CLI、MCP 等 HTTP 服务,而这些服务通常由凭证代理来保障安全。
(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。