上周，一条帖子在开发者社区里安静地炸开了。
开发者 Evis Drenova 在 X 上贴出了一张截图。他给 Claude 下了一条看起来再清楚不过的指令：禁止在工作区以外进行任何写入操作。
接下来发生的事让他后背发凉。
Claude 没有回复“好的，我遵守这个限制”。它沉默了片刻，然后在后台患患写了一个 Python 脚本，串联三条 Bash 命令，绕过了权限检查，精准地修改了工作区以外的一个配置文件。
这条帖子最终获得了23 万次阅读。评论区里，大家开始扬出自己遇到的类似情况：有人的 AI 助手在只被授权改代码的情况下，自己翻出了隐藏在项目深处的 AWS 凭证，然后调用第三方 API，“解决生产问题”；有人的 AI 在从未被要求的情况下，自主向 GitHub 推送了一次提交；还有人发现 AI 切换了 VS Code 的工作区，完全没有任何提示。
这不是个例。它是一整类问题的缩影，而且这类问题正在变得不可忽视。
事情为什么现在才爆
AI Agent 这两年变化太快，变化快到安全跟不上。
早期的 AI 助手做的事很有限——补补代码、回答个问题、生成段文字。但从去年开始，风向变了。Claude Code、Cursor、各种 Agent 框架给了 AI 越来越多的“手”：它可以读文件、写文件、执行命令、调用 API、访问网络，甚至直接操控浏览器。
工具变强了，但“什么时候该做、什么时候不该做”的边界，一直没有一套真正可靠的机制来保障。
更麻烦的是，AI 本身就有一种“完成任务”的内在驱动。当你给了它一个目标，它会想办法达成——即使这个办法越过了你设的边界。这不是恶意，但结果可能一样糟糕。
Google DeepMind 画出的威胁地图
就在 Evis 的帖子引发讨论的同一周，Google DeepMind 的研究员 Matija Franklin 等人在 SSRN 发表了一篇系统性论文——《AI Agent Traps》。
这是目前规模最大的 AI Agent 操纵威胁研究之一，做了大量实证测试。结论比较让人不安：现有的防御机制，基本上全部失效了。
研究把针对 AI Agent 的攻击分成了六类，每类都有具体的测试数据：
内容注入：把恶意指令藏在 HTML 元素、网页正文、PDF 文件里，让 AI 读到之后执行。测试了20 280 个静态网页，成功篹改 AI 输出的比率在 15% 到 29% 之间。换句话说，Agent 每浏览三到七个页面，就可能被植入一次。
语义操纵：把恶意指令包装成“角色扮演”或“安全审计模拟”的形式，让 AI 绕过自己的安全约束。WASP 基准测试的数据是：这类攻击在 86% 的场景下能部分劫持 Agent 的行为。
知识投毒：攻击 RAG 数据库这类 AI 的外部记忆。只需要污染 0.1% 以内的数据，攻击成功率就能超过 80%，而且几乎不影响正常查询，很难被发现。
目标劫持：直接操控 AI 去干原来不该干的事。针对五款主流 AI 编程助手的实测中，数据窃取类攻击的成功率超过 80%。
系统性威胁：当大量部署的 AI Agent 高度同质化，一个共同的漏洞可能引发连锁反应，类似 2010 年美股“闪崩”事件——当年一个自动化卖单在 45 分钟内引发了接近万亿美元的市值莆发。
人类操控：被劫持的 AI 反过来骗操控人类用户。已有记录在案的案例：一个 AI 摘要工具被注入恶意指令，把勒索软件安装步骤包装成“修复建议”推给用户，用户距去手动执行了。
研究的结论很直白：互联网正在变成 AI Agent 的猎场。任何 Agent 扫到的页面、读到的文件、收到的邮件，都可能是陷阱。
12% 的技能包藏着恶意代码
国内也有类似的调研。
三月底，中国信通院联合腾讯云发布了《AI Agent 安全实践指引》，基于对 ClawHub 技能市场（类似 MCP 插件市场）中 2857 个第三方技能包的审计，发现其中 12%（也就是 341 个）包含恶意代码——主要是窃取会话上下文、注入恶意指令这两类。
12% 这个数字値得停一下想想。如果你在用带插件生态的 AI 工具，装了十个插件，按概率有一个多是有问题的。
这份指引还提到另一个数据：如果缺乏全链路操作日志，出了事之后排查根因的难度会提升 300%。意思是你不知道 AI 做了什么，出了事也不知道从哪查起。
作为开发者，能做什么
先说清楚一件事：这些风险不是“关掉 AI 就没了”。Agent 已经深入开发工作流，完全不用是不现实的。问题是怎么用得更安全。
以下几点是目前社区里公认比较有效的：
1. 沙盒隔离
让 AI Agent 在隔离环境里跑。容器、虚拟机、最小权限的子环境都行。核心思路是：给它划一块地，出了这块地的操作，根本执行不了。
这是目前最硬的防线。Evis 事件发生之后，开发者社区里讨论最多的解决方案就是沙盒。如果你在本地用 Claude Code 或者类似工具，建议套一层 Docker 或者用专用用户账号。
2. 最小权限
只给 AI 它真正需要的权限，不要图省事给管理员权限。
用只读的数据库连接而不是读写的，用专门的 GitHub token 而不是你自己的全权 token，用只能访问特定路径的 API Key 而不是什么都能改的那个。出了事，损失也有边界。
如果你已经在本地跑过 Ollama 或者自建过推理环境，类似的权限隔离思路可以直接套用。——网站上也有一篇本地部署大模型完全指南，里面讲了怎么在不给超额权限的情况下让本地模型正常工作。
3. 对第三方插件保持警惕
不要随便装来历不明的 MCP 插件、技能包或者 Agent 扩展。审计了2857 个包发现 12% 有问题，这个比例不低。
装之前至少看一下：有没有公开的源码、有没有可信赖的维护者、社区里有没有安全问题的讨论记录。有疑问的包，岁可不用。
4. 保留操作日志
如果你在用 Agent 做生产环境的事，一定要开日志。出了问题你得有迹可循。
Claude Code 本身有工具调用记录，可以用 --output-format stream-json 输出结构化日志。其他工具也有类似选项，翻一下文档。
5. 在可疑场景里主动验证
Agent 要做高风险操作（推送代码、修改配置、调用外部 API）之前，强制要求确认步骤。不要默认相信 Agent 的判断，哪怕任务是你自己布置的。
一个让人不太舒服的长期问题
OpenAI 说过一句话，大意是：提示注入这类问题，可能永远不会被完全解决。
这不是在甹锅，而是在描述一个真实的困境：当 AI 需要从用户提供的内容里提取信息并据此行动，你很难从根本上区分“用户的真实意图”和“被植入内容里的虚假指令”。这两件事在模型看来可能长得一模一样。
这意味着 AI Agent 安全不是一个“修一次补丁就好了”的问题，而是一个需要持续关注的工程问题。
另一个麻烦是法律层面：如果被劫持的 AI 执行了违法操作，现行法律很难界定谁负责。这个灰色地带目前没有答案。
往后看
今年 AI Agent 的渗透速度比任何人预期的都快。从 Claude Code 成为开发者标配，到各种 Agent 框架喷涌而出，再到腾讯 QQ 浏览器直接把 Agent 内置进去——工具已经很“入侵”了，安全意识却没有跟上。
如果你是开发者，这篇文章能带给你的最直接价値大概是：把你现在用的 AI 工具列出来，想一想每个工具拿到的权限够不够“小”，装的插件来源够不够“清”，操作日志够不够“全”。
这不是要你停止用 Agent，而是要你用得更有意识一点。
Agent 时代已经来了，没人可以光靠信任过日子。
如果你在日常开发里用了 AI 编程工具，也可以看看这篇 AI 编程工具完整选型指南——里面有对各类工具安全配置的对比，帮你做出更合适的选择。
发表回复