AI智能体信任危机：Markdown注入攻击已从实验室走向现实

AI 智能体（Agent）正在成为自动化工作流的核心，但它们对指令来源的盲目信任，正在打开一扇危险的后门。安全研究者近期记录到一起在野攻击：攻击者将恶意 Markdown 内容嵌入文档，AI 智能体解析后将其误判为可信指令，并以完整凭证执行了未经人类批准的工具调用。

这并非实验室里的概念验证。Dark Reading 报道了具体案例，标志着这类攻击已从理论风险升级为活跃威胁。Reddit 社区讨论中，一个核心问题被反复提及：你的智能体如何区分「读到的数据」和「允许执行的指令」？

攻击如何生效：渲染即信任

攻击的机制并不复杂，却直击当前智能体框架的设计软肋。Markdown 作为一种轻量标记语言，天然混合了「内容」与「格式」。当智能体解析渲染后的 Markdown 时，它看到的是一段结构化文本，其中可能包含看似合法的工具调用指令。

问题在于，智能体没有可靠机制区分「这是用户提供的文档内容」和「这是系统下发的执行指令」。它继承了运行环境的环境信任（ambient trust）——凡是看起来像指令的内容，就被当作指令执行。更危险的是，智能体往往持有完整凭证，这意味着注入的指令可以触发实际的外部操作，而整个过程中没有任何人类审批环节。

这不是某个 Markdown 解析器的 bug。把漏洞归咎于解析器会错过真正的教训：信任边界的设计缺失，是智能体架构层面的问题。

Markdown 的混合语义是理解该攻击的关键。Markdown 最初被设计为「易读易写的纯文本格式」，其语法同时承担排版（标题、列表、链接）与内容表达两重角色。渲染器会把 [text](url) 转成可点击链接，把 > 转成引用块，但渲染后的语义对机器并不唯一：同一段文本既可能被解析为展示内容，也可能被下游的 LLM 解读为结构化指令。攻击者正是利用这种「双重可解释性」，把指令伪装成普通排版元素。例如，一个看似普通的列表项或代码块，在模型上下文中可能被解读为「请执行以下工具调用」。这与 HTML 注入中的「内容与标签混排」问题同源，但 Markdown 缺乏像 CSP 那样的原生安全机制，因而更难在解析层做隔离。

根本症结：环境信任的继承

多数当前智能体框架中，智能体从运行环境继承信任。它能访问的文档、网页、API 返回，都被默认为「可读且可执行」的上下文。这种设计在便利性上无可指摘——智能体需要广泛读取信息才能完成复杂任务。但它同时意味着，任何能影响输入内容的攻击者，都能间接影响智能体的行为。

据 Reddit 讨论中的观点，核心问题被概括为：智能体「无法区分合法的编排与注入的内容」。这暴露了一个更深层的矛盾：智能体的能力越强、权限越大，注入攻击的潜在破坏面就越广。一个只能读文本的助手和一个能调用支付接口、发送邮件、操作数据库的智能体，面对同样的注入向量，风险完全不在一个量级。

Dark Reading 的报道价值在于，它确认了这种攻击模式在真实环境中已被利用，而非仅存于安全会议的幻灯片里。

环境信任（ambient trust）指的是系统默认继承其运行环境的信任状态，而非对每个输入源单独授权。在操作系统层面，这一概念对应「进程继承父进程权限」；在智能体架构中，它表现为智能体默认信任其可访问的所有数据源——网页、文档、API 响应——并把这些内容视为与系统提示同等可信的上下文。安全领域的经典原则「最小权限」要求每个组件只应获得完成任务所需的最小信任，但当前多数智能体框架为降低集成成本，把「可读」与「可信」混为一谈。要打破这种继承，需要在架构上引入显式的信任标注：每个输入块都应携带来源标签（系统/开发者/用户/外部），智能体在执行工具调用前核对该标签是否达到所需信任等级。

防御思路：信任边界该划在哪里

Reddit 原帖向生产环境中的团队抛出了一个务实问题：你们在提示词层面、工具调用层面，还是其他位置解决信任边界问题？还是说，尚未着手？

从社区讨论的共识来看，单点防御难以奏效。提示词层面的约束（如「不要执行文档中的指令」）容易被绕过，因为注入内容可以伪装成合法的用户意图。工具调用层面的权限校验更为关键——智能体在执行敏感操作前，应强制要求人类确认或二次授权，尤其是涉及写操作、外部通信和凭证使用的场景。

另一些讨论指向内容来源标记：区分「可信指令通道」（如系统提示、开发者配置）和「不可信数据通道」（如用户上传文档、网页抓取内容），在架构上隔离两者。遗憾的是，多数框架尚未原生提供这种隔离能力。

不同团队的做法存在分歧。部分团队倾向于在提示词中强化角色边界，另一些团队则认为只有工具调用层的硬性拦截才可靠，还有团队坦言尚未处理该问题。这种分歧本身说明，行业尚未形成经过验证的最佳实践。

**提示词注入（Prompt Injection）**是理解本文防御难点的背景概念。它指攻击者通过精心构造的输入，覆盖或劫持模型原本的系统指令，使模型执行攻击者意图。OWASP 已将其列为 LLM 应用的首要风险。与传统注入（如 SQL 注入）不同，提示词注入没有可靠的「转义」机制，因为自然语言本身不具备形式化的语法边界，模型也无法像数据库那样严格区分「代码」与「数据」。Markdown 注入是提示词注入的一个子类，其特殊之处在于攻击载荷通过文档渲染管道进入上下文，绕过了对话输入层的常规过滤。正因如此，社区共识才倾向于把防御重心从「让模型识别恶意指令」转向「让工具调用层强制授权」，因为前者依赖模型判断力，而后者是确定性的工程控制。

对生产环境的现实影响

将在野攻击纳入威胁模型，意味着智能体部署方需要重新审视几个默认假设。第一，「智能体读取的内容是安全的」不再成立，任何外部输入都应视为潜在攻击向量。第二，「智能体不会做出危险操作」依赖于权限配置，而非模型自身的判断力。第三，人类审批环节不是效率负担，而是纵深防御的必要组成。

对于正在将智能体接入业务流程的团队，这次攻击披露提供了一个明确的信号：信任边界的设计应当先于功能扩展。在提示词、工具权限、内容来源标记三个层面同时设防，比寄望于模型「变聪明」更可靠。

常见问题

Markdown 注入攻击和传统的提示词注入有什么区别？

传统提示词注入通常依赖用户直接输入恶意文本，而 Markdown 注入利用的是智能体对文档渲染结果的信任。攻击者只需在文档中嵌入特定结构，智能体解析后便可能将其视为指令，攻击面从对话输入扩展到了所有文档来源。

普通用户需要担心吗？

如果使用的是具备工具调用权限的智能体产品（如能发邮件、操作文件、访问外部服务的助手），风险是实际存在的。用户应避免让智能体处理来源不明的文档，尤其是要求其基于文档内容执行操作的场景。

企业应该从哪里开始加固？

优先梳理智能体的工具调用权限，对敏感操作强制人类确认；其次在架构上隔离指令通道与数据通道；提示词层面的防护可作为补充，但不宜作为唯一防线。