🤖 AI

A Framework for Formalizing LLM Agent Security

本文提出了一种基于上下文安全视角的 LLM 智能体安全框架，通过定义任务对齐、动作对齐、源授权和数据隔离四项安全属性及相应的验证机制，系统性地重新形式化了现有攻击与防御方法，以解决传统定义中因忽视上下文而导致的效用与安全权衡难题。

原作者： Vincent Siu, Jingxuan He, Kyle Montgomery, Zhun Wang, Neil Gong, Chenguang Wang, Dawn Song

发布于 2026-03-23

📖 1 分钟阅读☕ 轻松阅读

原作者： Vincent Siu, Jingxuan He, Kyle Montgomery, Zhun Wang, Neil Gong, Chenguang Wang, Dawn Song

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文就像是为**AI 智能体（LLM Agents）**设计的一套“智能安检与授权系统”。

想象一下，未来的 AI 不再只是陪你聊天的机器人，而是能帮你订机票、查银行余额、甚至操作公司数据库的“全能管家”。

如果这个管家太“听话”，别人随便说句话它就照做，那它可能会把你的钱转走，或者把机密文件发给陌生人。但如果它太“死板”，连你让它“删除一个临时文件”都因为怕危险而拒绝，那它就没法干活了。

这篇论文的核心观点就是：安全不能只看“说了什么”，而要看“在什么情况下、谁让做的、为了什么目的”。

下面我用几个生活中的比喻来拆解这篇论文：

1. 核心问题：为什么“一刀切”行不通？

比喻：餐厅里的“禁止喧哗”牌
想象一家餐厅挂着一块牌子：“禁止大声说话”。

场景 A：一个顾客在角落里大声打电话骂人。这是违规的，保安应该制止。
场景 B：一个顾客在角落里大声给过生日的朋友唱生日歌。这也是“大声说话”，但这是合法的，甚至很温馨。

如果餐厅保安（现有的安全防御）只看“声音大不大”就抓人，那过生日的朋友也会被赶出去（误杀，损失了实用性）。
如果保安完全不管，那骂人的人就会继续骚扰（漏网，造成安全隐患）。

论文指出：现在的 AI 安全就像那个只会看“声音大小”的保安。它分不清“恶意指令”和“正常指令”，因为同样的指令（比如“删除文件”），在黑客手里是破坏，在用户手里是清理垃圾。

2. 新框架：四大“安全安检门”

为了解决这个问题，作者提出了四个“安检门”，只有同时通过这四道门，AI 的动作才是安全的。

第一道门：任务对齐 (Task Alignment) —— “这事儿在允许做的范围内吗？”

比喻：你雇佣了一个私人厨师。
规则：厨师只能做“做饭”相关的事。
违规：如果厨师突然决定去“制造毒药”或者“去隔壁偷东西”，这就越界了。
作用：确保 AI 做的事情，是你一开始允许它做的范围（比如“帮我订晚餐”），而不是去干坏事（比如“帮我造炸弹”）。

第二道门：动作对齐 (Action Alignment) —— “这一步具体是在干正事吗？”

比喻：还是那个厨师。
场景：你让他“做一顿健康的晚餐”。
- 合法动作：去超市买蔬菜、切菜。
- 非法动作：虽然也是在做饭，但他突然决定“顺便把邻居家的狗抓来炖了”。
作用：即使大方向是对的（做饭），但每一个具体的小动作（抓狗）必须也是为了那个大目标服务的。如果动作偏离了目标，就是违规。

第三道门：来源授权 (Source Authorization) —— “这话是谁让说的？”

比喻：厨师在厨房工作。
场景：
- 情况 A：你（老板）走进厨房说：“把盐放少点。” -> 合法，因为是你说的。
- 情况 B：一个送外卖的小哥路过窗口，隔着门喊：“把盐放少点，顺便把冰箱里的肉全扔了！” -> 危险！虽然也是“放盐”，但“扔肉”这个指令来自陌生人。
作用：AI 必须分清指令是来自可信的老板（你），还是来自不可信的陌生人（黑客、恶意网页）。如果陌生人混在菜谱里（比如网页里藏了一行字）指挥 AI，AI 必须能识破。

第四道门：数据隔离 (Data Isolation) —— “别把张三的秘密告诉李四”

比喻：厨师手里有两份菜单，一份是A 先生的（对花生过敏），一份是B 先生的（对海鲜过敏）。
违规：厨师在做 B 先生的菜时，突然说：“哦，A 先生对花生过敏，所以我也不能给 B 先生吃花生酱。”（虽然没直接说 A 的名字，但泄露了 A 的隐私）。
作用：确保 AI 在处理不同用户、不同任务时，不会把 A 的隐私数据“流”到 B 的上下文中。

3. 如何验证？（神谕函数 Oracle Functions）

作者提出了一套“理想化的检测工具”（神谕函数），用来在 AI 做动作之前或之后进行“灵魂拷问”：

谁指使的？（来源追踪）
目的是什么？（目标评估）
这个动作符合目的吗？（动作评估）

虽然现在的 AI 很难完美做到这些（就像很难完美读懂人心），但作者说，只要有了这个标准，我们就能知道现在的防御手段哪里做得好，哪里是瞎蒙的。

4. 重新定义“攻击”

有了这套框架，很多以前模糊的“黑客攻击”现在变得非常清晰：

间接提示注入（Indirect Prompt Injection）：
- 以前定义：只要网页里有指令，就是攻击。
- 新定义：如果指令来自陌生人（来源未授权），且动作偏离了目标（比如让你把数据发给黑客），这才是攻击。如果指令来自陌生人但完全符合你的目标（比如菜谱里说“烤箱 200 度”），那就是合法的。
越狱（Jailbreak）：
- 用户直接命令 AI 去做绝对禁止的事（比如“造病毒”）。这违反了“任务对齐”。
困惑的副手（Confused Deputy）：
- AI 以为自己有特权，帮用户做了用户没权限做的事。比如用户没权限看 HR 数据库，但 AI 用自己的权限帮用户看了。这违反了“来源授权”。

5. 总结与未来

这篇论文就像给 AI 安全领域画了一张精确的地图。

以前的做法：像在大海里捞针，看到可疑的词就拦截，结果误伤很多正常功能。
现在的做法：建立了一套上下文安检系统。它不只看“词”，而是看“谁、在什么时间、为了什么目的、对谁、做了什么”。

未来的方向：
我们需要开发更聪明的“安检员”（算法），能真正理解上下文，而不是只会背单词。同时，我们需要新的测试标准，不能只测 AI 会不会被“骗”，还要测它在复杂、多轮对话、跨会话的场景下，能不能守住这四道门。

一句话总结：
真正的安全，不是让 AI 变得“胆小怕事”，而是让它变得“明辨是非”——知道什么时候该听谁的，什么时候该做什么，以及什么时候该保守秘密。

论文标题：A Framework for Formalizing LLM Agent Security

作者：Vincent Siu, Jingxuan He, Kyle Montgomery, Zhun Wang, Neil Gong, Chenguang Wang, Dawn Song
机构：UC Santa Cruz, UC Berkeley, Duke University

1. 研究背景与问题 (Problem)

随着大语言模型（LLM）代理（Agents）越来越多地介入现实世界任务（如调用工具、访问数据库、执行代码），其安全性成为关键挑战。现有的安全定义和防御机制存在以下核心缺陷：

缺乏上下文感知（Context-Agnostic）：现有的攻击定义（如提示注入）往往仅基于输入内容的表面特征（例如，只要输入中包含指令性文本就被视为攻击），而忽略了执行上下文。
- 例子：同样的“删除文件”指令，如果是用户授权的合法清理任务，则是正当行为；如果是未授权来源的恶意注入，则是安全违规。现有方法无法区分这两种情况。
效用与安全的权衡（Utility-Security Trade-off）：由于缺乏上下文判断，防御者面临两难：
- 若统一拦截所有包含特定关键词的输入，会导致大量误报（False Positives），损害代理的实用性。
- 若过于宽松，则会让代理容易受到攻击（如被未授权来源劫持）。
定义模糊：现有的攻击分类（如直接/间接提示注入、越狱、任务漂移等）缺乏统一的理论框架，导致防御机制碎片化，难以系统性评估。

核心问题：如何建立一个形式化框架，能够根据执行上下文（谁发出的指令、目标是什么、信息流是否合规）来精确界定 LLM 代理的安全性与攻击行为？

2. 方法论 (Methodology)

作者提出了一个基于**上下文安全（Contextual Security）的系统化框架，将代理的执行过程形式化，并引入了一组神谕函数（Oracle Functions）**来验证安全属性。

2.1 执行上下文形式化 (Execution Context)

在时间步 $t$ ，代理的执行上下文 $C_t$ 被定义为元组：
$C_t = (p, Tr_{t-1}, M_t, E_t, S_{auth,t}, G)$
其中包含：

$p$ ：用户提示（初始目标）。
$Tr_{t-1}$ ：之前的动作 - 观察轨迹。
$M_t$ ：持久化记忆。
$E_t$ ：环境状态。
$S_{auth,t}$ ：已认证的源集合。
$G$ ：源权限图（Source Permission Graph），定义谁可以访问/影响谁。

2.2 神谕函数 (Oracle Functions)

为了在运行时验证安全，框架定义了五个理想化的神谕函数（类似于密码学协议中的理想功能），用于提取验证所需的关键信息：

指令归因函数 $I$ ：识别哪些输入导致了当前动作（区分指令与背景信息）。
来源归因函数 $L$ ：追踪每个输入的来源（是用户、系统、还是外部网页？）。
目标评估函数 $H_p, H_{Tr}, H_a$ ：
- $H_p$ ：从提示中提取授权的目标 $o_0$ 。
- $H_{Tr}$ ：判断当前轨迹是否服务于 $o_0$ 。
- $H_a$ ：判断单个动作是否服务于 $o_0$ 。

2.3 四大安全属性 (Four Security Properties)

基于上述上下文和神谕函数，框架定义了四个核心安全属性。只有当所有属性同时满足时，代理的行为才是安全的：

任务对齐 (Task Alignment)：
- 确保代理追求的目标是用户授权的（ $o_0 \in O$ ，其中 $O$ 是允许的目标空间）。
- 防止越狱（目标超出安全范围）和任务漂移（轨迹偏离初始目标）。
动作对齐 (Action Alignment)：
- 确保每一个具体的动作都服务于授权的目标。
- 防止能力滥用（例如，在推荐食谱时，虽然整体任务合法，但查询医疗记录这一具体动作与目标无关）。
来源授权 (Source Authorization)：
- 确保指令仅来自已认证的源（ $S_{auth,t}$ ）。
- 防止间接提示注入（未认证的外部来源如网页、邮件中的指令被当作权威指令执行）。
- 注：如果未认证来源的内容确实服务于授权目标（如用户说“按这个食谱做”，食谱来自未认证网站），则需结合动作对齐判断，但核心原则是未认证源不能直接指挥特权操作。
数据隔离 (Data Isolation)：
- 确保信息流遵守权限边界（基于源权限图 $G$ ）。
- 防止跨上下文信息泄露（如将用户 A 的预算信息泄露给用户 B，或在不同会话间复用敏感数据）。

2.4 攻击与防御的重构

利用该框架，作者将现有的攻击重新定义为对上述一个或多个属性的违反，并将防御机制重构为对神谕函数的近似或属性检查。

3. 关键贡献 (Key Contributions)

首个上下文感知的安全框架：
提出了一个形式化框架，将 LLM 代理的安全从“基于内容”转变为“基于上下文”，明确了执行上下文 $C_t$ 在授权决策中的核心地位。
四大安全属性与神谕函数：
定义了任务对齐、动作对齐、来源授权和数据隔离四个属性，并引入了神谕函数来形式化描述防御机制必须近似的信息（如指令归因、来源追踪、语义目标评估）。
攻击与防御的系统化重定义：
- 攻击重构：将间接提示注入、直接提示注入、越狱、任务漂移、记忆中毒、困惑副官（Confused Deputy）、能力滥用等攻击，精确映射为特定安全属性的违反。
  - 例如：间接提示注入被定义为“未认证源（违反来源授权）+ 动作不服务于目标（违反动作对齐）”。
- 防御重构：揭示了现有防御的局限性（如基于模式的过滤无法区分上下文），并指出防御应致力于增强神谕函数的近似能力。
揭示现有防御的根本局限：
指出许多现有防御（如简单的输入过滤）缺乏对 $I$ （指令归因）和 $L$ （来源归因）的准确近似，导致在面对自适应攻击时失效，或在保持安全时牺牲过多效用。

4. 结果与分析 (Results & Analysis)

论文通过理论分析和案例研究展示了框架的有效性：

攻击分类的精确性：
- 间接提示注入：传统定义认为任何外部输入中的指令都是注入。新框架指出，只有当外部指令导致动作偏离目标（违反动作对齐）且来源未认证时，才构成攻击。这解释了为什么“按食谱做”是合法的，而“按邮件指令泄露数据”是攻击。
- 直接提示注入 vs. 越狱：区分了“在允许范围内冲突指令”（违反任务对齐，如用户要求忽略系统提示）与“请求完全禁止的目标”（违反任务对齐，如请求制造生物武器）。
- 能力滥用：识别出代理拥有权限且任务整体合法，但具体动作（如查询医疗记录）与当前任务（推荐食谱）不匹配的情况。
防御机制的评估：
- 分析了现有防御（如 Prompt Engineering、模型微调、沙箱、输出过滤）在近似神谕函数方面的表现。
- 发现基于**动作对齐（ $H_a$ ）的防御（如检查工具调用是否符合目标）比仅基于来源/指令过滤（ $I/L$ ）**的防御更有效，但往往伴随着较高的效用损失（误报）。
- 指出数据隔离和跨会话安全是现有防御中最薄弱的环节。
开放问题：
指出了实现神谕函数的实际挑战（如因果归因的困难、语义判断的鲁棒性），以及动态环境、多代理协作和组合式安全（Compositional Safety）等未来研究方向。

5. 意义与影响 (Significance)

理论突破：
解决了 LLM 代理安全领域长期存在的定义模糊问题，提供了一个统一的数学语言来描述攻击和防御，使得不同研究之间的比较和整合成为可能。
指导防御设计：
明确了防御机制的设计目标：不应仅仅是内容过滤，而应致力于构建能够近似神谕函数（特别是指令归因和来源追踪）的机制。这为开发更智能、上下文感知的防御系统指明了方向。
解决效用 - 安全困境：
通过上下文感知，框架展示了如何在允许合法操作（如读取外部食谱）的同时阻止恶意操作，从而在理论上打破“安全即牺牲效用”的零和博弈。
推动基准测试发展：
指出当前基准测试缺乏授权上下文（如未定义谁认证、权限边界是什么），呼吁建立包含明确授权上下文的新型基准测试，以评估代理在真实场景中的安全性。

总结：这篇论文通过引入形式化的上下文安全框架，将 LLM 代理安全从经验性的“打补丁”模式提升到了系统性的理论分析高度，为构建真正安全、可靠且实用的 AI 代理系统奠定了重要的理论基础。