Agentic SQL 注入：穿越信任边界的经典攻击新衣

没人给这篇文章鼓掌。HN 上零分、零评论，然而 CVE-2026-18830 在预测未来两年 agentic AI 安全走向这件事上，比那些塞满你信息流的获得融资的创业公司噪音更有参考价值。

事情是这样的：AWS Bedrock AgentCore 存在一个漏洞，认证用户可以伪造 tool-use 内容块，这些内容块在 LLM 实际上从未授权的情况下就被执行了。LLM 本应是守门人，决定"是，调用这个工具"或"不，不调用"。结果发现你直接绕过了守门人，向 harness 递交一条看起来足够合法可以执行的伪造指令。

如果这听起来很眼熟，那就对了。这正是我们从 90 年代就开始修复的同一类 bug：系统信任了跨越信任边界的输入，却没有验证它到底来自哪里。把"SQL 查询"换成"tool-use 块"，把"数据库"换成"agent 运行时"，你得到的根因与二十年前的注入攻击完全一致。发现这个问题的研究人员将其标记为值得命名的独立模式并没有错，但我们不要假装底层机制是什么新奇的 AI 时代谜题。它就是一个信任了不该信任的 payload 的解析器。

真正有意思的不是 AWS 这个 bug 本身。而是同样的绕过模式也出现在 Google ADK 和 Vercel AI SDK 中。三个不同的厂商，三种不同的实现，同样的架构错误。这不是巧合，这是趋同进化。每个构建 agent harness 的人都在解决同一个问题（如何让 LLM 安全地触发现实世界的动作），显然他们中的很多人都在用同样不安全的方

式解决。

"agentic SQL injection" 这个表述在这里起了很大作用，我理解为什么。它是个好标签，很抓眼球，把一个可怕的新事物映射到每个开发者已经恐惧的东西上。但要谨慎使用这个类比。SQL 注入已经被充分理解，有几十年的工具链、ORM、参数化查询和静态分析器来检测它。Agent harness 绕过还没有这样的生态。称其为"SQL 注入"让它听起来像是已经接近解决的问题。事实上并没有。它更像是 1998 年的 SQL 注入状态，刚好是人们意识到这是一个类别而不是个别 bug 的时候。

被低估的事实：这个模式在三个主要框架中被发现，HN 上基本上没有关注，这应该比一个花哨的、有好听名字的零日更让你担忧。一个真正系统性的发现在社区中参与度低，通常意味着两种情况：要么严重性还没被充分认识到，要么应该关心的人不是读它的人。这两种情况在这里都成立。当下在生产环境中运行基于 agent 的自动化管道的人，大多数不是在小众安全渠道读漏洞披露的人。

把

这称为一个"漏洞类"而不是三个孤立 bug，谁从中受益？说实话，这一次每个人从准确的表述中都受益。它不是为炒作而炒作。如果一个研究团队能够指出独立实现中可重复的模式，这是有用的弹药，可以让工程组织真正优先处理修复，而不是把它当作一次性的补丁然后遗忘。

如果你在构建或部署 agent 运行时，教训不是"修补 AgentCore"。而是"审计模型决策和 harness 执行之间的信任边界"。问一个直白的问题：认证但非特权的用户能否构造一个看起来像合法工具调用的 payload，并在模型实际没有选择调用该工具的情况下使其被执行？如果你不知道答案，你就不知道自己是否易受攻击。

这还有一个令人不安的治理含义。许多 agent 安全模型假设 LLM 是控制点。这个 bug 类表明这个假设是承载性的，而且在至少三个实现中，实际上在 harness 层面并没有被强制执行。这是一个设计审查问题，而不是代码审查问题。你无法通过 grep 来解决它。

我们花了二十年构建工具和制度性的肌肉记忆来捕获传统软件中的注入 bug。Agent 运行时作为主流模式大概只有三年历史。我们是否能够足够快地建立同样的肌肉记忆，然后再让 agent 系统连接到具有现实世界影响的事物上，还是我们要一个 CVE 一个 CVE 地重学每一个注入教训？