跳转到主要内容

运行时治理胜过提示词治理:解读 Nvidia Sentry 与 kill-switch 之争

提示词层面的控制是建议性的,因为它们存在于一个概率系统内部。运行时拦截位于动作变得具体的位置,而权威正应属于那里。

铁路货场中货运列车与轨道的鸟瞰图

放置控制的两个位置

每个 agent 系统都有两个候选位置来放置安全控制。第一个在模型的指令内部:一个写着不要删除生产数据的 system prompt,一个警告不要外泄密钥的工具描述,一段附加到上下文窗口的策略段落。第二个在 agent 与它试图执行的操作之间的运行时路径上:tool call、egress 请求、凭证使用。

这两者并不等价,而且差异不是程度上的。提示词层面的约束是一个概率系统的输入。它与用户的消息、检索到的文档、三轮之前到达的工具输出,以及攻击者放在 agent 刚刚抓取的网页里的任何内容争夺注意力。它受制于模型的所有失效模式:长上下文中的指令漂移、对自信用户的谄媚、对注入文本的易感性,以及纯粹的采样方差。当它奏效时,奏效是因为模型选择遵从。当它失效时,架构中没有任何东西会察觉。

运行时控制拦截的位置,是动作已经具体化的那个点。模型已经发出了一个带有名称和参数的 tool call。该调用是一个结构化对象,而不是一种倾向。它可以被解析、与策略匹配、暂扣、改写或拒绝,这一切都发生在任何东西到达文件系统、网络或密钥存储之前。控制不需要模型同意它。

当前围绕 Nvidia 的运行时 agent 安全框架以及更广泛的 kill-switch 之争的讨论,在厂商话术之下,是一场关于哪一层持有权威的争论。一方把模型当作执行面,试图让指令更强。另一方把模型当作不可信的规划器,把权威放在它必须经过的路径上。从架构上看,第二方是正确的,而行业向它的漂移是正确的押注。

kill switch 是一种症状

kill switch 是一个有吸引力的想法,因为它把一个艰难的治理问题压缩成一个按钮。它还预设了 agent 集群很少具备的两件事:一个对整个部署拥有权威的单一监督者,以及一条从该监督者到每个运行中工作负载的可靠通道。

Close-up of a server rack in a data center, showing storage hardware and cabling

两者都无法经受真实系统的考验。agent 由编排器生成,跨区域扩展,嵌入队列和 cron 任务,并被授予比请求它们的进程存活更久的凭证。监督者往往与实际持有打开套接字的容器相隔数层抽象。沿这条链向下发送的信号是一个请求,而不是保证,而请求会被崩溃的 sidecar、分区的网络和正在重试中的工作负载丢弃。

真正阻止 agent 的是能力的移除,而不是意图的传递。具体来说:撤销 agent 正在使用的 token,这样它的下一次调用无论它自认为在做什么都会授权失败。在网络边界关闭 egress 路径,这样离开进程的请求无处可去。排空 agent 读取的队列,这样没有新工作到达。轮换它即将读取的密钥。这些是执行动作,因为它们改变的是什么是可能的,而不是什么是被意图的。建立在能力撤销之上的关停程序会优雅降级:如果一项撤销失败,其他项仍然有效。

值得精确说明策略产物是什么、不是什么。当一家实验室发布关停标准,或发布描述 agent 何时应停止的模型规范条款时,那是一份治理文档。它塑造行为,它传递意图,它建立问责。它不是执行机制,因为它与被它约束的模型处在边界的同一侧。把这类出版物读作安全保证,就是把价值观声明误认为控制声明。

设计规则:拦截,而非指示

由此得出的规则是狭窄且机械的。每个有后果的工具都在调用路径上获得一个策略决策点,并采取默认拒绝的姿态。有后果意味着任何写入、删除、发送、花费、认证或触及沙箱之外的操作。默认拒绝意味着该工具在策略明确允许特定调用形态之前不可用,而不是在有人记得去阻止它之前可用。

机制并不光鲜。agent 运行时把每个工具包裹在一个拦截器中。在派发之前,拦截器组装一个决策请求:主体(哪个 agent、哪个任务、哪个委托身份)、工具名称、参数的摘要,以及诸如会话数据分类之类的上下文信号。它查询策略引擎,收到允许、拒绝或转换的裁决,然后才派发、改写或拒绝。转换很重要:对某个字段进行脱敏或收窄某条路径,往往比二元阻断更好。

Close-up of an orange power button on an electronic remote control device

每个决策都连同主体、工具、参数摘要和裁决一起记录日志。使用摘要而非原始参数,使日志可以安全留存,同时仍允许重放和争议处理。该日志是审计、事件复盘以及调优策略本身的基底。

在这种设计下,指令并没有消失。它们仍然是塑造行为的正确工具:语气、分解策略、何时提出澄清问题、如何总结。改变的是所做出的主张。任何安全属性都不应仅依赖一条指令,因为指令是对一个遵从性在构造上就是概率性的系统提出的建议。

执行的代价

运行时拦截不是免费的,假装它是免费的会产生糟糕的架构。三项代价是真实的。

第一是延迟和一个新的单点故障。每个被拦截的调用现在都要等待一个策略决策,而策略路径处在产品的关键路径上。如果它不可用,正确的默认是拒绝,这意味着策略服务需要自己的可用性预算,至少与其守护的工具一样强。这是一项工程承诺,而不是配置细节:复制的决策点、带短过期时间的签名策略包的本地缓存,以及为降级情况记录在案的行为。

第二是策略编写是一个 schema 问题。模糊的 schema 会产生两种失效模式之一:规则宽到对一切盖章放行,或规则紧到阻断合法工作、团队于是绕开它们。工作在于把决策请求做对——哪些属性在调用时可用、哪些是稳定的、哪些可能被攻击者影响。喂给未建模上下文的策略引擎,会对错误的事情做出自信的决策。

第三是度量。规则数量不是安全指标;一个庞大的规则集可能完全不起作用。值得追踪的结果,是有后果工具上被拦截动作与允许动作的比率,按工具和主体细分。在一个写入生产环境的工具上,比率接近零,是策略只是装饰的信号。一次变更后比率急剧变化,是值得调查的信号。两个数字都不是保证,但两者都描述了控制是否真的在路径上。

诚实的总结是:运行时治理把信任从模型的遵从转移到运营者的基础设施。这是更难构建的东西,也是更容易审计的东西。鉴于 agent 系统正被授予凭证和网络访问权限,审计才是真正重要的部分。

分享XLinkedIn永久链接6 分钟阅读

相关阅读

这能回答的问题

Why are prompt-level safety constraints considered advisory?

They are inputs to a probabilistic system and inherit its failure modes, including instruction drift, susceptibility to injected text and sampling variance. Compliance depends on the model choosing to comply, and nothing in the architecture detects when it does not.

What does a runtime policy decision point actually check?

Before a tool call is dispatched, the interceptor assembles the principal, tool name, an arguments digest and contextual signals, then queries a policy engine for a permit, deny or transform verdict. The decision and its inputs are logged for audit and replay.

Is a kill switch sufficient to stop a misbehaving agent fleet?

Rarely. A kill switch assumes a single supervisor and a reliable channel to every workload, which distributed agent fleets seldom have. Revoking credentials, closing egress and draining queues changes what is possible rather than signalling intent, and degrades more gracefully.

What are the main costs of runtime enforcement?

Added latency and a new single point of failure on the call path, which needs its own availability budget. Policy authoring is also a schema problem, and a vague schema yields either rubber-stamped rules or blocked legitimate work.