Persona Guardrail: A Production-Grade Defense Framework for Agentic SystemsPersona Guardrail：面向智能体系统的生产级防御框架

We consider a generic architecture representative of modern production scale agentic AI systems. The system receives user requests in the form of natural-language instructions, structured inputs (e.g., JSON), or a combination of both. In addition to user-provided information, the frontend application may attach contextual metadata (e.g., user state, session information, or application-specific context) that assists the agent in decision making. Before reaching the agent, every incoming request is processed by the input Persona Guardrail, which validates the request against the agent’s functional boundaries and security policies. Persona Guardrail can block or send through the request to the agentic system, which comprises one or more large language models (LLMs), enterprise knowledge bases, retrieval components, internal and external tools, APIs, and other software services. During task execution, the agent may perform multiple reasoning steps and interact with these components to retrieve information, invoke tools, or execute actions before producing a final response. The generated response is subsequently processed by the output Persona Guardrail, which validates it against the agent’s intended functionality and security policies before it is returned to the user.我们考虑了一种代表现代生产规模智能体 AI 系统的通用架构。系统以自然语言指令、结构化输入（如 JSON）或两者结合的形式接收用户请求。除用户提供的信息外，前端应用程序还可能附加上下文元数据（如用户状态、会话信息或特定于应用程序的上下文），以辅助智能体进行决策。在到达智能体之前，每个传入请求都会由输入 Persona Guardrail 处理，该护栏根据智能体的功能边界和安全策略验证请求。Persona Guardrail 可以阻止或将请求发送至智能体系统，该系统包含一个或多个大语言模型（LLM）、企业知识库、检索组件、内部和外部工具、API 以及其他软件服务。在任务执行期间，智能体可能会执行多个推理步骤，并与这些组件交互以检索信息、调用工具或执行操作，然后产生最终响应。生成的响应随后由输出 Persona Guardrail 处理，该护栏在响应返回给用户之前，根据智能体的预期功能和安全策略对其进行验证。

We consider an adversarial setting in which an external malicious user has unrestricted query access to the agentic system and can observe all responses returned by the system. The adversary possesses general knowledge of the agent’s intended functionality, public interfaces, and expected behavior, but does not have access to the system’s internal state, including system prompts, intermediate reasoning, memory, tool interactions, orchestration logic, or communication between internal components. We assume the underlying LLMs, infrastructure, and trusted software components are uncompromised. Within this threat model, the adversary aims to manipulate the agent through carefully crafted inputs to achieve one or more of the following objectives:我们考虑了一种对抗性设定，其中外部恶意用户对智能体系统拥有不受限制的查询访问权限，并能观察系统返回的所有响应。攻击者具备关于智能体预期功能、公共接口和预期行为的一般知识，但无法访问系统的内部状态，包括系统提示词、中间推理、内存、工具交互、编排逻辑或内部组件之间的通信。我们假设底层大模型、基础设施和受信任的软件组件未被破坏。在此威胁模型内，攻击者的目标是通过精心设计的输入来操纵智能体，以实现以下一个或多个目标：

1. Instruction Manipulation and Prompt Extraction. The adversary attempts to extract confidential system prompts, reveal internal instructions or policies, or manipulate the agent into violating its intended behavior through attacks such as prompt injections.1. 指令操纵与提示词提取。攻击者试图提取机密系统提示词、泄露内部指令或策略，或通过提示词注入等攻击操纵智能体违反其预期行为。

2. Generation of Harmful or Policy-Violating Responses. The adversary seeks to induce the agent to produce responses or perform actions that violate organizational policies, safety requirements, or legal and regulatory constraints, potentially resulting in reputational, financial, or legal harm to the organization.2. 生成有害或违反策略的响应。攻击者寻求诱导智能体产生响应或执行违反组织策略、安全要求或法律法规约束的操作，可能导致组织声誉、财务或法律上的损害。

3. Functional Boundary Violation. The adversary attempts to cause the agent to operate outside its intended scope by eliciting responses or executing actions unrelated to its designated functionality. For example, an attacker may attempt to coerce a ride-booking assistant into providing medical advice or revealing internal operational information, thereby violating the agent’s predefined functional boundaries.3. 功能边界违规。攻击者试图通过诱导智能体执行与其指定功能无关的响应或操作，使其在预期范围之外运行。例如，攻击者可能试图强迫打车辅助智能体提供医疗建议或泄露内部运营信息，从而违反智能体预定义的功能边界。

Our objective is to design a defense framework that mitigates these attacks while preserving the utility, responsiveness, and intended functionality of the agent under normal user interactions.我们的目标是设计一个防御框架，在正常用户交互下保持智能体的效用、响应性和预期功能的同时，减轻这些攻击。

Persona Guardrail is designed to operate under the stringent latency requirements of production agentic systems. Both the input and output guardrails make blocking decisions—requests must be validated before agent execution, and responses must be validated before being returned to the end user. Hence, the guardrails cannot be executed asynchronously with the agent. As a result, the primary design objective is to achieve robust security while incurring only a small and predictable latency overhead that preserves the responsiveness required by production-scale deployments.Persona Guardrail 旨在在生产智能体系统严格的延迟要求下运行。输入和输出护栏均需做出阻止决策——请求必须在智能体执行前进行验证，响应必须在返回给终端用户前进行验证。因此，护栏无法与智能体异步执行。结果，主要设计目标是在实现稳健安全性的同时，仅产生较小且可预测的延迟开销，从而保持生产规模部署所需的响应性。

From a high-level perspective, an agentic guardrail can be viewed as a reasoning system that determines whether an input or output lies within the functional and security boundaries of an agent. A straightforward approach is to leverage a general-purpose LLM by providing it with a natural-language specification of the agent’s intended functionality, permissible actions, and security policies, and asking it to classify each interaction accordingly. While conceptually simple, this approach presents several practical challenges for production deployment.从高层视角来看，智能体护栏可以被视为一个推理系统，用于确定输入或输出是否处于智能体的功能和安全边界内。一种直接的方法是利用通用大模型，向其提供智能体预期功能、允许操作和安全策略的自然语言规范，并要求其相应地对每次交互进行分类。虽然概念上很简单，但这种方法在生产部署中存在几个实际挑战。

First, a comprehensive natural-language specification is difficult to construct and maintain as the underlying agent evolves. Production agents frequently undergo updates, including changes to prompts, tools, APIs, retrieval sources, and supported capabilities. Consequently, the guardrail specification must evolve alongside the agent to accurately reflect its intended behavior. Second, invoking a medium- or large-scale reasoning model for every request introduces significant latency. Since both the input and output guardrails operate synchronously on the critical execution path, their latency directly impacts end-to-end response time and user experience. Finally, a static guardrail is unlikely to remain effective in dynamic production environments where both adversarial attack strategies and legitimate user behavior continuously evolve.首先，随着底层智能体的演变，构建和维护综合的自然语言规范非常困难。生产智能体经常进行更新，包括提示词、工具、API、检索源和支持功能的更改。因此，护栏规范必须随智能体一起演变，以准确反映其预期行为。其次，为每个请求调用中大型推理模型会引入显著延迟。由于输入和输出护栏都在关键执行路径上同步运行，它们的延迟直接影响端到端响应时间和用户体验。最后，在对抗性攻击策略和合法用户行为不断演变的动态生产环境中，静态护栏不太可能保持有效。

These challenges raise several fundamental design questions. How can the functional and security specification of an agent be maintained as the system evolves? How should guardrail performance be measured, particularly in terms of false positive and false negative rates? How can production misclassifications be systematically incorporated to refine the guardrail over time? More broadly, how can a guardrail continuously adapt to emerging attack techniques and distribution shifts in user requests while maintaining low latency and high reliability?这些挑战提出了几个基本的设计问题。随着系统的演变，智能体的功能和安全规范应如何维护？护栏性能应如何衡量，特别是在误报率和漏报率方面？生产环境中的错误分类应如何系统地纳入以随时间改进护栏？更广泛地说，护栏如何在保持低延迟和高可靠性的同时，持续适应新兴的攻击技术和用户请求的分布偏移？

Existing defenses only partially address these challenges. Rule-based and policy-based guardrails (Rebedea et al., 2023; Inan et al., 2023) provide deterministic enforcement but are difficult to scale across heterogeneous agents and often fail to capture context-dependent or previously unseen attacks. Model-based guardrails (Microsoft, 2025; Jia et al., 2025) offer greater flexibility and generalization but typically rely on expensive reasoning models and have received relatively little attention regarding continuous adaptation, deployment at production-scale, or systematic evaluation under evolving workloads. More generally, recent systematization efforts (Kim et al., 2026) categorize existing defenses into runtime protection, secure-by-design mechanisms, and component hardening, while identifying the need for practical, adaptive defenses that can operate under real-world deployment constraints.现有的防御措施仅部分解决了这些挑战。基于规则和策略的护栏（Rebedea 等人，2023；Inan 等人，2023）提供了确定性的强制执行，但难以在异构智能体之间扩展，且往往无法捕捉上下文相关或以前未见的攻击。基于模型的护栏（Microsoft，2025；Jia 等人，2025）提供了更大的灵活性和泛化能力，但通常依赖昂贵的推理模型，且在持续适应、生产规模部署或在演变负载下的系统评估方面受到的关注相对较少。更广泛地说，近期的系统化工作（Kim 等人，2026）将现有防御归类为运行时保护、安全设计机制和组件强化，同时指出了在现实世界部署约束下运行的实用、自适应防御的需求。

Motivated by these challenges, we design Persona Guardrail as an adaptive, production-oriented runtime defense framework. Rather than relying solely on static rules or expensive reasoning, Persona Guardrail combines lightweight inference with a closed-loop feedback mechanism that continuously refines its functional and security boundaries using signals collected from production traffic. This design enables the framework to adapt to both emerging adversarial attack patterns and shifts in user behavior while satisfying the stringent latency and scalability requirements of production agentic systems.受这些挑战的驱动，我们将 Persona Guardrail 设计为一个自适应的、面向生产的运行时防御框架。Persona Guardrail 不仅依赖静态规则或昂贵的推理，而是将轻量级推理与闭环反馈机制相结合，利用从生产流量中收集的信号持续细化其功能和安全边界。这种设计使框架能够在满足生产智能体系统严格延迟和可扩展性要求的同时，适应新兴的对抗性攻击模式和用户行为的转变。

The central abstraction underlying Persona Guardrail is the functional boundary of an agent. Intuitively, the functional boundary characterizes the set of user interactions that are consistent with the agent’s intended functionality, security requirements, and product specifications.Persona Guardrail 的核心抽象是智能体的功能边界。直观地说，功能边界表征了与智能体预期功能、安全要求和产品规范一致的一组用户交互。

The input guardrail enforces the functional boundary before a request reaches the agentic system. Its objective is to determine whether an incoming user request should be processed by the agent or rejected. The input allowlist specifies the classes of user requests that fall within the intended capabilities of the agent, whereas the input blocklist captures malicious inputs, known adversarial attack patterns, and, optionally, out-of-domain requests that the agent is not designed to handle. To enforce the input functional boundary, we investigated four alternative architectures:输入护栏在请求到达智能体系统之前强制执行功能边界。其目标是确定传入的用户请求应由智能体处理还是被拒绝。输入允许列表指定了落在智能体预期能力范围内的用户请求类别，而输入阻止列表捕获恶意输入、已知的对抗攻击模式，以及（可选地）智能体未被设计处理的域外请求。为了强制执行输入功能边界，我们研究了四种替代架构：

We evaluated these architectures along four dimensions: classification performance, inference latency, operational complexity, and generalization across heterogeneous agents. The embedding-based approach provides the lowest inference latency but requires careful calibration of similarity thresholds and continuous maintenance of an embedding database containing representative allowlist and blocklist examples for every agent. As agents evolve, maintaining these examples becomes increasingly expensive, and the approach exhibits limited robustness to semantically novel requests. The fine-tuned classifier performs well when evaluated on agents represented in its training data. However, its performance degrades when deployed on previously unseen agents or when the functional boundary evolves, necessitating periodic retraining and increasing operational complexity. The hybrid architecture improves classification accuracy by combining fast retrieval with LLM reasoning, but introduces additional infrastructure complexity and requires maintaining both an embedding index and an LLM-based inference pipeline.我们从四个维度评估了这些架构：分类性能、推理延迟、运营复杂性和跨异构智能体的泛化能力。基于嵌入的方法提供最低的推理延迟，但需要仔细校准相似度阈值，并持续维护包含每个智能体代表性允许列表和阻止列表示例的嵌入数据库。随着智能体的演变，维护这些示例变得越来越昂贵，且该方法对语义新颖的查询表现出有限的稳健性。微调分类器在评估其训练数据中表示的智能体时表现良好。然而，当部署在以前未见的智能体上或功能边界演变时，其性能会下降，需要定期重新训练并增加运营复杂性。混合架构通过将快速检索与大模型推理相结合提高了分类准确率，但引入了额外的基础设施复杂性，并需要同时维护嵌入索引和大模型推理流水线。

Based on these trade-offs, we adopt an LLM-based classifier using Qwen3-30B-A3B (et al., 2025) as the input guardrail. We find that this approach offers the best overall trade-off across these dimensions: low operational complexity, low inference latency, strong classification performance, and generalization across diverse agentic systems. Moreover, because the functional boundary is represented semantically rather than as agent-specific examples, the same model can be deployed across multiple agents with minimal customization while adapting naturally to evolving boundary specifications.基于这些权衡，我们采用 Qwen3-30B-A3B（et al., 2025）作为输入护栏的基于大模型的分类器。我们发现这种方法在这些维度上提供了最佳的整体权衡：低运营复杂性、低推理延迟、强大的分类性能以及跨多样化智能体系统的泛化能力。此外，由于功能边界是语义表示而非智能体特定示例，同一个模型可以以最小的定制部署在多个智能体上，同时自然地适应演变的功能边界规范。

The output guardrail enforces the functional boundary before the agent’s response is returned to the user. Its objective is to verify that the generated response remains consistent with the agent’s intended functionality, organizational policies, and security requirements. The output allowlist specifies the expected characteristics and permissible actions of the agent’s responses, while the output blocklist captures prohibited behaviors, including policy violations, unsafe or harmful responses, disclosure of confidential information, hallucinated capabilities and other outputs that violate the agent’s functional or security boundaries.输出护栏在智能体的响应返回给用户之前强制执行功能边界。其目标是验证生成的响应是否与智能体的预期功能、组织策略和安全要求保持一致。输出允许列表指定了智能体响应的预期特征和允许操作，而输出阻止列表捕获禁止的行为，包括策略违规、不安全或有害的响应、机密信息的披露、幻觉能力以及其他违反智能体功能或安全边界的输出。

As with the input guardrail, we evaluated the same four architectures (embedding-based retrieval, LLM-based classification, hybrid retrieval–LLM, and a fine-tuned classifier). We adopt the same LLM-based classifier (Qwen3-30B-A3B) (et al., 2025) for output enforcement, as it provides the best balance between inference latency, deployment simplicity, and generalization across diverse agents. Furthermore, using a common classification model for both input and output enforcement simplifies deployment and maintenance while enabling a consistent semantic interpretation of the functional boundary throughout the agent execution pipeline. The output guardrail serves as the final enforcement point before the response reaches the end user and may block a policy-violating response even when an attack has influenced the agent.与输入护栏一样，我们评估了相同的四种架构（基于嵌入的检索、基于大模型的分类、检索-大模型混合和微调分类器）。我们采用相同的大模型分类器（Qwen3-30B-A3B）（et al., 2025）进行输出强制执行，因为它在推理延迟、部署简单性和跨多样化智能体的泛化能力之间提供了最佳平衡。此外，在输入和输出强制执行中使用通用的分类模型简化了部署和维护，同时实现了在整个智能体执行流水线中对功能边界的一致语义解释。输出护栏作为响应到达终端用户之前的最终强制执行点，即使在攻击已经影响智能体的情况下，也可能阻止违反策略的响应。

Model selection for Persona Guardrail is driven by both guardrail performance and production latency. To ensure a responsive user experience, we require the model’s end-to-end P90 inference latency. This requirement restricts the set of models that can be practically deployed.Persona Guardrail 的模型选择由护栏性能和生产延迟共同驱动。为确保响应迅速的用户体验，我们需要模型端到端的 P90 推理延迟。这一要求限制了可以实际部署的模型集。

We initially experimented with both closed- and open-weight models. Closed models, including models served through OpenAI and Anthropic APIs, require requests to be sent to externally hosted inference endpoints. In our experiments, the resulting network and serving overhead prevented these models from consistently satisfying our sub-100 ms latency requirement. We therefore focused on open-weight models that could be deployed within our own serving infrastructure, allowing us to control inference placement, caching, hardware configuration, and other serving optimizations.我们最初试验了闭源和开源权重模型。闭源模型（包括通过 OpenAI 和 Anthropic API 服务的模型）要求将请求发送到外部托管的推理端点。在我们的实验中，由此产生的网络和服务开销使这些模型无法持续满足我们 100 毫秒以下的延迟要求。因此，我们专注于可以在我们自己的服务基础设施内部署的开源权重模型，这使我们能够控制推理位置、缓存、硬件配置和其他服务优化。

Among locally deployable models, we evaluated Qwen2.5-3B, Qwen2.5-7B, Qwen3-8B, and Qwen3-30B-A3B. We additionally evaluated Qwen3-VL-30B as a higher-capacity alternative. Each model was evaluated on the same sets of benign, out-of-domain (OOD), and adversarial queries for a representative production agent. The benign evaluation contains three subsets representing different production traffic distributions: most-frequent queries, randomly sampled queries, and an extensive benign set. For OOD and adversarial datssets, we report the percentage of queries incorrectly approved; therefore, lower values indicate stronger rejection. Table 2 summarizes the results.在本地可部署的模型中，我们评估了 Qwen2.5-3B、Qwen2.5-7B、Qwen3-8B 和 Qwen3-30B-A3B。我们还评估了 Qwen3-VL-30B 作为更高容量的替代方案。每个模型都在针对代表性生产智能体的相同良性、域外（OOD）和对抗性查询集上进行了评估。良性评估包含三个子集，代表不同的生产流量分布：最频繁查询、随机采样查询和广泛的良性集。对于 OOD 和对抗性数据集，我们报告错误通过的查询百分比；因此，较低的值表示更强的拒绝能力。表 2 总结了结果。

The results expose an important trade-off between benign utility, security, and latency. The smaller models can achieve competitive rejection rates on OOD and adversarial requests, but at the cost of substantially higher false blocking of legitimate traffic. For example, Qwen2.5-3B has the lowest median latency (81 ms) and approves only 18% of targeted adversarial requests, but approves just 49–67% of the benign evaluation sets. Qwen2.5-7B and Qwen3-8B improve benign utility, but still approve only 77–93% of benign requests and exhibit median latencies of 168 ms and 170 ms, respectively.结果揭示了良性效用、安全性和延迟之间的重要权衡。较小的模型可以在 OOD 和对抗性请求上实现有竞争力的拒绝率，但代价是大幅增加了对合法流量的错误阻止。例如，Qwen2.5-3B 具有最低的中位数延迟（81 毫秒），仅批准了 18% 的针对性对抗请求，但仅批准了 49–67% 的良性评估集。Qwen2.5-7B 和 Qwen3-8B 改善了良性效用，但仍仅批准 77–93% 的良性请求，且中位数延迟分别为 168 毫秒和 170 毫秒。

Qwen3-30B-A3B provides a substantially better utility-latency trade-off. It approves 99–100% of benign requests across all three benign evaluation sets while maintaining a median inference latency of 95 ms. Although some smaller models achieve lower false-approval rates on individual OOD or adversarial sets, their substantially higher benign false-block rates make them unsuitable for our production setting, where both security and preservation of legitimate agent functionality are important.Qwen3-30B-A3B 提供了显著更好的效用-延迟权衡。它在所有三个良性评估集中批准了 99–100% 的良性请求，同时保持了 95 毫秒的中位数推理延迟。尽管一些较小的模型在个别 OOD 或对抗性集上实现了更低的错误通过率，但它们大幅更高的良性错误阻止率使它们不适合我们的生产环境，在生产环境中，安全性和保持合法智能体功能都非常重要。

Qwen3-VL-30B provides the closest benign classification performance, approving 96–99% of legitimate requests, and achieves lower false-approval rates than Qwen3-30B-A3B on the evaluated OOD and adversarial sets. However, its median inference latency is 150 ms, exceeding our latency target. In contrast, Qwen3-30B-A3B uses a mixture-of-experts architecture with approximately 30B total parameters while activating only approximately 3B parameters per token. This architecture provides sufficient model capacity for semantic functional-boundary classification while keeping inference cost compatible with synchronous guardrail enforcement.Qwen3-VL-30B 提供了最接近的良性分类性能，批准了 96–99% 的合法请求，并且在评估的 OOD 和对抗性集上实现了比 Qwen3-30B-A3B 更低的错误通过率。然而，其中位数推理延迟为 150 毫秒，超过了我们的延迟目标。相比之下，Qwen3-30B-A3B 使用混合专家架构，总参数约为 30B，但每个标记仅激活约 3B 参数。这种架构为语义功能边界分类提供了足够的模型容量，同时使推理成本与同步护栏强制执行兼容。

Based on these results, we select Qwen3-30B-A3B as the shared classifier for both the input and output Persona Guardrails. Among the evaluated models, it provides the best overall trade-off between preserving benign utility, rejecting functional-boundary violations, and satisfying the production latency constraint. Using the same model for both guardrails also simplifies serving and maintenance and allows agent-specific behavior to be expressed through functional-boundary specifications rather than separate model deployments.基于这些结果，我们选择 Qwen3-30B-A3B 作为输入和输出 Persona Guardrail 的共享分类器。在评估的模型中，它在保持良性效用、拒绝功能边界违规和满足生产延迟约束之间提供了最佳的整体权衡。为两个护栏使用相同的模型也简化了服务和维护，并允许通过功能边界规范而非单独的模型部署来表达智能体特定的行为。

Existing public agent benchmarks are designed to measure task utility, harmful behavior, or robustness against specific attacks, such as indirect prompt injection, and therefore do not provide the labels a persona guardrail needs: whether a user turn (before the agent acts) or an agent turn (before a response is returned) falls inside or outside the agent’s declared functional boundary. To evaluate Persona Guardrail under its intended malicious-user threat model, we construct PAGE (Persona-Aware Guardrail Evaluation), a purpose-built benchmark in which every message is (i) attributed to one of the four AgentDojo personas, (ii) tagged with the turn on which the guardrail fires (pre-app/user or post-app/agent), and (iii) labelled with a request kind—benign, adversarial, out-of-domain (OOD), or mixed. Every label is grounded in the same natural-language allowlist that instantiates the guardrail, so the dataset and the enforced policy share a single source of truth. In total, PAGE comprises $2{,}180$ labelled messages ($2{,}076$ synthesized around the four personas plus $104$ projected from AgentHarm  (Andriushchenko et al., 2025)) and is, to our knowledge, the first guardrail benchmark that jointly covers user and agent turns across four production domains with benign, out-of-domain, and adversarial intents. We release it to support reproducible evaluation of functional-boundary enforcement.现有的公共智能体基准测试旨在衡量任务效用、有害行为或针对特定攻击（如间接提示词注入）的鲁棒性，因此无法提供个人防护栏（persona guardrail）所需的标签：即用户轮次（在智能体执行动作前）或智能体轮次（在返回响应前）是否处于智能体声明的功能边界之内。为了在预期的恶意用户威胁模型下评估个人防护栏，我们构建了 PAGE（Persona-Aware Guardrail Evaluation），这是一个专门构建的基准测试，其中每条消息都 (i) 归属于四个 AgentDojo 人设之一，(ii) 标记了防护栏触发的轮次（应用前/用户轮次或应用后/智能体轮次），以及 (iii) 标记了请求类型——良性、对抗性、域外 (OOD) 或混合。每个标签都基于实例化防护栏的相同自然语言白名单，因此数据集和执行的策略共享单一的事实来源。PAGE 总共包含 2,180 条标记消息（2,076 条围绕四个人设合成，外加 104 条从 AgentHarm (Andriushchenko et al., 2025) 投影而来），据我们所知，这是第一个联合覆盖四个生产领域中用户和智能体轮次，且包含良性、域外和对抗性意图的防护栏基准测试。我们发布它是为了支持功能边界执行的可重复评估。

We study a progression of configurations of increasing specificity, all evaluated on the same PAGE splits:我们研究了一系列特异性逐渐增加的配置，所有配置均在相同的 PAGE 分割上进行评估：

The last two configurations are exploratory: whether an explicit blocklist improves over the iterated allowlist is an empirical question, and we let the measured results (Section 4.3) determine the narrative.最后两个配置是探索性的：显式黑名单是否比迭代白名单更好是一个经验性问题，我们让测量结果（第 4.3 节）来决定结论。

Table 6 reports aggregate performance across configurations and Table 9 the underlying decision counts. The comparison isolates the value of the functional boundary. The baseline judge—given only a generic agent description—attains reasonable adversarial detection ($92.6\%$) but cannot enforce a functional boundary: it catches only $57.3\%$ of out-of-domain turns, giving a $25.0\%$ false-approved rate and $85.7\%$ accuracy. Introducing the persona allowlist raises out-of-domain detection to $83.3\%$ and cuts the false-approved rate to $9.9\%$; the single iteration pass—driven entirely by inspecting the false-approved and false-blocked turns—raises out-of-domain detection further to $93.5\%$ and reduces the false-approved rate to $4.7\%$, lifting accuracy to $95.9\%$; a second refinement pass and a held-out, multi-split validation of this iterative gain are reported in Appendix A (Table 12). Crucially, the benign false-blocked rate stays essentially constant across all three configurations ($\approx 3.7\%$), so these security gains do not cost utility.表 6 报告了各配置的汇总性能，表 9 报告了底层的决策计数。该比较隔离了功能边界的价值。基线裁判（仅给定通用智能体描述）获得了合理的对抗性检测率（92.6%），但无法执行功能边界：它仅捕获了 57.3% 的域外轮次，导致 25.0% 的错误批准率和 85.7% 的准确率。引入人设白名单将域外检测率提高到 83.3%，并将错误批准率降低到 9.9%；单次迭代过程（完全由检查错误批准和错误拦截轮次驱动）将域外检测率进一步提高到 93.5%，并将错误批准率降低到 4.7%，将准确率提升至 95.9%；第二次精炼过程以及对此迭代增益进行的留出多分割验证在附录 A（表 12）中报告。至关重要的是，良性错误拦截率在所有三个配置中基本保持不变（≈3.7%），因此这些安全收益并未以牺牲效用为代价。

The blocklist-only and allowlist+blocklist configurations settle whether an explicit blocklist helps. A blocklist alone is far weaker: it reaches only $71.2\%$ accuracy because, although it catches $87.2\%$ of adversarial turns, it flags just $14.5\%$ of out-of-domain requests—a blocklist enumerates attacks, not the agent’s function, so it cannot recognise a competent request that merely falls outside scope (a $49.0\%$ false-approved rate). Adding the blocklist on top of the allowlist does not improve on the allowlist alone: raw detection edges up, but the benign false-blocked rate roughly doubles ($3.6\%\to 8.2\%$) and overall accuracy slips ($95.9\%\to 94.9\%$). The iterated allowlist thus remains the strongest configuration: the allowlist is both necessary and sufficient to enforce the functional boundary, and a blocklist neither substitutes for it nor usefully complements it.仅黑名单和白名单+黑名单配置确定了显式黑名单是否有帮助。仅黑名单的效果要弱得多：它仅达到 71.2% 的准确率，因为尽管它捕获了 87.2% 的对抗性轮次，但它仅标记了 14.5% 的域外请求——黑名单枚举的是攻击，而不是智能体的功能，因此它无法识别仅仅超出范围的能力范围内的请求（49.0% 的错误批准率）。在白名单之上添加黑名单并不能改善仅白名单的情况：原始检测率略有上升，但良性错误拦截率大约翻了一番（3.6%→8.2%），整体准确率下滑（95.9%→94.9%）。因此，迭代白名单仍然是最强的配置：白名单对于执行功能边界既是必要的也是充分的，而黑名单既不能替代它，也不能有效地补充它。

Table 7 decomposes performance by request label, and Table in Appendix A breaks the strongest configuration (iterated allowlist) down by agent. Two observations stand out. First, adversarial detection is high for every allowlist configuration ($\geq 96.8\%$), and even the description-only baseline and the generic blocklist catch most overt attacks ($92.6\%$ and $87.2\%$): explicit attacks are the easy case. Second, out-of-domain detection is where the functional boundary matters most—it climbs from $57.3\%$ (baseline) to $83.3\%$ (allowlist) to $93.5\%$ (iterated), whereas the blocklist manages only $14.5\%$, confirming that identifying competent-but-out-of-scope requests—not attack coverage—is the hard part of the problem, and that only an allowlist addresses it. Per agent, the lower Slack and Workspace OOD rates reflect the difficulty of the fluent, task-like cross-persona OOD cases described in Section 4.1.3.表 7 按请求标签分解了性能，附录 A 中的表按智能体分解了最强配置（迭代白名单）。两个观察结果非常突出。首先，每个白名单配置的对抗性检测率都很高（≥96.8%），即使是仅描述的基线和通用黑名单也能捕获大多数明显的攻击（92.6% 和 87.2%）：显式攻击是容易的情况。其次，域外检测是功能边界最重要的地方——它从 57.3%（基线）上升到 83.3%（白名单）再到 93.5%（迭代），而黑名单仅达到 14.5%，这证实了识别能力范围之内但超出范围的请求（而不是攻击覆盖）是问题的难点，且只有白名单能解决它。按智能体来看，Slack 和 Workspace 较低的 OOD 率反映了第 4.1.3 节中描述的流畅、任务式跨人设 OOD 案例的难度。

The experiments above use the three-label setting (benign, adversarial, out-of-domain). We additionally study mixed turns—turns that combine a valid in-scope request with an out-of-scope or adversarial rider—which raise a labelling question: should a turn that contains some legitimate intent be approved (allowlist-presence semantics) or blocked (because it also carries off-policy content)? We evaluate both labelling policies against the no-mixed setting on the iterated-allowlist configuration (Table 8).上述实验使用三标签设置（良性、对抗性、域外）。我们额外研究了混合轮次——结合了有效的范围内请求和范围外或对抗性附加指令的轮次——这提出了一个标记问题：包含某些合法意图的轮次应该被批准（白名单存在语义）还是被拦截（因为它也携带了策略外内容）？我们在迭代白名单配置上针对无混合设置评估了这两种标记策略（表 8）。

The guardrail blocks $92.2\%$ of mixed turns in both policies (its predictions do not depend on the label). Consequently, scoring mixed turns as should-approve inflates the false-blocked rate to $17.1\%$ and drops accuracy to $88.6\%$, whereas scoring them as should-block keeps accuracy at $95.6\%$ with a $3.6\%$ false-blocked rate. In other words, the guardrail behaves as if a mixed turn is off-policy, which is consistent with a strict functional boundary that rejects any turn carrying a disallowed component.防护栏在两种策略中都拦截了 92.2% 的混合轮次（其预测不依赖于标签）。因此，将混合轮次评分为“应批准”会将错误拦截率提高到 17.1% 并将准确率降至 88.6%，而将其评分为“应拦截”则使准确率保持在 95.6%，错误拦截率为 3.6%。换句话说，防护栏的表现就像混合轮次是策略外的一样，这与拒绝任何携带违规组件的轮次的严格功能边界是一致的。

The guardrail model—a 30B-parameter Qwen3 mixture-of-experts model that activates approximately 3B parameters per token and is quantized to FP8—is served with vLLM on NVIDIA Dynamo. Inference is disaggregated into a CPU frontend and GPU workers: a prefix-cache-aware router dispatches each request to a worker, which performs the model inference on a dedicated accelerator. The frontend and worker pools scale independently (Figure 3 in the Appendix).防护栏模型——一个 30B 参数的 Qwen3 混合专家模型，每个 token 激活约 3B 参数，并量化为 FP8——在 NVIDIA Dynamo 上使用 vLLM 提供服务。推理被分解为 CPU 前端和 GPU 工作节点：一个感知前缀缓存的路由器将每个请求分派给工作节点，由其在专用加速器上执行模型推理。前端和工作节点池独立扩展（附录中的图 3）。

Because the guardrail lies on the critical path of every interaction, the serving infrastructure is optimized for predictable latency and high availability. The model context length is capped to bound the per-request KV-cache footprint and worst-case inference latency. Workers register with a per-region discovery mechanism, and requests are routed only to healthy workers in the same region. Individual worker failures therefore reduce local capacity without interrupting the remaining workers, while regional isolation contains region-wide failures and permits application-level failover.由于防护栏位于每次交互的关键路径上，服务基础设施针对可预测的延迟和高可用性进行了优化。模型上下文长度被限制，以约束每个请求的 KV 缓存占用空间和最坏情况下的推理延迟。工作节点在区域级发现机制中注册，请求仅路由到同一区域内的健康工作节点。因此，单个工作节点的故障会减少本地容量，而不会中断其余工作节点，而区域隔离则控制了区域范围的故障并允许应用级故障转移。

Because a guardrail runs on every request and response, its latency is judged not in isolation but against a transparency budget: it may consume only a small fraction of the host application’s end-to-end processing time before users perceive it. We express this budget as a fixed fraction of application latency, yielding a sub-100 ms P90 target for each guardrail model call.由于防护栏在每个请求和响应上运行，其延迟不是孤立判断的，而是根据透明度预算进行衡量：在用户感知到之前，它只能消耗主机应用端到端处理时间的一小部分。我们将此预算表示为应用延迟的固定比例，从而为每个防护栏模型调用产生低于 100 ms 的 P90 目标。

Meeting this target is made tractable by three properties of the guardrail workload.通过防护栏工作负载的三个属性，实现这一目标变得可行。

Beyond exploiting workload structure, we reduce per-call cost through model selection rather than compression alone. A mixture-of-experts model with only a few billion active parameters, served in FP8, provides the capacity of a larger model at the inference cost of a substantially smaller one. Together, disaggregated serving, prefix-cache reuse, bounded contexts, and one-token output target the prefill-dominated structure of the workload rather than generic token-generation speed.除了利用工作负载结构外，我们还通过模型选择而非单纯的压缩来降低每次调用的成本。一个仅有几十亿激活参数、以 FP8 提供服务的混合专家模型，以大幅减小的推理成本提供了较大模型的容量。总之，分解式服务、前缀缓存重用、有限上下文和单 token 输出，针对的是工作负载以预填充为主的结构，而不是通用的 token 生成速度。

Under this design, the guardrail sustains its latency budget across the tested operating range (Figure 1). Between 5 and 50 QPS, median latency ranges from 19.43 to 25.34 ms and P90 latency from 57.30 to 61.08 ms. P99 increases from 76.77 ms at 5 QPS to 104.15 ms at 50 QPS, crossing the 100 ms objective at 30 QPS. These measurements are single-accelerator model-call latencies with a 4,096-token context cap; they do not include application or network overhead. Accelerator utilization remains below 65% over this range. Relative to the prior general-purpose serving stack, the disaggregated design reduces guardrail-call latency by approximately 30%.在这种设计下，防护栏在测试的操作范围内保持了其延迟预算（图 1）。在 5 到 50 QPS 之间，中位数延迟范围为 19.43 到 25.34 ms，P90 延迟为 57.30 到 61.08 ms。P99 从 5 QPS 时的 76.77 ms 增加到 50 QPS 时的 104.15 ms，在 30 QPS 时超过了 100 ms 的目标。这些测量是具有 4,096 token 上下文上限的单加速器模型调用延迟；它们不包括应用或网络开销。在此范围内，加速器利用率保持在 65% 以下。相对于之前的通用服务栈，分解式设计将防护栏调用延迟降低了约 30%。

Guardrail failures are frequently semantic rather than deterministic, so infrastructure health alone is insufficient. Persona Guardrail records telemetry for every processed interaction, including the decision, agent identifier, evaluated boundary, policy version, inference latency, and final outcome. Agent-level monitoring tracks allow and block rates and latency distributions, while operational monitoring measures throughput, resource utilization, availability, context-limit rejection, and end-to-end latency.防护栏故障通常是语义上的而非确定性的，因此仅基础设施健康是不够的。个人防护栏记录每次处理交互的遥测数据，包括决策、智能体标识符、评估边界、策略版本、推理延迟和最终结果。智能体级监控跟踪允许和拦截率以及延迟分布，而操作监控测量吞吐量、资源利用率、可用性、上下文限制拒绝和端到端延迟。

Allow and block rates, together with disagreements between shadow and active policies, identify examples for investigation but are not themselves estimates of false-positive or false-negative rates. Such rates require examples with known labels or independently adjudicated samples. This distinction prevents agreement with the active policy from being mistaken for ground truth.允许和拦截率，连同影子策略与活动策略之间的分歧，确定了供调查的示例，但它们本身并不是假阳性或假阴性率的估计。这些比率需要带有已知标签或经过独立裁决的样本的示例。这种区分防止了与活动策略的一致被误认为是事实真相。

Routine metrics contain identifiers and aggregate measurements rather than raw prompts, responses, or intent lists. Content retained for debugging or refinement is sampled, minimized or redacted, access-controlled, and deleted according to a bounded retention policy. These monitoring signals support the continuous guardrail evolution framework described in Section 5.5.常规指标包含标识符和汇总测量值，而不是原始提示词、响应或意图列表。保留用于调试或精炼的内容会被采样、最小化或脱敏、访问控制，并根据有限的保留策略进行删除。这些监控信号支持第 5.5 节中描述的持续防护栏演进框架。

Unlike static security policies, guardrail specifications evolve as agent capabilities and attack techniques change. Persona Guardrail maintains an independent policy for each deployed agent, containing allowed and blocked intents for both user requests and agent responses. The same classifier can serve multiple agents, but each evaluation uses the intent lists associated with the current agent and interaction boundary. Candidate updates must satisfy predefined thresholds on security effectiveness, utility, reliability, and latency before deployment.与静态安全策略不同，防护栏规范会随着智能体能力和攻击技术的变化而演变。个人防护栏为每个部署的智能体维护一个独立的策略，包含用户请求和智能体响应的允许和禁止意图。同一个分类器可以服务多个智能体，但每次评估都使用与当前智能体和交互边界相关联的意图列表。候选更新在部署前必须满足预定义的安全性有效性、效用、可靠性和延迟阈值。

Operationally, the editable intent taxonomy is separated from the policy enforced in production. Applying a persona to a policy copies its four intent lists into a deployment snapshot; later edits to the source persona do not affect that snapshot. A persona used by a shadow or active policy is not edited in place. Instead, it is cloned, the clone is refined, and the resulting candidate proceeds through offline evaluation, review, and rollout. Thus, each iteration creates an explicit candidate while the currently active allowlist remains unchanged.在操作上，可编辑的意图分类法与生产中执行的策略是分离的。将人设应用于策略会将它的四个意图列表复制到部署快照中；随后对源人设的编辑不会影响该快照。影子或活动策略使用的人设不会在原处进行编辑。相反，它会被克隆，克隆版本会被精炼，生成的候选版本会通过离线评估、审查和发布流程。因此，每次迭代都会创建一个明确的候选版本，而当前活动的白名单保持不变。

To reduce overfitting to a fixed benchmark, offline evaluation uses three complementary pools: a golden set of curated, unambiguous behaviors that acts as a regression floor; an adversarial set of prompt injections, jailbreaks, and difficult boundary cases; and a production set sampled from live traffic. Examples used to motivate a refinement are kept separate from the held-out examples used to validate it. A candidate is accepted only if it satisfies the predefined thresholds across all three pools.为了减少对固定基准测试的过拟合，离线评估使用三个互补池：一组作为回归底线的精选、无歧义行为的黄金集；一组提示词注入、越狱和困难边界案例的对抗性集；以及一组从实时流量中采样的生产集。用于激励精炼的示例与用于验证它的留出示例是分开的。只有当候选版本在所有三个池中都满足预定义阈值时，才会被接受。

Once approved, the candidate snapshot is distributed as declarative configuration rather than as a serving-code deployment. This allows per-agent policies to be promoted independently without redeploying the shared model-serving stack. Every production activation is gated by independent human review.一旦批准，候选快照将作为声明性配置分发，而不是作为服务代码部署。这允许每个智能体的策略在不重新部署共享模型服务栈的情况下独立提升。每次生产激活都由独立的人工审查进行门控。

New policies are initially deployed in shadow mode, where they evaluate sampled production traffic without affecting user-visible decisions. Their predictions are compared with those of the active policy to identify disagreements for analysis. A candidate that passes shadow evaluation is introduced through a limited enforcing rollout before becoming active. The same snapshot is used throughout these stages. If a regression is detected, the rollout is stopped and the previously active snapshot remains in effect or is restored.新策略最初以影子模式部署，它们评估采样的生产流量而不影响用户可见的决策。它们的预测与活动策略的预测进行比较，以识别分歧进行分析。通过影子评估的候选版本在成为活动状态之前，会通过有限的强制发布引入。在这些阶段中都使用相同的快照。如果检测到回归，发布将停止，之前活动的快照将保持有效或被恢复。