💻 computer science

Runtime Compliance Verification for AI Agents

本文介绍了 C-Trace，这是一个通过将监管要求表达为形式化谓词、监控执行轨迹以阻断违规行为，并在多个案例研究中证明了在缓解攻击诱发的违规方面具有高度有效性的运行时验证框架，旨在为 AI 智能体强制执行 GDPR 合规性。

原作者： Nafiseh Kahani, Masoud Barati, Diana Addae

发布于 2026-06-19

📖 1 分钟阅读☕ 轻松阅读

原作者： Nafiseh Kahani, Masoud Barati, Diana Addae

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

想象一下，你雇佣了一位聪明、健谈的私人助理来帮你打理生活。这位助理可以打电话、发邮件、查询你的银行详情，甚至删除你的记录。然而，由于这位助理是由人工智能驱动的，它并不总是“懂得”隐私规则。它可能会不小心把你的地址告诉陌生人，或者在你从未说过“好”的情况下给你发送营销邮件。

这篇论文介绍了一个名为 C-Trace（合规追踪式运行时智能体一致性强制执行系统）的系统。不要把 C-Trace 仅仅看作是一个新的助手，而要把它看作是一个站在 AI 助手身旁、极其严厉且警觉的保安，实时监视着它说的每一个字和采取的每一个行动。

以下是该系统的运作方式，通过简单的概念进行拆解：

1. 问题所在：“健忘”的助手

目前测试这些 AI 助手的方法就像是在它们开始工作前给它们进行一次“随堂测验”。你问：“你会遵守规则吗？”它们回答：“是的。”但一旦它们真正开始工作、与真实的人交谈时，它们可能会忘记这些规则。

问题： AI 在一次对话中可能符合合规要求，但在下一次对话中可能会违反规则，这取决于用户的要求。
差距： 现有的安全工具就像是只在门口检查身份证的保镖（静态检查）。它们不知道你是否已经在当晚早些时候承诺过要提前离开派对。它们忽略了整个对话的上下文。

2. 解决方案：“保安”（C-Trace）

C-Trace 位于 AI 与外界之间。它会观察整个对话过程（即“追踪”）。它不仅仅看一句话，它还记得整个故事。

它通过充当过滤器来强制执行四项主要的“隐私法”（基于 GDPR）：

“知情同意”检查 (P1)： 在 AI 执行诸如发送营销邮件之类的操作之前，保安会检查：“用户此前是否明确表示过‘同意’？”如果用户只是说，“我大概不介意，”但从未点击正式的“是”，保安就会阻止该行为。
“目的限制”检查 (P2)： AI 被雇佣是为了完成一项特定的工作，比如修复一个损坏的订单。如果用户要求 AI 利用该订单数据为另一家公司建立画像，保安会说：“不行，那是另一项工作。你并没有被授权做那个。”
“最小化数据”检查 (P3)： 如果 AI 需要检查订单，它只需要订单号和电子邮件。如果 AI 试图为了检查订单而获取用户的出生日期或政府身份证件，保安会说：“信息太多了。你只需要基础信息即可。”
“删除权”检查 (P4)： 如果用户说“删除我的数据”，保安会将该用户标记为“已删除”。如果 AI 稍后试图再次提及该用户，保安会关上门：“这个人已经在我们的系统中不存在了。你不能再提到他。”

3. 如何测试： “猫鼠游戏”

为了看看这个保安是否真的有效，研究人员玩了一场“猫鼠游戏”。

攻击者： 他们使用一种特殊的程序 (DSPy) 生成了数百个棘手的、令人困惑的或具有攻击性的对话，旨在诱导 AI 违反规则。他们还使用了来自其他安全测试的真实“越狱”提示词。
测试： 他们让 AI 在有和没有这个保安的情况下尝试处理这些棘手的对话。
结果： 没有保安的情况下，AI 经常违规（有时是 100% 违规）。有了 C-Trace 保安后，AI 几乎每次都被拦截了。即使当保安不得不“猜测”一句话中包含什么数据时（因为完美理解人类语言很难），它仍然抓住了绝大多数违规行为。

4. “三头”验证

为了确保保安不是在信口开河，研究人员用三种不同的语言构建了相同的规则手册（Python 代码、一种名为 Rego 的策略语言，以及一种逻辑语言 MFOTL）。

类比： 想象三个不同的法官在阅读同一个剧本。如果他们都对谁有罪达成了一致，你就知道判决是可靠的。在这篇论文中，这三个“法官”在每一个测试案例上都达成了完美的共识。

5. 核心结论

论文声称 C-Trace 是有效的。

它能实时阻止 AI 违反隐私规则。
它不会显著减慢 AI 的速度（它仅增加了极小部分的处理时间）。
它创建了一个永久的“审计日志”（书面记录），记录了保安做出的每一个决定，以便人类日后进行审查。

简而言之： 如果你有一个处理敏感数据的 AI 助手，C-Trace 就是确保它不会意外泄露你的秘密、把你的数据卖给错误的人、或忽视你“被遗忘”请求的系统——它通过监视 AI 的每一个动作，并在其试图违规的瞬间将其制止。

技术摘要：AI 智能体的运行时合规性验证

问题陈述

AI 智能体通过工具调用、函数调用和多轮对话，越来越多地处理个人数据。与传统的 API 不同，智能体会动态地决定调用哪些工具、传递哪些参数以及在自然语言中披露哪些信息。这些运行时决策可能会触发《通用数据保护条例》（GDPR）下的义务，例如在未经同意的情况下处理个人数据，或在用户提出删除请求后仍披露数据。

目前的测试实践无法解决这种动态风险：

离线红队测试（Offline Red-Teaming）： 使用策划的提示词测试模型，但无法在运行时强制执行规则，也无法观察已部署智能体的会话状态。
护栏库（Guardrail Libraries）： 匹配单个输入/输出中的模式，但缺乏会话历史，因此无法追踪在对话早期是否已授予过同意，或者是否已声明了用途。

因此，一个智能体部署可能在一次对话中是合规的，而在另一次对话中则是不合规的，而无需任何代码或模型权重的更改。这产生了对智能体事件轨迹进行运行时验证的需求，并需配合一个进程内攻击驱动程序来测试受攻击输入的监控器。

方法论：C-Trace 框架

作者提出了 C-Trace（Compliance Trace-based Runtime Agent Conformance Enforcement，基于追踪的运行时智能体一致性强制执行框架），该框架将 GDPR 合规性视为事件流的运行时属性，而非单条消息的属性。

1. 事件模型与提取

该框架对智能体循环进行插桩，将自然语言运行转换为类型化事件轨迹 ( $\tau = e_1 \dots e_n$ )。事件包括 UserMsg（用户消息）、AsstMsg（助手消息）、ToolCall（工具调用）、ToolRet（工具返回）、Consent（同意）和 Erasure（擦除）。

标注： 提取器为每个事件标注数据类别 ( $C(e)$ ) 和用途 ( $\Pi(e)$ )。
策略： 会话策略定义了声明的用途、工具与用途的绑定关系，以及针对每种用途的数据白名单（必要的数据类别）。

2. 形式化谓词

四个 GDPR 原则被编码为基于不断增长的轨迹的一阶谓词。这些谓词是单调的：一旦发生违规，后续事件无法将其“修复”。

P1 (同意/Consent)： 处理数据需要针对特定用途的先前 Consent 事件（除非适用“合法利益”依据）。
P2 (用途限制/Purpose Limitation)： 附加到事件的每个用途必须在策略中声明。
P3 (数据最小化/Data Minimization)： 工具调用中的数据类别必须对于该调用的至少一个声明用途是必要的。
P4 (删除权/Right to Erasure)： 在针对某一主体发生 Erasure 事件后，后续任何事件不得披露该主体的标识符。

3. 运行时监控器与攻击驱动器

拦截器 (Interceptor)： 置于智能体循环与工具 API 之间，增量评估谓词。决策包括 forward（转发）、redact（脱敏，即移除非必要数据）或 block（拦截，即拒绝该事件）。
攻击驱动器 (Attack Driver)： 使用以下方式生成针对每个谓词的对抗性对话：
- DSPy 生成的提示词： 使用角色扮演、紧迫感和越狱框架对种子请求进行变体处理。
- 真实语料库提示词： 来自红队测试语料库（HarmBench, AdvBench, DAN）的逐字提示词。
预言机 (Oracle)： 一个独立的、可观测的预言机通过检查被接受的轨迹是否符合策略，来判定攻击是否成功，且该过程独立于监控器的内部谓词。

4. 交叉验证

为了确保操作层面的监控器与形式化规范一致，相同的策略逻辑在三个运行时中实现：

Python： 用于操作层面的强制执行。
Rego/OPA： 用于审计层面的策略。
MFOTL (MonPoly)： 用于形式化时序逻辑规范。
作者验证了这三者在每一条轨迹上都能对每个事件达成一致。

评估与结果

该框架在四个经过 GDPR 重构的案例研究上进行了评估：Shopper（零售）、Airline（航空）、MedAgent（医疗）和 FinAssist（银行/KYC）。

关键指标

攻击成功率 (ASR)： 成功绕过监控器的攻击百分比。
误报率 (FPR)： 被错误拦截的良性请求百分比。
实现率 (Realization Rate)： 在没有监控器的情况下，模型尝试违规行为的频率。

研究发现

未受监控智能体的脆弱性： 在没有监控器的情况下，智能体在所有四个家族中都会犯错。同意绕过 (A1) 和过度收集 (A3) 经常被触发（在某些情况下 ASR 高达 100%）。
基准测试的局限性：
- Regex/Presidio (无状态)： 这些基准测试无法检测依赖于会话历史的违规行为（如同意、用途限制、删除）。虽然 Presidio 减少了过度收集，但它无法阻止同意绕过或删除后的召回。
- 随机基准 (Random Baseline)： 具有高误报率（72–88%）且没有针对性的保护。
C-Trace 表现：
- 完美提取： 在所有案例研究和攻击注册表（生成的及真实语料库）中，实现了 0% ASR 和 0% FPR。
- 噪声提取： 在每类别提取器存在低于 10% 噪声（模拟掉线和过度分类）的情况下：
  - ASR 保持在 $\le$ 12%（显著低于基准测试）。
  - FPR 保持在 $\le$ 16%。
- 消融实验： 移除单个谓词会恢复特定的攻击家族（例如，移除 P1 会恢复同意绕过），证实了每个谓词的必要性。
开销： 监控器为每个事件增加的中间延迟极低，仅为 1.8 $\mu$ s。

重要性与主张

本文声称是首个将 GDPR 义务的运行时验证应用于 AI 智能体自然语言执行轨迹的工作。

新颖性： 与无状态护栏不同，C-Trace 对会话轨迹进行推理，从而能够捕捉依赖于早期事件（如先前的同意或删除）的违规行为。
实用性： 该框架作为一个进程内拦截器运行，无需修改底层模型或工具实现。它生成适用于合规审查的追加式 JSONL 审计日志。
可靠性： 结果表明，监控器的可靠性高度依赖于类别提取器的准确性。虽然策略逻辑是稳健的，但由于提取错误导致的类别遗漏是主要的失效模式。
范围： 该方法专注于四个核心 GDPR 原则（同意、用途限制、数据最小化、删除权），适用于多个领域（零售、医疗、金融）和法律依据（同意、法律义务）。

作者得出结论，只要底层的事件提取质量足够高，并且针对模糊的数据类别设有失效保护机制，那么基于追踪的监控是 AI 智能体的一种实用的强制执行层。