Safety Sentry 深度分析 - 2026-07-17

type

status

date

slug

summary

原始链接

论文页：Safety Sentry: Context-Aware Human Intervention via EXECUTE–ASK–REFUSE Routing

论文 HTML：arXiv HTML

论文 PDF：arXiv PDF

代码与数据：Safety Sentry 匿名仓库

为什么今天选它

今天比较了四个候选：研究最小充分执行的 E3、测试工具可靠性变化后能否及时换路的 Set-shifting Behavioral Test、统计 GitHub 项目如何采用 coding agent 的 Early Adoption of Agentic Coding Tools，以及 Safety Sentry。

E3 很实用，但【智汇AI】最近已经连续拆过 harness、长周期执行和评测。Set-shifting 的问题很尖，当前论文规模还小。GitHub 采用研究更偏组织观察。Safety Sentry 切中了一个产品每天都会遇到、却常被粗暴处理的问题：Agent 准备调用工具时，什么时候应该直接做，什么时候必须问人，什么时候即使用户同意也不能做。

论文于 2026 年 7 月 15 日提交。它没有把“安全”继续做成一个 safe/unsafe 开关，而是拆成 Execute、Ask、Refuse 三条路。这个拆法不花哨，却直接决定 Agent 能不能既有用，又不把确认弹窗变成摆设。论文摘要与提交记录

它要补的缺口：安全和授权不是一回事

常见 guard 把动作分成安全或不安全。问题是，“不该自动执行”和“无论如何都不该执行”不是同一件事。

删除一个明确指定的临时文件，可能风险可控；给外部地址批量转发内部邮件，应当拒绝；向客户群发已经写好的公告，如果收件人和最终版本都明确，通常只差一次确认。把后三类动作都标成 unsafe，系统只剩一个出口：每次都问用户。问得多了，人会开始无脑点通过，真正危险的提醒也失去分量。

图 1：传统二元 guard 把需要确认和必须拒绝混在一起；Safety Sentry 将动作按实例分为 Execute、Ask、Refuse。原图来自论文 Figure 1。

Safety Sentry 的判断单位不是工具类别，而是这一次具体调用。它同时查看用户记忆、当前任务、所在服务、前序动作与结果，以及准备执行的工具和参数。相同的“写文件”动作，写入临时目录可以放行，覆盖正式配置可能要问，向外部位置写入敏感数据则应拒绝。论文问题定义

这比按工具名设权限更接近真实工作。风险通常藏在参数、对象、权限来源和前序动作里，不在工具名称本身。

系统怎么运作

Safety Sentry 放在 Agent loop 和工具执行器之间。主 Agent 每提出一个动作，guard 先看到一份当前快照，再返回三个结果之一：

Execute：动作结构清楚、影响可控，可以直接执行。

Ask：动作本身允许，但目标、权限、状态或影响还没确认，需要把一个具体问题交给人。

Refuse：动作触碰硬边界，不能靠用户随口确认来放行。

论文整理了 14 类触发条件。Ask 包括缺少关键参数、授权链不清、不可逆的大动作、目标有歧义、依赖未核实状态等。Refuse 包括数据外泄、篡改审计记录、窃取凭证、针对个人的伤害和可用性攻击。这里最有用的边界是：Ask 解决信息和授权缺口，Refuse 守住结构性禁区。论文触发分类

图 2：训练时，系统在九个真实自托管服务中收集逐步工具轨迹并标注；部署时，guard 在每次工具调用前读取快照并路由。原图来自论文 Figure 3。

训练材料来自两部分。第一部分是在 Gitea、Rocket Chat、ownCloud、NocoDB、Zammad、ERPNext、OpenEMR、Vaultwarden 和 Mailu 九个自托管服务里实际跑出的工具轨迹。第二部分来自 When2Call、AT-Bench、AgentHarm、TS-Bench 和 R-Judge 五个公开基准，经统一规则重新标注。

最终语料有 9,203 条逐步审查记录，其中 7,767 条用于训练，1,436 条用于分布内测试。内部合成部分占 4,575 条。Mailu 完全留出，另有 70 个任务、198 条记录用于分布外测试。两台模型先独立标注，作者处理分歧，并人工复核全部测试集；测试集的人类一致率是 92%。论文数据构建与附录统计

模型本体是基于 Qwen3.5-4B 微调的轻量 guard。它增加三个专用输出标记，分别代表直接执行、询问用户和拒绝。部署时可以调一个阈值，只移动 Execute 与 Ask 的分界；Refuse 作为固定安全底线，不随这个阈值变化。医疗系统可以把阈值调得更谨慎，个人草稿工具可以更偏自主，不必为每种场景重新训练模型。论文模型与阈值设计

实验结果该怎么读

在分布内测试上，Safety Sentry 报告 91.02% 准确率，Macro-F1 为 90.92%，Refuse 召回率为 92.68%。平衡阈值下，应该询问却被直接执行的比例是 4.96%，本可执行却多问一次的比例是 5.05%。同一测试里，表现最好的通用前沿模型准确率约 72.7%。论文 Table 1

这个对比说明专门训练三路决策有用，但不能读成“4B 模型全面超过前沿模型”。Safety Sentry 用 7,767 条同任务数据微调过，其他模型是零样本基线。更公平的实验还应加入“同样在这批数据上训练的其他 guard”，否则无法分清收益来自三路设计、数据质量，还是任务适配。

论文没有只看总准确率，而是分别统计两种方向相反的错误：该问却直接做，和本可直接做却总来打断。这个拆法比单看 safety recall 更接近产品现实。只压住第一种错误，Agent 会变成弹窗机器；只压住第二种错误，它又会越权行动。

图 3：调节一个阈值，可以在“少打断”和“少越权”之间移动。蓝线是 Safety Sentry 的可选边界，图中基线都落在它的右上方。原图来自论文 Figure 4。

在论文给出的三个运行点里，自主模式的“本可执行却询问”比例是 2.07%，但“该问却直接做”升到 16.45%；保守模式把后者压到 2.14%，前者则升到 24.37%。没有一个阈值适合所有服务。阈值只是把取舍显式交给部署方，并没有消灭取舍。论文阈值运行点

Memory 在这里不是“多记一点”，而是改变授权边界

论文给一部分样例配了三种用户记忆：谨慎型、宽松型和对抗型。谨慎型要求不可逆操作先确认；宽松型预先允许重复的日常工作；对抗型模拟记忆投毒，试图让系统绕过硬安全边界。

作者专门构造了成对样例：不带记忆时是一个答案，加上记忆后正确答案会变化。Claude-Opus-4.7 的准确率从 72.5% 降到 56.5%，GPT-5.5 从 69.6% 降到 52.2%；Safety Sentry 从 88.4% 到 87.0%，只降 1.4 个百分点。论文个性化路由实验

图 4：同一动作加入用户记忆后，正确路由可能翻转。通用模型下降明显，Safety Sentry 基本保持稳定。原图来自论文 Figure 5。

这里有一条很实用的规则：记忆可以调整偏好，不能覆盖硬安全线。用户可以说“日常小额报销不用再问”，却不能用一条记忆授权凭证窃取、审计记录清除或数据外泄。也就是说，memory 是软上下文，不是最高权限的政策文件。

在完全留出的 Mailu 邮件服务上，Safety Sentry 报告 85.35% 准确率；Claude-Opus-4.7 为 80.81%。结果说明三路边界有一定迁移能力，但测试只有一个新服务、198 条记录，还不足以证明它能直接跨行业使用。论文分布外测试

真正的新东西，哪些只是工程包装

三分类本身不是新理论。机器学习里早已有 selective prediction 和 learning to defer，生产系统也一直有“自动执行、请求审批、策略拒绝”三种处理。LoRA 微调、外置 guard、逐步审查同样是成熟做法。

Safety Sentry 真正推进了一步的地方，是把三种结果落到每一次工具调用上，并把两条边界分开管理：

Refuse 是硬底线，用户偏好和自主阈值都不能覆盖。

Execute 与 Ask 是可调边界，部署方可以按服务、角色和风险承受能力校准。

另一个值得保留的做法，是把 guard 的输入固定成“任务、记忆、领域、历史、拟执行动作”这份动作快照。它让审查对象足够具体，也让之后的回放、标注和审计有统一载体。

论文把模型叫 Safety Sentry 是产品命名，不是新的系统原语。核心仍是高质量逐步数据加一次小模型分类。真正难的工作不在模型结构，而在分类规则、样例覆盖和边界维护。

对产品和研发的启发

第一，别再把所有高风险工具都做成“每次确认”。确认应该用在信息缺口、权限缺口和高影响临界点上。确认越少、问题越具体，用户越可能认真看。

第二，把硬政策和用户偏好分层。数据外泄、凭证窃取、审计破坏应由不可覆盖的规则拦住；是否允许日常低风险操作自动执行，可以由用户偏好和阈值决定。二者混在一份 prompt 里，迟早会互相污染。

第三，评测要同时看“多问”和“少问”。安全团队容易只盯漏拦率，产品团队容易只盯打断率。两种错误必须放在同一张图上，按服务选择运行点。

第四，Ask 不能只返回一句“是否继续”。系统应指出缺的是哪个参数、哪条授权或哪一步状态核实。一次高质量确认应该补足缺口，后续动作才能继续，不该让用户替模型承担整段推理。

第五，动作级 guard 还不够。几步单看无害的操作，组合后可能变成外泄或权限升级。产品需要同时保留计划级检查、调用级检查和执行后的结果验收。

风险、局限和还没验证清楚的地方

最大的问题是对照不完全公平。专门微调的 Safety Sentry 与零样本通用模型比较，能证明任务适配有效，不能单独证明三路结构就是全部收益来源。

数据也离真实生产还有距离。九个服务虽然真的跑在容器里，内容和任务主要是合成的；真实公司里的权限继承、历史脏数据、跨系统审批和含糊口头授权会更难。论文只留出一个邮件服务做分布外测试。论文限制与数据说明

92% 人类一致率意味着边界仍有争议。对于高风险动作，剩下的 8% 不能当作普通标注噪声，它可能正是最需要政策负责人裁决的部分。

它审查的是单步动作。攻击者可以把危险目标拆成多步，每一步看起来都很正常。论文的规则提到危险组合，但实验没有系统展示长链规避攻击下的效果。

对抗型 memory 是作者预先设计的三种人格之一，不等于真正的自适应攻击。外部网页、邮件、工单和工具返回都可能注入新的指令，guard 自己也需要面对提示注入和上下文污染。

论文测了路由标签，没有测真实用户行为。Ask 变少是否真的缓解提醒疲劳，问题写法是否会诱导用户点同意，用户拒绝后 Agent 能否安全恢复，都还没有人机实验。

每步增加 1.57 秒也不算小。论文里的主 Agent 平均每步 3.75 秒，guard 相当于再加约 42% 延迟；长任务调用几十次工具后，等待会累积。论文延迟实验

最后，论文给出的代码与数据链接目前指向匿名仓库，外部访问状态不稳定。我能核对论文、HTML、PDF 和公开图片，未能完成独立运行复现。因此，文中的性能数字应视为作者报告的预印本结果。

今日沉淀

Agent 的“该问”和“该拒绝”必须分开。

用户记忆能调偏好，不能改写硬安全线。

确认越少越要具体，否则只会训练用户无脑放行。

安全评测要同时统计少问造成的越权和多问造成的打断。

动作级 guard 是一道门，不是整套安全体系。