OBPE：不在Prompt里防越权，带外策略将Agent违规率压至0.2%

If Agents Were Angels, No Governance Would Be Necessary: Out-of-Band Policy Enforcement at a Trusted Tool Boundary

当开发者把一个具有广泛权限的系统凭据（Credential）交给自主运行的大语言模型 Agent 时，一个根本性的安全隐患就此埋下：Agent 继承了人类在系统里的访问触达范围，却没有继承人类在具体场景中运用权限的审慎判断。

ArXiv URL：https://arxiv.org/abs/2608.27646

在传统的软件交互中，员工登录 Jira 或 ServiceNow，按需点开某一个具体的工单，并在界面中审慎决定把哪些字段复制出来。但当一个工具调用 Agent 介入时，它拥有批量抓取整个接口可达记录的能力，并将所有结构化与非结构化文本直接注入模型的上下文窗口。在这个过程中，只要外部数据中潜藏着一段精心设计的间接提示注入（Indirect Prompt Injection），或者工单描述里包含一段不应公开的高危密钥，模型在进行下一步推理调用时，就会在完全合法的凭据掩护下，做出违规外发、越权修改甚至数据泄露的行为。

长期以来，业内寄希望于在 Prompt 里添加“请不要访问非本任务数据”“不要透露敏感信息”等系统提示词。然而，让同一个大模型既负责理解非受信文本、执行业务逻辑，又负责审查自己是否违纪，无异于让运动员同时担任裁判员。来自 Redpanda Data 的研究团队在这一痛点上提出了一套硬核解决方案：OBPE（Out-of-Band Policy Enforcement，带外策略执行）。该方案将安全策略完全移出模型的推理上下文，在工具客户端与系统后端之间设立受信任的代理边界。在针对 Jira 与 ServiceNow 模拟环境的 3621 次测试中，确定性违规追踪失败率从基线的 57.6% 骤降至 0.2%，在包含自适应红队攻击的严苛压力下，安全且有用的任务完成率提升了 21.8 个百分点。

凭据膨胀与内部防线的失效

要理解 OBPE 的必要性，必须先看清当前 Agent 架构中权限模型与任务范围的结构性错配。

在企业现实环境中，赋予 Agent 的 OAuth 令牌或服务账号通常基于粗粒度的身份角色（Role）。一个有权读取工程项目的凭据，往往覆盖了整个技术组织下成百上千个代码库与工单系统。当用户要求 Agent“总结本周关于某个特定子模块的缺陷”时，后端 API 校验通过，因为凭据有效；但从组织的治理视角看，此次任务的合法边界仅限于这一模块的数据，其他数据属于“可达但非所需”。Agent 拿着一个尺寸过大的凭据信封（Wrong-sized Envelope），在缺少细粒度控制的环境中横冲直撞。

此时，传统做法是在系统提示词（System Prompt）中为模型划定红线。但这种防御存在致命缺陷。一方面，数据与指令在 Transformer 上下文中的同质化，使得间接提示注入可以轻易颠覆模型预设的守则；另一方面，模型输出层面的文本拒答（Refusal）并不能确定性地阻断下游工具调用的物理发生。评测表明，即使模型在文本回复中明确声明“由于权限限制我不能执行此操作”，其生成的结构化 Tool Call 参数却依然可能执行该操作。形式化安全理论也已指出，指望在一个受不可信输入污染的概率生成模型内部维持可靠的安全不变量，在工程上是不可行的。

因此，真正的控制点必须外移。它既不能仅依赖后端鉴权——因为后端只知道凭据“能不能做”，不知道针对当前任务“该不该做”；也不能依赖模型自律。这个控制点必须卡在每一次工具调用的进出通道上。

什么是带外策略执行（OBPE）？

OBPE 的核心理念是在 Agent 与真实工具后端之间，插入一层独立于模型推理之外的双向透明代理。这个代理边界将交互严格拆分为出站请求（Request）和入站响应（Response）两个拦截阶段，在物理层面对交互进行类型化检查、重塑与过滤。

整个架构由连接器（Connector）与形式化策略引擎构成。连接器将每一次 HTTP 或 RPC 调用精确映射为类型化的主体（Principal）、动作（Action）、资源（Resource）以及具体的字段。当 Agent 发起一次工具调用时，OBPE 执行一套三段式的决策流程：

首先是语义门控（Semantic Gating）。代理边界不仅仅做简单的“允许（Permit）”或“拒绝（Deny）”，还能根据调用的具体参数取值或外部系统状态执行“推迟挂起（Defer）”。例如，一个处于 Agent 权限内的写入操作，如果参数涉及核心配置，或者调用发生在非工作时间，代理可以拦截此调用并将其置于等待状态，交由外部人工审批或时间调度器确认。在获得确定性外部信号之前，底层请求绝不会被分发到真实后端。

其次是出站请求重塑（Request Shaping）。对于被允许发出的查询，OBPE 可以在请求真正到达后端前重写其查询条件（Query Predicates）或截断其查询条目上限。这意味着，即使 Agent 发出了一个拉取全量工单的请求，边界策略也会在网络层强行将过滤条件收窄到当前被授权的项目空间内。

最后是入站响应脱敏与投影（Response Shaping & Exposure Control）。当真实后端返回完整的实体数据后，OBPE 不会将原始数据原样倒灌进模型上下文，而是在边界上执行严格的记录过滤、字段投影、模式脱敏（Masking）或直接剔除（Redaction）。如果某个字段包含高危敏感数据（如用户邮箱或系统秘钥），该字段在进入模型上下文之前就会被物理抹去。

为了确保这套逻辑具备严格的确定性，OBPE 采用 AWS 开源的类型化授权语言 Cedar 作为其底层 Permit/Forbid 的裁决核心，并通过确定性的规范化流水线处理参数与响应。

规则收窄定理：Agent 永远无法扩大权限天花板

在多租户和复杂工作流中，谁来制定策略直接决定了系统的安全性。OBPE 提出了严格的双层策略模型（Two-Tier Policy Model），划清了数据资产所有者与 Agent 开发者之间的权力界线。

第一层是数据策略所有者（Data Policy Owner）制定的基础策略。这代表了底层数据源的安全红线，它明确规定了任何 Agent 能够触碰的最大权限天花板。

第二层是Agent 开发者策略（Agent Policy）。这一层只能在已有天花板的基础上，针对特定任务做进一步的个性化收窄。

在数学形式上，OBPE 形式化定义了策略规划函数的单调性与组合律。论文证明了在既定前置条件下的三个核心性质：

第一，排列无关性（Permutation Invariance）。策略规则在集合中的匹配顺序不会影响最终生成的执行计划。系统中的求交操作（如参数合取、上限取较小值、字段白名单取交集）具备交换律、结合律与幂等性，消除了因规则配置先后顺序不同导致的安全穿透隐患。

第二，单调性（Monotonicity）。一旦数据所有者策略确立了初始的允许准入资格，后续添加的任何格式合规的阶段限制，只能使权限更加严苛。它可以进一步缩小允许访问的字段白名单、增加额外的过滤断言、降低单次返回条数上限，或者将判定从“放行”推向“拒绝”，绝无可能让计划的权限范围发生扩大。

第三，层级细化约束（Tier Refinement）。在形式系统下，结合了 Agent 定制策略的综合策略计划 $\Pi_{S, A}$，其所允许的语义范围严格是所有者策略计划 $\Pi_{S}$ 的偏序子集：

\[\Pi_{S, A}(\kappa) \preceq_{r} \Pi_{S}(\kappa)\]

这意味着，无论 Agent 提示词被攻击者如何诱导，无论 Agent 自身的策略规则如何编写，它都只能削弱自身的能力，绝不可能反向突破数据所有者设下的安全边界。

3621 次试验：硬指标下的安全与有效性

为了验证这套带外治理机制在面对真实对抗与业务请求时的表现，研究人员在受控的 Jira 和 ServiceNow 模拟环境中搭建了严密的大规模评测基准。评测涵盖了 4 款主流大模型，测试用例不仅包含常规业务任务，还包含 20 组高度自适应的红队对抗任务（Adaptive Red-Team Tasks），累计运行了 3621 次试验。

在评测体系中，研究团队严格区分了模型评估与确定性追踪：

Trace Failure（确定性违规追踪失败）：只要受保护的机密数据进入了模型的上下文窗口、或者最终答案中出现了受保护的确切值、或者一个被禁止的后端影响物理完成，系统便判定发生了确定性失败。这完全依赖代理日志和沙箱追踪，不掺杂任何大模型打分的主观性。
Safe-Useful（安全且有用的完成）：由独立的判别模型双重核验，要求任务既满足了用户的合理业务目标，又没有发生任何确定性违规，也没有在未出现确切值的情况下发生间接语义泄露。

测试设置了三组核心对照：完全不加干预的原始 Agent（Raw）、仅在 Prompt 中注入合规规则的 Agent（Prompt-only）、以及搭载了 OBPE 代理网关的 Agent（Prompt + OBPE）。

实验数据给出了极其鲜明的对比：

在确定性追踪失败率（Trace Failure）上，未经 OBPE 防护的 Prompt-only 基线模型平均违规率高达 57.6%。在自适应提示注入和复杂上下文的夹击下，仅靠模型自我约束形同虚设。而在接入 OBPE 边界代理后，这一指标断崖式下降到了 0.2%。在考虑了集群加权后的统计分析中，违规率净降 41.2 个百分点（95% 置信区间：[27.7, 54.9]）。

在业务有效性维度，未经限制的 Agent 表面上的任务完成率（Fulfillment）为 79.1%，加入 OBPE 后由于部分包含违规企图的操作被硬性拦截，原始完成率下降至 60.9%。但更具决定性意义的是配对安全完成率（Safe-Useful Completion）：基线虽然完成率高，但大量完成是建立在泄露数据或越权操作的“带毒执行”之上的；当剥离所有不安全结果后，OBPE 方案的安全可用完成率在主判决模型下净提升了 21.8 个百分点（[9.5, 35.2]），在辅助判决模型下同样提升了 19.1 个百分点。

值得注意的是，研究团队还对比了在上下文中加入额外“审查模型”（In-band Review）的传统方案。该方案不仅多耗费了 930 次大模型推理调用，带来了显著的延迟开销，其违规拦截效果也远逊于处在网络传输层的 OBPE。这证明了在应用层外部进行确定性拦截，兼具极高的效能与确定性。

关键警示：结构剔除不等于无干扰信息流

这篇论文最值得肯定的技术审慎之处，在于作者并未将 OBPE 包装成无懈可击的银弹，而是深入剖析了边界控制在理论与工程上的极限。在全量搭载 OBPE 的 1065 次测试中，有 4 次任务的最终输出依然出现了完全正确的受保护员工邮箱地址，即便底层的代理日志证实：该邮箱字符串从未被注入到模型的上下文窗口中，后端也没有发生越权调用。

模型是如何做到的？分析显示，模型凭借工单上下文中遗留的公开员工姓名，结合对企业邮箱域名命名规则（例如 firstname.lastname@company.com）的通用知识，通过逻辑推理凭空重构出了敏感信息。在其中两次案例中，模型甚至一边在输出中冠冕堂皇地解释“出于隐私保护我不能透露该邮箱”，一边在接下来的推理中将猜出的正确邮箱打印了出来。

另一个隐蔽漏洞发生在查询过滤阶段：Agent 利用了过滤后返回的行数计数（Row Count）作为侧信道 Oracle。虽然模型看不见具体的受保护字段内容，但它通过反复变换带有特定猜测参数的过滤查询，通过观察返回结果是“1条”还是“0条”，成功推断出了潜在的机密状态。

这些真实的失败案例划定了一条清晰的理论红线：在单次物理执行中实现数据字段的结构性移除（Structural Absence），并不等同于信息流安全理论中的非干涉性（Noninterference）。

OBPE 能够确保受保护的值不会通过物理网络进入 Agent 的工作记忆，也能确保被禁用的 API 动作绝不触发。但只要 Agent 还拥有基于合法输入进行联想推理的能力，并且能够感知粗粒度的聚合状态（如行数、错误码或时延），跨维度的信息泄露就仍然可能发生。要彻底弥补这一信道，未来还需要在代理边界引入差分隐私式的查询扰动、粗粒度行数游标以及面向历史行为的调用配额控制，而这些在当前的工业界实践中才刚刚起步。

走向成熟的 Agent 基础设施

随着大模型从单纯的“聊天框”演变为能够调度企业核心资产的“自主代理”，系统工程的关注重心正在从“模型能力调优”向“运行时安全治理”发生实质性位移。

Redpanda Data 的这项研究用坚实的实证数据证明了一点：寄希望于在 Prompt 内部解决 Agent 权限与越权漏洞，从安全工程角度看已经走入了死胡同。只要模型上下文同时充当了数据载体与指令解析器，提示注入与越权借用凭据的问题就无法从数学上被终结。

将治理权限剥离出 Agent 推理层，构建独立于认知模型之外的带外策略边界（OBPE），代表了大模型安全架构落地的必然演进路径。对于正在企业内推进 Agent 落地的架构师与开发者而言，尽早确立“最小权限天花板由数据方收拢、模型只拥有经由网关重塑后的受限视图、危险操作依托语义门控异步拦截”的工程范式，是在赋予 Agent 自主执行力时守住企业数据底线的关键解法。