代理安全不能只依赖用户点击批准

审批弹窗还在，人工监督可能已经失效了。作者引用 Anthropic 的一个数字：用户会同意 Claude Code 中 93% 的手动权限请求。他据此提出，Agent 的安全边界不能建立在用户持续认真点击的假设上，而应该由模型之外的策略层决定哪些操作自动放行、哪些需要审批、哪些根本不能做。

这篇值得程序员读的地方，是把「加一个确认框」拆成了可以讨论的工程设计：工具调用在哪里拦、审批界面展示什么、凭证给多大权限，以及怎样识别已经失效的审批机制。不过，文中的评估数字和法规信息也需要分开看待。

为什么每次都确认，反而可能没人认真看

作者认为，有效审批需要同时满足三个条件：出现频率足够低，审核者能看到真正执行的调用，而且某些操作即使有人同意也无法解锁。

前两条关乎人的注意力，最后一条才决定权限边界。假如 Agent 可以通过自己生成的说明发起审批，审核者看到的内容就可能受到上下文影响；而上下文又可能混入攻击者提供的网页、文件或消息。

把审核交给另一个模型，也只能缓解其中一部分问题。原文引用的 Anthropic 评估中，完整流水线在真实内部流量上的误报率降到了 0.4%；但面对 52 个真实的过度行动案例，漏报率仍有 17%，约六分之一被放过。降低误报的第二阶段，还进一步降低了召回率，也就是找出风险行动的能力。

这里的取舍很具体：减少无谓阻拦，可能同时漏掉更多危险操作。作者因此主张，分类器适合放在硬性限制之上降噪，不适合独自承担生产数据库删除、资金转出这样的最终防线。

不过，93% 的通过率本身不能证明审批完全无效。如果原来的请求大多安全，通过率自然会高。真正缺少的，是危险请求被拦住多少，以及用户有没有理解自己批准的内容。

把不能做的事，放到模型碰不到的地方

作者提出，在 Agent 和它能访问的工具、MCP server、下游 API 之间加入策略层。Agent 提交请求，策略层在调用发出之前决定是否执行。

操作分四档：只读自动执行；可逆写入通知负责人并提供撤销窗口；对外发送或涉及资金的操作等待审批；高权限操作要求双人审核。此外，还有一份完全没有审批入口的禁用集合。

下面这段代码展示了分级、禁用和超时拒绝如何组合：

TIERS = {
    "read":      "auto",      # list_files, search, get_record
    "write":     "notify",    # reversible, undo window, no blocking prompt
    "external":  "approve",   # send_email, post_webhook, charge_card
    "privileged":"two_party", # grant_role, rotate_key, delete_bucket
}

BLOCKED = {"disable_audit_log", "drop_database", "modify_iam_policy"}

def authorize(agent_id, tool, args):
    if tool in BLOCKED:
        raise PolicyDenied(f"{tool} has no approval path")

    tier = TIERS[classify(tool, args)]

    if tier == "auto":
        return Allow()
    if tier == "notify":
        return Allow(undo=True, notify=agent_owner(agent_id))

    # Deny by default. A timed-out approval is a denial, never a pass.
    decision = request_approval(
        agent=agent_id, tool=tool, args=args,
        reviewers=2 if tier == "two_party" else 1,
        timeout=300, on_timeout=Deny,
    )
    return decision

要盯住的是 BLOCKED 和 on_timeout=Deny：前者让特定操作不存在人工解锁路径，后者让无人回应的请求默认失败。timeout=300、reviewers=2 把等待和双人审核写进了流程，但示例没有实现 classify(tool, args)，也没展开审批如何绑定这次调用。

分级只有在所有调用都经过同一处检查时才成立。

作者还要求收紧凭证权限：即使上层控制全部被绕过，危险 API 也应返回 403。网关可以集中处理身份、允许列表、参数校验和审批，但「Agent 绕不过网关」是部署必须兑现的条件，不能靠架构图保证。

此外，可逆写入需要真的能撤销。代码里的 undo=True 只是接口表达，撤销机制和窗口仍要由系统实现。

审批界面和调用链，也属于检查范围

审批弹窗并非天然可信。作者指出，间接提示注入可能影响模型生成的摘要，让人批准的内容与实际执行的内容出现偏差。

因此，界面应该展示模板解析后的真实工具名、参数和最终目标地址，不能只展示模型写的行动说明。对前端来说，这直接影响审批页的数据来源：应该从待执行请求中取展示数据。

通知渠道也有边界。把完整载荷发到 Slack，确实方便多人查看，却可能把受监管数据带入不适合存放它的系统。审批消息同样需要控制披露范围。

单次调用检查还有另一个盲区：十次单独看都正常的读取，合起来可能就是一次数据导出。作者建议增加每次运行、每个 Agent 每天的速率限制，并关注记忆投毒和自主行为偏移。前者是污染 Agent 后续依赖的记忆，后者是执行逐渐偏离原定目标，两者都难以只靠当前动作的确认框识别。

作者还建议从第一天记录三类指标：各层级通过率、决策耗时，以及覆盖决定和重试的比例。接近 100% 的通过率需要复查；低于两秒的响应可能是在机械点击；被拒后马上换个说法再申请，则值得告警。

日志还应包含 Agent 身份、准确参数、审核者和当时的策略版本。否则六个月后回查，很难解释某个请求为什么被允许。

我的判断

我认同这篇的工程方向：先限制 Agent 实际能获得的权限，再分配人的注意力。相比所有操作统一确认，分级更有机会让审核者集中处理有外部影响、难以撤销的动作；相比全部交给审核模型，底层受限凭证也提供了独立的阻拦机会。

但「四档通常足够」以及「接近全通过就降为通知加撤销」，属于作者的经验建议。文中没有给出对照实验，不能把它们当成普遍结论。高通过率可能来自任务安全，低于两秒也可能是审核者熟悉固定请求，仍需结合具体操作判断。

52 个案例上的 17% 漏报，也不足以直接推算一般团队的风险。原文没有展开样本构成和评估条件，这组数据能提醒我们关注漏报，不能替代本地验证。

法规部分尤其需要保留问号。原文称，EU AI Act 第 14 条要求高风险系统支持人工监督，并称 Regulation (EU) 2026/1744，即 Digital Omnibus，于 2026 年 7 月 27 日生效，将 Annex III 相关义务从 2026 年 8 月推迟至 2027 年 12 月 2 日。这些法律编号和日期在当前材料中未经独立核验，不宜直接拿去安排合规日程；具体系统是否属于适用范围，原文也明确交给法律专业人士判断。

能拿来做什么

• 给现有 AI 编程工具列一份操作清单，先区分只读、可撤销写入、对外操作和高权限操作，再确定哪些必须彻底禁用。
• 在 Node 工具服务或 MCP 调用入口统一检查身份、工具名和参数，并收紧下游凭证，确认 Agent 的其他执行入口无法绕过限制。
• 修改审批页，展示实际待执行调用的工具、参数和解析后目标，同时检查通知内容是否会泄露不该进入协作渠道的数据。
• 开始记录分层通过率、审核耗时、拒绝后的重试和策略版本，并增加运行级、每日级限额，用真实调用记录判断审批是否有效。