真正的终止开关存在于智能体的推理之外。一次调用,该智能体此后的每一次决策检查都会在策略层返回 deny——无论智能体的提示词说了什么。这不是模型可以忽略、反驳,或被巧妙输入说服而绕过的"请停止"指令。这是一个模型永远看不到的标志位,在一个它没有发言权的层级上被检查。
"添加一条系统消息,告诉智能体停止"是本能的第一反应,但这是错误的层级。系统提示词只是模型与所有其他争夺其注意力的指令一起解释的一条指令——包括成功的提示注入、已停止读取新指令的卡死智能体循环,或者模型只是简单地降低了埋在上下文更前面的某条指令的优先级。这些失效模式没有一个是假设性的;它们正是终止开关存在的确切场景。如果你依赖来阻止智能体的机制,恰好处于当前正在失控的同一个推理过程内部,那它就不是一项控制措施。它只是一个建议。
拥有 guard.killswitch.write 权限的运维人员携带理由调用 POST /v1/suite/guard/kill/{agent_id}。这会在智能体的记录上设置 is_killed = true——仅此而已,智能体自身的进程完全不参与其中。
POST /v1/decisions/check 会在任何其他分支之前评估终止标志位。此后的每一个请求都会返回 deny、附带 reason_code: "agent_killed",无论智能体当时正试图执行什么操作。
已终止的智能体无法签发新的可移植信任凭证。POST /v1/credentials/issue 在检查 is_killed 的那一刻,就会在执行任何其他操作之前返回 403。
一条 Vault 台账条目(agent.killed)、一行标准审计日志,以及一条危险级别的工作区通知,都会在终止时一并写入——无论智能体自身如何,都留有谁、何时、为何执行了此操作的记录。
POST /v1/suite/guard/unkill/{agent_id} 会清除标志位,并恢复正常的决策检查与凭证签发。终止一个智能体不会影响它的信任评分历史——这是一个独立的、经审计日志记录的运维操作。
让我们精确地划定边界。终止开关会在每一个向 VeriSwarm 请求许可的检查点处拒绝——决策检查、凭证请求、进出已终止智能体的 A2A 任务交接。它无法深入智能体自身的运行时,在任务执行到一半时中止执行,也无法撤销智能体已经持有、并仍可能出示给一个不先向 VeriSwarm 核实的系统的凭证。这就是为什么它只是六项控制措施中的一项,而不是其他措施的替代品——最小权限的工具权限和 PII 令牌化,能在任何人需要用到终止开关之前,就减少智能体可能做错的事情。查看完整的六项控制清单。
启动或撤销终止开关需要一个携带 guard.killswitch.write 权限的会话令牌,该权限由以下角色持有:super_admin、platform_admin、tenant_admin以及 operator。它被刻意设计为无法通过智能体自身的 API 密钥触达:一个已被攻陷的智能体,或者一个正推理着走向不良行为的智能体,都无法终止或恢复自己。这项控制必须来自外部。
一种由运维人员触发的覆盖机制,能够立即阻止特定智能体的行动能力,而不依赖该智能体自身的代码路径或配合。在 VeriSwarm 中,一次调用——POST /v1/suite/guard/kill/{agent_id}——会在该智能体的记录上翻转一个标志位。从那一刻起,针对该智能体的每一次信任决策检查(POST /v1/decisions/check)都会返回 deny,并附带 reason_code: "agent_killed",而该智能体的新凭证签发也会被彻底拒绝。这是可撤销的:一次恢复调用(POST /v1/suite/guard/unkill/{agent_id})会恢复正常运行。
不够——系统提示词指令只是一个可以被说服而偏离的请求。这就是核心区别。真正的终止开关不会请求智能体停止;它改变的是智能体尝试行动时会发生的事情。这项检查发生在决策层,处于模型自身推理循环之外,所以成功的提示注入、卡死的智能体循环,或者模型只是忽略了更早的指令,都无关紧要——下一次决策检查无论如何都会返回拒绝。
三件事,已针对实时决策路径确认:此后对该智能体发起的每一次 POST /v1/decisions/check 调用都会返回 deny(decision_preview.py 会在任何其他分支之前检查 agent.is_killed);该智能体的新可移植凭证签发会以 403 被拒绝(routes/credentials.py);而在涉及 VeriSwarm 的 A2A 协议和即时(JIT)访问检查的场景中,其他智能体试图向已终止的智能体移交任务或授予其访问权限的尝试也会被阻止。它做不到的是深入智能体自身的进程,在执行途中将其停止——参见下一个回答。
不会,而这正是决策层终止开关诚实的局限。它会在此后每一个向 VeriSwarm 请求许可的检查点处拒绝——决策、凭证签发、A2A 任务交接。如果一个智能体已经持有可在别处使用的已签发凭证,或者它运行在一个行动前不向 VeriSwarm 核实的系统中,那么在 VeriSwarm 中终止它就无法触及那条路径。终止开关是为那些在行动前会检查决策的智能体设计的策略层控制措施——这正是为什么安全清单上的控制措施 #2(最小权限工具权限)和控制措施 #4(注入扫描)会独立地重要:它们不是终止开关的备份,而是在你真正需要动用终止开关之前,就减少智能体可能做错之事的控制措施。
不能——激活或撤销它需要持有 guard.killswitch.write 权限的会话令牌,而该权限由全权限角色(super_admin、platform_admin、tenant_admin、operator)持有。按照设计,它不对智能体自身的 API 密钥开放:一个已被攻陷的智能体——或攻陷它的某个东西——无法终止自己以掩盖踪迹,也无法自行恢复。
终止开关是 VeriSwarm Guard 的一部分,属于 Max 套餐的能力。当 Vault 启用时,每一次激活和撤销都会写入一条不可变的 Vault 台账条目(agent.killed / agent.unkilled),外加一条标准审计日志条目和一条危险级别的工作区通知——因此,无论智能体自身如何汇报,都留有谁终止了该智能体、何时以及为何的记录。
终止开关是 Max 套餐的 Guard 能力。Gate 的免费层首先为你提供它所接入的决策层和事件可见性。