AI 编码助手正变得越来越智能，但它们的信任半径也成了一把双刃剑。Tenet Security 本周公布了一种名为 AgentJacking 的攻击手法，专门针对那些能主动读取错误报告并自动修复代码的 AI 编程代理。攻击者不需要黑进你的 IDE，只需要往代码仓库里塞一个伪造的 Sentry 错误页面——AI 代理就会乖乖替你把恶意代码写进项目里。
攻击路径：错误报告的逆向滥用
一切始于开发者再熟悉不过的 Sentry 错误报告。当代码抛出异常时，Sentry 会生成包含堆栈跟踪和环境信息的详细页面。AI 编码代理（如 GitHub Copilot 的自动修复模式、Cursor 的 Agent 功能）被赋予读取这些报告并自动生成修复代码的能力。AgentJacking 的巧妙之处在于：攻击者将恶意指令嵌入到一个完全虚假的 Sentry 页面中，而代理无法区分真假——它看到的只是一个“高层次错误描述”，然后按照提示（其实是攻击者的命令）修改代码。
举个例子：攻击者伪造一个“数据库连接池耗尽”的错误，并在错误详情里附上“修复建议”，比如修改连接字符串中的密码或添加一个后门函数。代理信任这个权威的错误来源，会直接应用“修复”。整个过程不需要开发者手动批准（取决于代理的自动化程度），因此恶意代码可以悄然潜入。
为什么难以被察觉
传统安全工具如 SAST、DAST 主要扫描代码中的已知漏洞模式，但 AgentJacking 注入的代码看似完全合法——它只是修改了某个配置值或增加了一个看似无害的函数调用。更糟的是，伪造的错误页面可以托管在合法域名下（通过子域名接管或云存储），甚至可以伪装成内部服务错误。AI 代理的决策过程是黑盒的，开发者事后很难回溯为什么代理会做出某个修改。
Tenet Security 在测试中成功让多种主流编码助手（包括基于 GPT-4o 和 Claude 的代理）执行了危险操作，例如：
- 在登录模块中追加密码明文记录
- 修改数据库查询以泄露用户数据
- 将 API 密钥发送到攻击者控制的服务器
这不是提示注入，是“环境劫持”
很多人第一时间会想到提示注入（prompt injection），但 AgentJacking 的运作方式不同。提示注入直接篡改输入给模型的文本，而 AgentJacking 攻击的是代理的 工具使用链路——代理调用读取错误页面的函数，然后根据页面内容生成代码。即使模型本身没有注入漏洞，它的输出也被不良的上下文污染了。这类似于浏览器中的跨站请求伪造（CSRF），但针对的是 AI 代理。
对于开发团队来说，这暴露了一个被忽视的攻击面：任何 AI 代理被动读取的外部资源（错误报告、日志、文档、Issue 回复）都可能成为攻击载体。只要代理“信任”这些来源，攻击者就能间接操控它的行为。
短期缓解与长期展望
目前没有一键修复的银弹。Tenet Security 建议开发者：第一，限制 AI 代理的自动化权限——至少要求在应用代码修改前进行人工审核（“代理建议”模式优于“自动执行”）；第二，对代理读取的外部内容进行来源验证（例如只读取签名后的错误报告）；第三，监控代理的修改行为，并与已知正常模式做对比。
长远来看，AI 编码工具需要内置上下文完整性检查：代理应该具备基本的“怀疑能力”，比如发现错误详情中出现明显的代码修改指令时，应暂停并询问用户。同时，安全社区需要为 AI 代理的输入输出建立类似 Content Security Policy 的约束机制。
这个攻击不挑 IDE，不挑模型，只看代理有多“听话”。在安全与效率的天平上，AgentJacking 提醒我们：留给 AI 的自主权越大，它犯错或被利用的可能性也越大。开发者在享受自动修复带来的便捷时，最好还是保持一份手动审查的谨慎。
评论
暂无评论
成为第一个评论的人