是Application指挥，还是NeMo Guardrails指挥？LLM安全编排中的职责分离

在设计LLM服务时，很快就会遇到这样的问题：从用户输入到RAG检索、护栏、LLM调用、工具执行，再到最终响应，是否都应该由Application来指挥？还是应该以NeMo Guardrails为中心，Application只负责前后两端？

首先说结论，这不是将其中一个定为唯一中心的问题。Application或可信API层是安全和业务控制的中心，而NeMo Guardrails Runtime是LLM处理管道的中心。Application负责认证、授权、租户边界、业务权限、最终批准和审计跟踪。NeMo根据配置协调Input Rail、Retrieval Rail、Dialog Rail、Execution Rail、LLM调用和Output Rail。

因此，“所有网络请求都必须由单个Application进程直接中继”这一说法并非OWASP、Microsoft或NVIDIA的单一官方原则。它是通过结合最小权限、完全中介（Complete Mediation）、可信服务层、数据访问API封装等原则而得出的推荐设计方案之一。重要的是，并非所有数据包都物理上通过同一个进程，而是在访问受保护数据和功能的所有路径上，相同的权限策略是否得到无遗漏的执行。

Application安全控制区域与NeMo Guardrails LLM处理管道职责分离并连接的结构

首先明确术语

本文中使用的四个术语如下：

RAG (Retrieval-Augmented Generation)：一种方法，首先检索与用户问题相关的外部文档，然后将这些文档片段作为参考资料放入LLM提示中以生成答案。
Rail：NeMo Guardrails中应用于请求处理特定阶段的可编程策略和流程。它们可以阻止输入、转换检索结果、控制工具执行以及检查模型输出。
Tenant Filter：在多租户环境中，限制数据检索仅限于当前用户所属租户及其权限范围内的数据的条件。这不仅仅是比较单个tenant_id，还可以同时应用文档等级、用户角色、所有权等安全过滤器。
Presidio：一个用于检测和匿名化文本中PII（Personally Identifiable Information，个人身份信息），如姓名、电话号码、电子邮件的引擎。它不是指挥整个LLM管道的编排器。

在此，认证（Authentication）是确认“你是谁”的过程，而授权（Authorization）是判断“该用户是否可以使用此数据或功能”的过程。护栏执行允许的LLM行为和内容策略，但不应代替用户判断最终的业务权限。

Hub-and-Spoke应分为两种含义

“以Application为中心的Hub-and-Spoke是安全的”这一说法经常被使用，但必须明确“中心”指的是什么。

1. 以网络代理为中心的Hub

所有浏览器、NeMo、检索系统、LLM和工具之间的通信都由一个Application进程直接中继的结构。优点是路径简单，易于集中日志记录。缺点是处理量增加时可能出现瓶颈，并在发生故障时成为导致整个服务停止的单点故障。如果Application代码承担了认证、检索、提示组装、护栏和工具控制等所有职责，则变更影响范围也会扩大。

2. 以安全控制为中心的Hub

所有访问受保护数据和功能的路径都必须经过可信的访问控制机制的结构。这种机制可能是一个单一的单体Application，也可能分解为API Gateway、认证服务、Retrieval API、策略决策和执行点。核心是一致的策略路径，不可绕过，而非单一进程。

本文推荐第二种含义的Hub。网络拓扑可以分散，但认证、授权和租户边界必须在Application拥有的信任域中一致地执行。

OWASP是否推荐以Application为中心的结构？

准确地说，OWASP不指定特定的产品部署，而是提出关于访问控制和代理权限的安全原则。

OWASP LLM06:2025 Excessive Agency

OWASP LLM06:2025 Excessive Agency解释说，当基于LLM的系统具有过多的功能、过多的权限和过多的自主性时，可能会执行危险操作。主要缓解措施如下：

最小化LLM可以调用的扩展功能及其范围。
提供目的狭窄的工具，而不是像执行shell命令那样的通用工具。
最小化连接到下游系统的工具的权限。
代表用户执行的操作应以该用户的安全上下文和最小权限运行。
对影响重大的操作要求人工批准。
应用Complete Mediation，通过安全策略验证所有发往下游系统的请求。
不要让LLM决定是否允许操作，而应由下游系统强制执行授权。

此原则与“Application直接代理所有网络请求”的说法不同。例如，即使NeMo的Custom Action调用Retrieval API，如果Retrieval API以经过验证的用户上下文再次确认权限，则可以满足Complete Mediation。反之，即使所有流量都经过Application，如果Application以高权限的公共账户查询Vector DB，则可能违反用户上下文和最小权限原则。

OWASP ASVS 4.0

OWASP ASVS 4.0的架构要求要求在可信的执行点应用访问控制，并对受保护的数据和资源使用单一且经过充分验证的访问控制机制。V4 Access Control也要求在可信的服务层而非可绕过的客户端执行访问控制规则并应用最小权限。

这里ASVS所说的“trusted service layer”并非仅指一个传统的服务器进程。ASVS 4.0文档广泛描述了访问控制网关、服务器、无服务器函数、微服务等可信的执行点。因此，将ASVS的“single mechanism”解释为“所有请求都必须通过相同的Application二进制文件”是过度的。更准确的解释是不要创建权限判断被复制或绕过的替代路径。

Microsoft的多租户RAG设计所言

Microsoft的安全多租户RAG架构描述了用户向智能Application发送请求，Identity Provider认证用户，Application将用户查询和权限令牌传递给Orchestrator API的流程。Orchestrator获取相关证据数据并传递给模型。

在多租户环境中，文档特别强调以下几点：

用户身份应沿请求链传递到Orchestrator和数据存储。
查询共享存储时，必须在查询条件中包含租户标识符。
应应用过滤或安全修剪，以确保用户只能看到允许的文档。
建议在存储前设置API层，以封装租户路由、用户身份使用、安全过滤器和访问日志。
访问租户数据的代码不应直接查询后端存储，而应通过此API层。

这里的“所有请求”是在访问租户数据存储的上下文中。Microsoft文档不要求将整个LLM系统的所有通信都通过一个Application进程进行代理。相反，它将智能Application、Identity Provider、Orchestrator、数据访问API、存储和基础模型表示为独立的组件。

也就是说，Microsoft推荐的中心不是单体Application，而是封装了租户数据权限逻辑的数据访问API，这种解释更为准确。

NVIDIA NeMo Guardrails的官方架构

NVIDIA NeMo Guardrails Architecture Overview解释说，NeMo Guardrails位于Application和LLM·Tool·Retrieval System之间。Application通过Python SDK或Guardrails Server发送消息并接收最终响应。Runtime读取配置、处理事件，并协调Rail、Custom Action、Retrieval和LLM请求。

NVIDIA文档的配置关系简化如下：Application调用NeMo Runtime这一单一的Guardrails接口，Runtime作为Hub协调各个Rail和外部LLM·检索·Tool。

Application调用NeMo Runtime，NeMo协调Rail和外部系统的Hub-and-Spoke结构

图1. 基于NVIDIA官方架构说明重新构建的Hub-and-Spoke配置图。NeMo Runtime是Hub，Rail和外部系统是逻辑上的Spoke。Rail不是独立的网络服务，而是Runtime执行的内部策略阶段，线条表示协调关系而非物理通信路径。官方文档

配置图和请求顺序应区分阅读。官方文档描述的通用评估顺序是Input → Retrieval → Dialog → Execution → Output Rail，但Runtime是事件驱动的，因此根据配置和对话流程，检索、Custom Action和LLM调用的时机可能会有所不同。

各Rail的作用如下：

Input Rail：在调用Application LLM之前，允许、修改或拒绝用户消息。
Retrieval Rail：在将从知识库或外部检索到的原始文本块放入提示之前进行过滤或转换。
Dialog Rail：使用Colang Flow和事件来确定下一个对话步骤，或协调响应和Action的执行。
Execution Rail：验证Custom Action和Tool的输入·输出，并控制其执行。
Output Rail：在将生成的响应返回给用户之前，允许、修改或阻止。

在此流程中，NeMo显然是LLM管道编排器。Application无需再次实现相同的Rail顺序。然而，NVIDIA文档并未说明应将用户账户的最终访问权限或租户所有权判断交给NeMo。NeMo可以调用Custom Action的事实与执行该Action的业务权限是两回事。

NeMo中两种可能的RAG集成方式

NVIDIA的RAG集成教程同时描述了两种方式。因此，不应断定只有一种是NeMo的官方标准。

方式1：Application传递Relevant Chunks

Application或Application拥有的Retrieval API首先进行检索。此时，根据认证用户和租户应用过滤器和安全修剪。检索到的原始文本块作为relevant_chunks上下文传递给NeMo的generate调用。

优点是数据访问权限易于与现有业务API以相同方式管理，且无需直接向NeMo授予Vector DB凭证。缺点是Application需要实现检索流程、错误处理和NeMo上下文传递，因此Application的职责增加。

方式2：NeMo管理知识库和检索

使用NeMo配置中的知识库，或连接Custom retrieve_relevant_chunks Action或Custom EmbeddingSearchProvider，由Runtime管理检索阶段。LLM管道配置集中在一处，便于实验和策略变更。

然而，“NeMo管理检索”并不意味着“NeMo决定用户权限”。Custom Action或外部检索API必须以可信的方式接收Application验证并传递的用户·租户上下文，并在访问存储时再次强制执行该权限。不应将提示中写入的tenant_id或LLM推断的用户角色作为授权依据。

两种方式的选择标准是检索职责的位置。如果现有数据访问API和权限模型已成熟，Relevant Chunks方式更为自然。如果是独立的知识机器人且数据隔离要求简单，NeMo管理方式也可能。如果多租户和细粒度文档权限是核心，即使NeMo启动检索调用，实际查询也应通过强制执行权限的Retrieval API进行，这样更安全。

Presidio应部署在哪里？

Microsoft Presidio Analyzer是一个基于Python的引擎，用于检测非结构化文本中的PII（个人身份信息），如姓名、电话号码、电子邮件。它可以作为Python库的AnalyzerEngine在进程内部调用，也可以部署为HTTP服务进行调用。检测结果可以传递给Presidio Anonymizer，以配置掩码或替换处理。

Presidio不是整个管道的编排器，而是文本PII检查器。因此，在在线RAG流程中，应检查Vector DB检索后返回的原始文本块，而不是嵌入向量本身。嵌入是用于语义搜索的数值表示，PII引擎难以将其作为检查和匿名化原始文本中姓名和电话号码精确位置的输入。

部署位置有两种可能：

在Application拥有的检索层调用：Retrieval API在通过Tenant Filter检索后立即调用Presidio，并将安全的文本块返回给NeMo。优点是数据在进入NeMo边界之前就被最小化。
在NeMo Retrieval Rail的Custom Action中调用：在检索到的原始文本块进入提示之前调用Presidio。这样更容易一起跟踪护栏策略和PII处理。

本文推荐的设计方案将权限过滤和PII检查在顺序上分离。Tenant Filter和文档授权首先在Retrieval API中应用，然后将返回的原始文本块在NeMo Retrieval Rail中通过Presidio进行检查。因为即使Presidio对文档进行了掩码处理，也不意味着可以检索其他租户的文档。未经授权的数据从一开始就不应包含在检索结果中。

此外，可以在最终的Output Rail中再次对生成的响应进行PII检查，作为额外的防御层。但输出检查不能替代检索前的授权。如果LLM已经接收了未经授权的原始文本，那么在输出阻止之前，安全边界就已经被打破了。

三种编排方式比较


比较标准	Application直接编排	NeMo Runtime编排	Application + NeMo混合型

—	—	—	—
认证·授权责任	Application直接负责	NeMo前的Application·Gateway或各下游API负责。不将最终判断交给NeMo·LLM	Application和可信API负责用户·租户·业务权限
RAG检索责任	Application执行检索、Tenant Filter、Security Trimming、上下文组装	NeMo知识库、retrieve_relevant_chunks Action或EmbeddingSearchProvider管理流程。实际权限执行在检索API·存储中进行	NeMo协调检索时机，Application拥有的Retrieval API执行权限过滤
护栏执行	Application代码或单独的中间件直接组合	NeMo Runtime执行Input·Retrieval·Dialog·Execution·Output Rail	LLM相关护栏由NeMo负责，业务有效性验证由Application负责
LLM调用	Application直接调用	NeMo Runtime根据配置调用	NeMo调用，Application可从外部控制模型凭证·允许模型·成本限额策略
可扩展性	单一代码库启动简单，但功能增加时耦合度和瓶颈可能增大	Rail和Action易于独立扩展，但需要Runtime容量规划和外部服务故障处理	各组件可独立扩展，但需要服务间契约和跟踪体系
策略可追溯性	易于集中存储，但安全策略和对话策略可能混淆	以Rail配置和Colang流程为中心，易于跟踪LLM策略	业务权限策略和LLM策略可分离所有权，但需要关联ID和集成审计
实现复杂度	初期可能较低，但随着RAG·Tool·Rail增加可能迅速升高	LLM流程实现简化，但会产生NeMo运营和Colang学习成本	初期复杂度最高，存在策略重复风险，需要明确的职责表
适用场景	简单的单租户聊天机器人，以现有Application代码为中心的小型系统	独立的知识机器人，复杂的对话·工具流程，LLM策略实验频繁的系统	多租户、细粒度文档权限、受监管数据、包含多个Tool和审批流程的运营系统

并非所有方式都总是优越的。对简单的聊天机器人应用混合型可能会增加运营复杂性，而用一个Application实现复杂的、多租户的代理可能会使变更和故障的影响范围过大。

如何分离认证·授权与护栏执行？

最简单的职责划分如下：

Application或可信API层的职责

登录会话和令牌验证
用户和租户的权威映射
RBAC·ABAC·文档所有权等业务授权
Retrieval API的Tenant Filter和Security Trimming
下游Tool的最小权限凭证和用户上下文传递
支付、删除、外部传输等高风险操作的最终批准
连接请求·检索文档·Tool执行·响应的审计日志
速率限制、成本限额、会话失效和事故响应

NeMo Guardrails的职责

检查有害或超出允许范围的输入
过滤·转换检索到的原始文本块并调用PII检查
管理对话状态和允许的流程
检查Tool·Custom Action输入和输出的LLM策略
协调LLM调用和响应生成流程
检查生成输出的安全性、格式、主题、PII
生成拒绝响应或安全的替代响应

在此划分中，最重要的规则是LLM或NeMo不应成为用户最终访问权限的权威决定者。即使NeMo的Rail判断“此用户看起来像管理员”，那也不是授权依据。授权必须在IdP、策略引擎、Application数据、Retrieval API、下游系统等确定性且可审计的层级强制执行。

混合型中常见的失败

Application和NeMo以不同方式实现相同策略

如果Application阻止身份证号而NeMo掩码并允许，策略就会出现分歧，导致结果难以预测。对于每项策略，应确定决策所有者和执行位置，并指明其他层的检查是用于深度防御还是最终决策。

从用户输入或提示中获取Tenant ID

Tenant ID应从登录后服务器确定的身份上下文中获取。如果直接使用浏览器发送的JSON字段或LLM推断的组织名称作为查询过滤器，可能会绕过租户边界。

向NeMo授予高权限存储凭证

即使NeMo管理检索，也应使用只读·租户限制凭证或权限验证Retrieval API。如果使用公共管理员账户查询整个Vector DB，然后仅在Rail中过滤，则不符合最小权限和Complete Mediation原则。

只信任最终的Output Rail

输出阻止可以减少泄露的可能性，但不能证明未经授权的数据已被检索并进入LLM提示是合理的。权限检查应在检索前进行，PII最小化应在提示组装前进行，输出检查应在返回前分别进行。

将所有内容放入一个Hub中，造成瓶颈和单点故障

以确保安全控制一致性为由，将所有逻辑放入一个Application中，会导致部署和故障影响整个路径。应保持访问控制策略的单一性，同时独立扩展Retrieval API和NeMo Runtime，并设计超时、熔断和失败时安全拒绝的机制。

实践应用清单

身份和权限

[ ] 是否通过IdP和服务器端映射而非浏览器发送的Tenant ID来确定租户？
[ ] 用户身份和权限范围是否以难以伪造的形式传递到Retrieval API和Tool？
[ ] 是否不将NeMo或LLM的自然语言判断作为最终授权依据？
[ ] 各下游系统是否在每次请求时重新验证权限？
[ ] 高风险操作是否经过用户确认或单独的审批流程？

RAG和个人信息

[ ] 共享Vector DB查询中是否强制包含Tenant Filter？
[ ] 是否定义了租户内部也需要文档·行·等级级别的Security Trimming？
[ ] 未经授权的原始文本是否在进入NeMo或LLM上下文之前被阻止？
[ ] Presidio是否检查的是检索后返回的原始文本块而非嵌入？
[ ] PII检测失败、Presidio故障、匿名化错误发生时，是否安全拒绝或限制？
[ ] 如果需要，Output Rail是否再次检查生成的响应中的PII？

编排和运营

[ ] 是否文档化了认证·授权策略和LLM Rail策略的所有者？
[ ] 是否记录了Relevant Chunks方式和NeMo管理方式的选择依据？
[ ] 是否对NeMo Custom Action和Tool应用了最小功能·最小权限？
[ ] Application、NeMo、Retrieval API、LLM、Tool的日志是否可以通过一个关联ID连接？
[ ] 日志中是否没有过度记录原始PII、令牌、提示秘密信息？
[ ] NeMo或Retrieval API故障时，是否没有通过绕过路径直接调用LLM或Vector DB？
[ ] 是否定义了各组件的超时、重试、熔断、速率限制、成本限额？
[ ] 是否对Rail策略和业务权限策略是否存在重复或冲突进行回归测试？

结论：中心不是一个，而是按职责划分的两个

支持以Application为中心设计的安全依据是明确的。OWASP强调最小权限、用户上下文、Complete Mediation和下游授权。ASVS要求可信的服务层和一致的访问控制机制。Microsoft建议在多租户RAG中将Tenant Filter、Security Trimming和访问日志封装在数据访问API中。

然而，这些依据并未形成“所有通信都必须由一个Application进程直接中继”这一与产品无关的官方原则。这是一种可以根据系统风险、组织结构和运营条件选择的设计方案。

另一方面，NVIDIA官方说明NeMo Guardrails Runtime协调Rail、Custom Action、Retrieval和LLM调用。因此，将NeMo置于LLM处理流程的中心是自然的。但NeMo的管道编排与用户的业务授权并非同一职责。

总结来说，Application是安全和业务控制的中心，而NeMo是LLM处理管道的中心。RAG检索两种方式都可行，但租户和文档权限必须由可信的Retrieval API或存储强制执行。Presidio作为检查已确认权限的检索原始文本PII的引擎进行部署。并且，不应让LLM或NeMo判断用户的最终访问权限。