作者 | Sergio De Simone

译者 | 田橙

为防止大语言模型和 AI Agent 执行嵌入在外部数据中的恶意指令，所有进入 Agent 上下文的文本在完成校验之前都必须被视为不可信数据，其中不仅包括用户输入的提示，还包括来自外部系统的各类信息。AI 安全公司 CyberArk 的首席软件架构师 Niv Rabin 表示。为此，他所在的团队提出了一种基于“指令检测”（Instruction Detection）与“历史感知校验”（History-Aware Validation）的方法，用于同时防御恶意输入数据和上下文历史投毒攻击。

Rabin 介绍说，团队设计了多种防御机制，并将其组织成一个分层的处理流水线。流水线中的每一层都针对不同类型的威胁，目的是减少单一防护手段不可避免存在的盲区。

这些防御措施包括“蜜罐动作”（honeypot actions）以及指令检测器，用于拦截具备指令特征的文本，确保模型最终接触到的仅是经过验证、且不包含指令的数据。同时，这些机制也会应用于整个上下文历史中，以防止所谓的“历史投毒”（history poisoning）。这种攻击方式指的是，原本看似无害的内容片段在多轮交互中逐步累积，最终拼接成一条完整的恶意指令。

所谓“蜜罐动作”，本质上是一种用于诱捕恶意意图的安全陷阱，即 Agent 在任何正常业务场景下都不应选择的合成动作。

这些动作对应的是一些不会真正执行任何操作的虚拟工具。它们并非用于完成实际任务，而是作为安全信号存在，其工具描述被刻意设计成能够暴露可疑行为。

在提示中出现的可疑行为包括对系统内部机制的元层级探测、异常的数据提取尝试，以及试图诱导模型泄露系统提示（system prompt）的操纵行为等。如果 LLM 在动作映射阶段选择了其中一个蜜罐动作，通常就意味着存在明显的异常或越界行为。

Rabin 指出，真正的安全风险并不主要来自用户输入，而是来自外部 API 或数据库的返回结果。针对这一问题，团队引入了指令检测器作为关键防护手段。

此外，时间也被证明是一种重要的攻击向量。早期响应中零散存在的恶意指令片段，可能会在后续交互中被重新组合，最终形成一条完整指令。这种现象被称为“历史投毒”。

示意图展示了一个典型案例：LLM 被要求分别获取三段数据，单独来看，这些数据完全无害；但合并在一起后，内容实际拼成了一条指令，要求系统停止处理并返回特定结果。

为防止历史投毒，所有历史 API 响应都会与最新获取的数据一并提交给指令检测器，作为一个统一输入进行分析。

Rabin 指出，历史投毒并不是发生在数据进入系统的入口阶段，而是发生在系统从历史记录中重建上下文的过程中。通过引入这一机制，即便对话历史中隐藏着试图干扰模型推理的细微线索，系统也能够在模型受到影响之前及时发现异常。

上述所有步骤都会在同一条流水线中运行。一旦任意一个阶段检测到风险，请求就会在模型处理之前被直接拦截；只有通过全部校验后，模型才会处理已经净化过的数据。

Rabin 总结，这种方法的关键在于将 LLM 视为一个长期运行、跨多轮交互的工作流系统，而非一次性的请求响应组件。他在原文中对这一方案进行了更为深入的展开，对于关注 AI 安全问题的读者而言，值得进一步阅读。