Uber 提出 Persona Guardrail：迭代允许清单把智能体越界检测从 57.3% 提升到 93.5%，误放行率降至 4.7%

框架以“功能边界”为核心抽象，把每个智能体的允许意图与禁止意图写成语义允许清单和阻止清单，在请求进入智能体之前和响应返回用户之前各做一次同步校验。 既有运行时防御多针对提示注入等特定攻击类别，而该工作把防御目标改为“智能体是否在其既定功能范围内运行”，从而同时覆盖恶意请求与良性但越界的请求。 论文给出形式化定义（功能边界把查询空间划分为应处理集与应拒绝集），并说明允许清单由代码导向 LLM 分析智能体实现与产品需求生成，随后在影子模式下用生产流量补充。

在 PAGE 基准上，迭代精炼的允许清单配置取得最高综合表现：准确率 95.9%、精确率 96.3%、召回率 95.3%、F1 95.8%，误放行率 4.7%、误拦截率 3.6%。 相对仅给通用智能体描述的基线裁判（准确率 85.7%、域外检测 57.3%、误放行率 25.0%），显式允许清单把域外检测提升到 83.3%，一次基于误放行与误拦截样本的迭代再提升到 93.5%。 所有配置在相同 PAGE 划分上评测；附录报告了不相交的二路与三路划分上的留出验证，v1→v2→v3 在未见数据上准确率单调上升（如 91.9%→96.1%→96.7%），说明增益不是调参过拟合。

仅用阻止清单的配置明显更弱：准确率 71.2%，域外检测仅 14.5%，误放行率 49.0%；在允许清单之上再加阻止清单也未改善，反而使良性误拦截率从 3.6% 升至 8.2%、准确率降至 94.9%。 这表明阻止清单枚举的是攻击而非智能体功能，无法识别“表述流畅、任务化但超出范围”的请求，而这类请求正是功能边界防御的难点。 逐标签分析显示对抗性检测在各允许清单配置下均较高（96.8%–97.0%），而域外检测在基线 57.3%、允许清单 83.3%、迭代允许清单 93.5%、阻止清单 14.5% 之间拉开差距。

生产部署方面，框架以 Qwen3-30B-A3B（MoE，约 30B 总参数、每 token 激活约 3B，FP8 量化）作为输入与输出共享分类器，在 vLLM 与 NVIDIA Dynamo 上以 CPU 前端与 GPU worker 解耦方式服务。 论文把护栏视为一种专门的推理负载——单 token、以 prefill 为主、共享约 93% 输入 token 的静态前缀——并据此用前缀缓存复用、前后端解耦与有界上下文来满足延迟预算，而非通用服务调优。 在 5–50 QPS 区间，中位延迟 19.43–25.34 毫秒、P90 延迟 57.30–61.08 毫秒，P99 在 30 QPS 处越过 100 毫秒目标；加速器利用率低于 65%；相对此前通用服务栈，解耦设计把护栏调用延迟降低约 30%。

该框架面向直接恶意用户与域外交互这一威胁模型：外部用户通过公开接口黑盒访问智能体，无法操纵其内部工具、检索文档、记忆或执行环境。在此设定下，它适用于需要拒绝越界请求的客户面向智能体，例如论文使用的 Workspace、Slack、Banking、Travel 四个域；是否把域外请求纳入阻止范围可由部署方配置，因此也支持选择回答或礼貌重定向的部署模式。方法上，允许清单由代码导向 LLM 分析智能体实现与产品需求生成，再经影子模式下的生产流量补充，并通过人工可读的意图分类法迭代精炼，而非重新训练分类器；候选更新需在黄金集、对抗集与生产采样集三类留出池上同时满足预设的安全、效用、可靠性与延迟阈值，经人工评审后以声明式配置分发，先在影子模式评估再限量放量。工程上，结果适用于单加速器模型调用、4,096 token 上下文上限的设定，且延迟测量不含应用与网络开销。

论文明确说明其结果是针对既定威胁模型的纵深防御控制，不构成对间接提示注入、组件被攻陷、未授权的中间工具动作、多轮攻击或其他模型外威胁的完整防护，部署决策与可接受错误率仍取决于具体应用。混合意图轮次的标注语义是一个开放问题：护栏在两种标注策略下都拦截约 92.2% 的混合轮次，因此把混合轮次计为应放行会把误拦截率抬到 17.1%、准确率降到 88.6%，而计为应拦截则保持 95.6% 的准确率与 3.6% 的误拦截率，这说明“含合法成分的轮次应否放行”需要按部署策略明确。附录中的知情攻击者实验显示，攻击者获得逐字意图清单时优势最大，但该场景现实风险较低；同时所用闭源攻击模型因安全调优在首轮攻击上有 17%–71% 的拒绝率，这一测量条件会影响对攻击强度的解读。此外，论文无法公开确切的生产护栏提示词，精确复现依赖内部基础设施；未来工作指向对话级与工具调用级的边界执行，这两项目前尚未纳入评测。