夜雨聆风我发现自己陷入了一个细思极恐的场景。
昨天下午，我像往常一样让 Claude Code 帮我修一个 Sentry 报错。它花了大概 30 秒分析报错栈，然后开始改代码。我瞟了一眼改动，看起来挺合理——修复了一个空指针判断，还加了个兜底逻辑。我点了确认，继续忙别的事。
但如果——我说如果——那个 Sentry 报错根本就是伪造的呢？
这不是我的被害妄想。这是 2026 年 7 月中旬，全球安全研究界炸锅的一个真实漏洞。它有一个名字，叫 Agentjacking。
一、一个伪造的报错，就能接管你的机器
VentureBeat 和 The Hacker News 在 7 月 12 日同时报道了一项安全研究成果：攻击者可以通过伪造 Sentry 错误报告，诱导 Claude Code、Cursor 等 AI 编程工具执行恶意代码。
原理简单到你不敢相信。攻击者向某组织的 Sentry 事件流中注入一条伪造的报错，报错信息里藏了一段"修复建议"。AI 编程 Agent 读取到这条报错——因为它的工作机制就是读取报错、理解、修复——然后信任了报错中的修复建议，执行了攻击者想让 Agent 执行的代码。
85% 的测试成功率。2388 家暴露组织。其中包含财富 100 强公司。
在我的知识库里，[[wiki/concepts/AI智能体开发|AI 智能体开发]] 笔记里记录的核心关注点之一就是「Agent 自主执行能力进化」——从 GLM-5.2 自主录屏剪辑，到 OpenMontage 让 AI 组织视频生产流程，Agent 正在变得越来越自主。但自主意味着什么？意味着它不再等你的指令，它能自己决定"下一步做什么"。
这个能力在好的方向上叫自动化，在坏的方向上叫——攻击面。
二、为什么传统安全工具拦不住
我一开始的想法是：这东西防火墙应该能拦吧？IAM 策略总能管住吧？
答案是否定的。
Agentjacking 的恐怖之处在于：整个攻击链路里的每一个步骤，在传统安全视角下都是合法的。 Agent 读取 Sentry 报错——合法。Agent 读取网上的一段"修复参考"——合法。Agent 修改本地代码文件——你看，它本来就是干这个的。然后代码被执行——同样，AI 编程工具的基本职责就是帮你改代码跑代码。
我在 [[wiki/concepts/AgentSkills|Agent Skills]] 的笔记里写过一句话："Agent Skills 是教 LLM Agents 用工具的说明书。" 现在的问题是，攻击者也学会了写说明书。他们伪造了一个"修复报错"的场景说明，Agent 信了，照着执行了。而 IAM、EDR、网络控制全部放行——因为这些工具本来就不检测"Agent 是不是在做好事"。
我自己用 Claude Code 和 WorkBuddy（它也是 Agent 模式在工作）快半年了。说实话，我从没怀疑过工具发给我的代码改动建议。信任是效率的基础——如果每行代码我都要审查再审查，那要 Agent 干什么？
但 Agentjacking 让我意识到：信任太深的地方，就是漏洞藏得最深的地方。
三、不只是 Sentry——整个 Agent 生态的系统性风险
这不是 Sentry 的锅。研究报告很明确地指出：Datadog、PagerDuty、Jira 等协作工具都存在相同的攻击面。
你会发现一个规律：Agent 要真正有用，就必须能接入你的工具链。 它要读 Sentry 的报错才能帮你修 Bug，要搜 Jira 的工单才知道你在做什么，要看 Datadog 的仪表盘才能分析性能问题。
但每一次接入，都意味着放进来一个攻击向量。AI 编程 Agent 从协作工具中读取的信息，本质上已经变成了可执行的指令流——而不仅仅是人类阅读的信息流。
这就引出了一个更底层的问题：Agent 时代的安全范式，还没建立起来。
我建立 OPCKG（一人公司知识库）的时候就反复遇到一个问题：自动化程度越高，安全边界越模糊。我做了 10 个小应用，从珠宝内容工作台到金融早报，每个都在帮我省时间，但每个都在某种程度上替我做了"信任决策"。Agentjacking 告诉我，我正在做的不是杞人忧天。
四、一人公司和个人开发者怎么办
好消息是：你不是财富 100 强，攻击者大概率不会为了你一个人花精力伪造 Sentry 报错链。坏消息是：你最大的资产是你的开发环境和凭据，而这些在自动化流程里暴露得越来越多。
我从这件事里总结了几条自己能做的安全实践，分享出来：
1. 限制 Agent 的执行范围。 别让 Agent 拥有完整的环境权限。WorkBuddy 的沙箱机制、Claude Code 的 --allow 白名单目录，这些都是能用的。我以前嫌麻烦全关了，现在重新开了。
2. 审计可疑的"修复建议"。 如果你的 AI 编程工具突然要改一个你不熟悉的配置文件，或者要安装新依赖——停一下，看清楚它要干什么。不是说不能信任，而是信任应该是一个默认怀疑、验证后确认的过程，而不是反过来。
3. 主开发环境不要放生产凭据。 这条本来就应该做，但一人公司最容易犯的错就是"反正就我一个人，都放一起省事"。我的建议是至少把生产环境的凭据隔离到一个单独的目录或环境中，Agent 默认访问不了。
4. 关注 Agent 安全工具的进展。 这次事件之后，我判断会出现两种情况：一是 AI 编程工具厂商会推出安全审计模式（比如对"读取 → 执行"链路做签名验证），二是会出现 Agent 安全第三方方案（可信执行环境、Agent 行为审计日志）。我保持关注，如果发现好工具会分享出来。
五、Agent 时代的安全，不能只信"它不会干坏事"
我在 Vault 复利那篇笔记里提到过一个观点：自动化不是一劳永逸的，它是一种需要持续维护的能力。 安全也是一样。
AI 编程工具在帮我们省时间的同时，也在替我们做越来越多的信任决策。Agentjacking 不是最后一个针对 Agent 生态的攻击方式，它只是第一课。
作为一人公司，我的选择不是回到纯手工模式——那是因噎废食。我的选择是更清醒地信任：我知道我的 Agent 助手现在也能被钓鱼，所以我多看一眼它的"修复建议"。不复杂，但关键。
你怎么看？你平时会审查 AI 编程助手给你写的每行代码，还是看完标题直接点确认？