当企业开始大规模部署 Agent，一个新的安全问题逐渐浮现：同样由大模型驱动的智能体，是否应该使用完全相同的安全策略？
例如，企业内部有一个财务 Agent、一个人事 Agent 和一个差旅 Agent。它们可能使用相同的基础模型，甚至接入相同的工具平台，但职责完全不同。财务 Agent 可以处理报销和账务，人事 Agent 可以查询员工信息，差旅 Agent 则负责机票和酒店预订。
如果用户让差旅 Agent 查询其他员工的薪资，这个请求未必包含违法违规内容，也不一定存在提示注入，但它显然超出了差旅 Agent 的职能范围。传统通用内容安全护栏即使准确判断请求内容无害，也不代表应该允许 Agent 执行。
2026 年 10 月 2 日，Uber 研究团队发表了论文《Persona Guardrail: A Production-Grade Defense Framework for Agentic Systems》，提出了一套已经进入生产环境的 Agent 安全防护框架。它的核心思路并不复杂：每个 Agent 都应该拥有与自身角色和业务职能相匹配的安全边界。
https://arxiv.org/pdf/2610.03434
论文提出了 Persona Guardrail，通过语义白名单、黑名单和输入输出检测，约束 Agent 的行为范围。在作者构建的 PAGE 评测集上，框架将整体准确率从 85.7% 提升至 95.9%，将超范围请求检出率从 57.3% 提升至 93.5%。
不过，相比这些实验数字，更值得关注的是 Uber 如何把这套机制变成可配置、可迭代、可规模化部署的企业级安全系统。
从场景化风控到 Agent 专属策略
对于传统内容安全行业来说，按业务场景配置不同风控策略并不是一个新概念。
同样是文本内容审核，社交平台可能重点关注辱骂、骚扰和引流；电商平台更关注虚假宣传、违规商品与交易欺诈；金融业务则更加重视敏感信息泄露、欺诈和违规营销。
即使底层使用同一个检测模型，不同业务也可以通过独立的风险分类、检测阈值和处置规则，实现差异化的安全治理。
这种模式在内容安全领域已经相当成熟，而 Agent 的发展让它有了新的应用空间。
过去，一个业务场景通常对应一套内容安全策略。但当企业开始引入大量专业化 Agent 时，安全策略需要进一步细化到具体的智能体。因为 Agent 不只是生成内容，还能够调用工具、访问数据、修改系统状态，甚至替用户执行实际操作。
这意味着，Agent 安全不能只回答「这段内容有没有风险」，还必须回答「当前这个 Agent 是否应该执行这项任务」。
一个 HR Agent 查询员工薪资，可能是符合职责的正常业务；同样的操作如果由差旅 Agent 发起，就属于明显的功能越界。即便两个 Agent 使用相同的模型，判断结果也应该不同。
这正是 Persona Guardrail 所强调的 Functional Boundary（功能边界）：通过明确描述 Agent 被设计来完成什么工作，将用户请求和模型行为约束在相应范围之内。
从产品设计的角度看，这实际上延续了传统内容安全平台「千业务千策略」的思路，只是进一步演变成了 Agent 时代的「一 Agent 一策略」。
Persona Guardrail：给每个 Agent 定义自己的行为边界
Persona 这个词在 AI 领域越来越常见，通常用来描述智能体的角色、人设或行为特征。例如，一个 Agent 可以被设计成专业的金融顾问、耐心的客服人员，或者擅长技术分析的软件工程师。
但 Uber 论文中的 Persona 并不主要关注 Agent 的性格、语言风格或拟人化特征，而是强调其业务职责、允许执行的任务以及禁止触碰的安全边界。
Persona AI 关注 Agent 应该扮演什么角色，而 Persona Guardrail 进一步关注这个角色应该被允许做什么。两者在概念上有所关联，但研究目标并不相同。
Uber 将功能边界表达成自然语言形式的语义策略，而不是试图穷举所有可能的用户请求。其原因很简单：用户可以用无数种方式表达同一个需求，如果只依赖关键词或固定规则，很难覆盖所有表达方式。
例如，差旅 Agent 的一条允许策略可以表述为：「允许当前用户查询、预订和修改本人有权管理的机票、酒店及其他差旅行程。」
这条规则不要求用户必须说出「查询机票」这样的固定关键词，而是由模型根据请求的语义判断，用户究竟是不是在执行允许的差旅任务。
在具体实现上，Uber 为每个 Agent 配置四组意图列表：
策略配置 | 主要作用 |
|---|---|
allowed_user_intents | 定义用户可以向 Agent 提出哪些请求 |
blocked_user_intents | 定义哪些用户请求需要拒绝 |
allowed_agent_intents | 定义 Agent 可以产生哪些回复或行为 |
blocked_agent_intents | 定义 Agent 不应该产生哪些回复或行为 |
其中，白名单负责描述 Agent 应该做什么，黑名单负责描述 Agent 不应该做什么。两者共同为不同 Agent 提供可配置的功能边界。
值得注意的是，Uber 并没有要求每个 Agent 都训练一个专属安全模型。它最终选择 Qwen3-30B-A3B 作为共享分类模型，让不同 Agent 通过加载各自的策略，实现差异化检测。
这样一来，新增 Agent 时，企业主要需要定义新的安全策略，而不是重新开发或部署一套模型。
这与传统内容安全平台的架构非常相似：检测能力由平台统一提供，业务策略则根据实际场景分别配置。对于已经拥有内容安全基础设施的企业来说，这种设计具有较强的可迁移性。
整个防护过程是如何工作的？
Persona Guardrail 的核心执行机制分成输入护栏和输出护栏两个阶段。
当用户向 Agent 发送请求时，输入护栏首先根据该 Agent 的功能边界判断是否允许处理。如果请求违反安全策略，或者超出了当前 Agent 被允许处理的业务范围，系统可以直接拒绝。
如果输入通过检查，请求就会进入 Agent 的正常执行流程。Agent 可以进行模型推理、知识检索和工具调用，并最终生成回复。随后，输出护栏再次检查结果是否符合 Agent 的功能边界以及组织安全策略。
例如，一个差旅 Agent 收到用户要求其查询工资信息的请求，输入护栏可以在执行前识别出功能越界；如果 Agent 在正常查询行程时意外生成了涉及其他用户隐私的内容，输出护栏也有机会在结果返回前将其拦截。
这种双向检测设计并不新颖。传统大模型内容安全产品也广泛采用输入、输出两侧的防护机制。Uber 的不同之处在于，检测依据不仅是通用风险分类，还包括每个 Agent 的专属功能规范。
对于企业来说，这意味着可以用统一的护栏接口服务多个 Agent，而不必为每个业务重新开发检测系统。
不过，这里有一个需要强调的边界：Uber 当前实现主要检查用户输入和最终输出，并没有对 Agent 执行过程中每一次工具调用进行独立授权。
如果 Agent 在中间步骤已经执行了一次错误的转账操作，即使输出护栏拦截了最终回复，也不能撤销已经发生的资金转移。因此，Persona Guardrail 更适合作为现有安全体系的一层补充，而不能替代工具授权和执行过程控制。
实验验证：为什么语义白名单尤其重要？
为了验证 Persona Guardrail 的效果，Uber 构建了一套名为 PAGE（Persona-Aware Guardrail Evaluation）的评测集。
PAGE 共包含 2,180 条带标签的数据，覆盖 Workspace、Slack、Banking 和 Travel 四类 Agent，涉及正常业务请求、恶意请求、超出业务范围的请求以及混合意图请求。
其中，特别值得关注的是 Out-of-Domain（OOD，超范围请求）。
对于通用内容安全模型来说，识别恶意请求已经是比较成熟的能力。但是，OOD 请求可能完全正常，只不过不属于当前 Agent 应该提供的服务。这类请求很难依靠传统风险标签准确识别。
Uber 在实验中比较了五种策略配置，核心结果如下：
策略配置 | 整体准确率 | OOD 检出率 | 正常请求误拦率 |
|---|---|---|---|
通用 LLM 基线 | 85.7% | 57.3% | 3.7% |
初始语义白名单 | 93.2% | 83.3% | 3.7% |
迭代优化白名单 | 95.9% | 93.5% | 3.6% |
仅使用黑名单 | 71.2% | 14.5% | 8.7% |
白名单 + 黑名单 | 94.9% | 96.8% | 8.2% |
注：上述结果来自论文 Table 6、Table 7，使用不包含 180 条混合意图样本的 2,000 条数据。
实验中，单纯使用黑名单的效果相当有限，OOD 检出率只有 14.5%。这其实不难理解：黑名单可以告诉模型哪些行为被禁止，却很难完整描述一个 Agent 究竟应该提供哪些服务。
例如，一个银行 Agent 的黑名单可能包含禁止泄露账户信息、禁止未授权转账等规则。但当用户要求它写一首诗时，请求既没有违反这些规则，也不是恶意内容，黑名单可能因此选择放行。
引入语义白名单后，情况就不同了。模型不仅知道什么不能做，还知道当前 Agent 被设计来做什么。
更有意思的是，作者通过分析误报和漏报样本，对白名单中的意图描述进行了一轮优化，便将 OOD 检出率从 83.3% 提升到 93.5%。这个过程并不需要重新训练护栏模型，只需要修改策略描述。
这对企业级安全产品很有参考价值。很多时候，业务安全效果的改善并不一定依赖模型能力升级，也可以通过策略优化来实现。
实验还发现，直接将黑名单叠加到白名单上，虽然可以进一步减少错误放行，却会将正常请求误拦率从 3.6% 提高到 8.2%，导致整体准确率下降。
当然，这并不能简单理解为黑名单没有价值。对于涉及金融交易、个人隐私等高风险业务，显式禁止规则仍然十分重要。实验真正说明的是，功能边界应当主要由允许的业务能力来定义，而不是仅靠枚举禁止事项反向推断。
Uber 如何把一套安全策略变成生产级系统？
如果说功能边界定义和语义白名单是 Persona Guardrail 的技术基础，那么策略管理与持续演进机制，则是这篇论文更值得企业借鉴的工程实践。
对于一个只有几个 Agent 的系统，人工维护策略并不困难。但当一个企业内部有数十个甚至上百个 Agent 时，情况就完全不同了。
不同 Agent 的功能会持续变化，新的工具会不断接入，用户的正常需求也会发生变化。同时，新的攻击手法和风险模式还可能影响多个 Agent。
这意味着，安全策略不能在 Agent 上线时配置一次就不再更新，而需要像软件版本一样持续管理。
Uber 为此设计了独立的策略管理体系。每个 Agent 的功能边界以版本化记录的形式维护在 Registry 中，底层使用 MySQL 存储。通用安全知识和常见攻击规则由平台集中管理，Agent 专属功能边界则由各自的业务团队维护。
这样，企业既能统一管理通用安全能力，又不需要强制所有 Agent 使用同一套业务策略。
在策略更新时，Uber 也没有采用模型直接修改线上规则的方式，而是建立了一套完整的发布流程。
首先，系统从历史误报、漏报、真实业务流量以及新增功能中发现需要调整的策略。随后生成新的候选版本，通过黄金测试集、对抗测试集和生产流量样本进行离线评测。只有满足预设指标，并经过人工审核的候选策略，才能进入影子运行和小范围灰度阶段。
其中，Shadow Mode（影子模式）尤其重要。新策略可以在真实业务请求上运行并记录判断结果，但不会真正影响用户，便于安全团队观察它与现有策略的差异。
如果新版本存在明显的误拦或漏放问题，系统可以放弃更新，并保留原有的有效版本。
而且，策略调整通过配置发布完成，不需要重新部署共享模型服务。这使企业可以在保持底层检测基础设施稳定的情况下，独立迭代不同 Agent 的安全规则。
这一设计延续了传统互联网风控系统中已经成熟的策略生命周期管理思路，只是将管理对象扩展到了 Agent 的功能边界。
Uber 还针对护栏的推理性能进行了优化。系统使用 Qwen3-30B-A3B 作为共享检测模型，通过 FP8 量化、vLLM、NVIDIA Dynamo 和 Prefix Cache 等技术降低推理延迟。
因为护栏只需要输出 allow 或 block 的分类结果，模型实际只生成一个决策 Token。结合大量可复用的策略前缀，系统在单加速卡、5～50 QPS 的测试条件下，将单次护栏模型调用的 P90 延迟控制在约 57～61 毫秒。
需要注意，这并不是完整 Agent 请求的端到端延迟，不包括应用层和网络开销。
论文还报告，Persona Guardrail 在真实生产环境中实现了低于 1% 的误拦率和低于 2% 的误放率。不过，作者没有公开这些生产指标的完整标注规模与统计细节，因此更适合将其视为部署经验，而不是可以直接迁移到所有企业的性能承诺。
从 Persona Guardrail 进一步延伸：企业可以如何落地？
从企业级 AI 安全产品的角度来看，Persona Guardrail 最大的启发，是可以把 Agent 的安全能力从一套通用检测接口，发展为一套可配置、可管理的专属安全策略体系。
我们可以进一步将其抽象为 Agent Safety Profile（智能体安全档案）。每个 Agent 在创建和上线时，都需要建立自己的安全档案，明确业务职责、可访问数据、允许操作以及对应的安全规则。
这套安全档案可以建立在企业统一安全基线之上。
第一层是企业统一安全基线，包含内容安全、隐私保护、提示注入检测和通用风险规则，由安全平台集中维护。
第二层是 Agent 专属功能策略，定义当前 Agent 可以处理哪些业务、哪些请求属于超范围操作，以及出现异常时应该拒绝还是转交其他 Agent。
第三层是动态授权与执行约束。即使某项操作属于 Agent 的正常职能，也必须进一步核实当前用户是否具备相应权限。例如，财务 Agent 可以执行转账，不代表任何员工都可以要求它向任意账户转账。
第四层是评测和运营体系。每个 Agent 的策略版本都应该具有相应的测试集、误拦率、误放率、变更记录与审计信息，并随着 Agent 能力变化持续更新。
这里有必要区分：前两层与 Uber 已经实现的 Persona Guardrail 思路高度相关，而第三层的工具授权和执行约束，是在论文现有能力基础上的进一步扩展。
Uber 当前的防护仍然集中在用户输入和最终输出两个阶段。对于间接提示注入、工具返回投毒、记忆污染、复杂多轮攻击，以及 Agent 执行过程中的未授权操作，论文并没有给出完整的端到端验证。
作者也将会话级功能边界约束和工具调用前验证列为未来工作方向。
另外，Persona Guardrail 当前的主要决策方式仍然是允许或拒绝，对于实际业务中经常出现的混合意图请求，还存在进一步完善的空间。例如，用户要求差旅 Agent 取消本人机票，同时查询其他员工的行程，理想情况下，系统应当可以拆分任务，允许正常操作而拒绝越权部分，而不是只能整段放行或整段拒绝。
从这个角度看，Persona Guardrail 为 Agent 的专属安全策略提供了一个基础框架，但更完整的企业方案，还需要与身份鉴别、访问控制、工具授权和执行轨迹审计相结合。
对企业 AI 安全建设的启示
回顾 Uber 的研究，可以发现论文采用的许多技术并不陌生。
语义意图识别、黑白名单、输入输出拦截、策略版本管理、影子测试与灰度发布，在传统内容安全和互联网风控领域都有相当成熟的实践。
Uber 的贡献并不是重新发明这些技术，而是将它们组织成了一套面向 Agent 的生产级功能边界防护体系，并通过实验和实际部署，验证了这种设计的可行性。
这一点对于企业具有现实意义。
随着 Agent 数量不断增加，企业面临的安全问题很可能不只是某个模型能否抵御提示注入，还包括如何管理不同 Agent 的职责边界，如何让业务团队自主配置策略，如何评估新增 Agent 的风险，以及如何确保安全策略能够跟随业务变化持续演进。
如果每增加一个 Agent，就需要重新训练或部署一套独立的安全模型，整体运维成本很快就会失控。相比之下，使用共享安全检测能力，为不同 Agent 维护独立策略，是一条更容易规模化的路径。
当然，传统内容安全里的场景化策略不能直接等同于 Agent 安全策略。因为内容平台主要管理信息的发布与传播，而 Agent 还具有调用工具和执行操作的能力。因此，Agent 专属风控最终必须从内容和意图检测，延伸到执行权限和任务过程约束。
这也是 Persona Guardrail 留给后续研究和产品实践的重要空间。
从传统内容安全的场景化策略，到 Agent 时代的 Persona Guardrail，我们看到的并不是一套全新安全技术取代旧体系，而是已有安全治理能力随着 AI 应用形态变化而不断扩展。
过去，不同业务需要不同的内容安全策略；未来，不同 Agent 同样需要拥有与其职能相匹配的安全边界。
当企业开始将 Agent 真正纳入业务系统，这种精细化、平台化的安全策略管理，可能会逐渐成为企业 AI 安全基础设施的重要组成部分。
声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
