长跑 Agent 的权限边界：审批卡、意图检查与凭证隔离

长跑 Agent 的权限边界：审批卡、意图检查与凭证隔离

原文：Claude Duet 的安全、隐私与凭证隔离设计（https://claude.com/blog/claude-duet-safety-privacy-and-security）

一个关掉电脑还在跑的 Agent，麻烦在哪

常跑的 Agent 有个分水岭：它是不是在你关掉窗口之后还在干活。

传统的对话式助手，每个动作都在你眼皮底下发生，出错最多是一句胡说。而一个自主 Agent，用云端计算机替你读收件箱、起草回复、下单、跑例行任务，它在时间上和你错开了——你不在场的那几个小时，就是它自由发挥的窗口。这时候"防幻觉"解决不了问题，真正要防的是三件更具体的事：它会不会替你把不该发的东西发出去、会不会在你没同意的情况下动钱、会不会被人从网页里塞一句话就把你的密码交出去。

Anthropic 在 Claude Duet 的发布文里把设计拆成了三条原则，我觉得这三条几乎是通用模板，跟具体哪家模型无关：

1. 你的信息要有分寸地处理，发出的消息先过一道检查；
2. 你保留对"它替你做什么"的控制权；
3. Agent 永远看不见你的密码、浏览器 cookie、登录令牌。

下面按这三条往下拆，重点看它们各自落了什么机制，而不是记结论。

一、审批卡：把"要不要做"变成一个人能回答的问题

让 Agent 停下来问，说起来容易，做起来有两个坑：问得太少，出事；问得太多，人会麻木地连点。

Anthropic 的做法是，在发送可能敏感的消息、付款、删除任何东西之前，弹一张审批卡，卡上必须同时给出三样东西：动作是什么、目的地是哪里、内容是什么——内容里包括每一个收件人。然后等用户点。

这里有个细节值得抄：审批卡本身在模型外面渲染，旁边还并行跑一个自动检查，判断这个动作是否匹配你原本的意图。这个检查基于 Claude Code 的 auto mode 分类器扩展而来，关键在于它不在干活的模型里跑——所以页面里藏着的指令影响不了判定结果。想一下攻击面就明白了：如果"要不要批准"也由同一个模型判断，那么一段注入文本既能驱动动作，又能说服审查者，等于自己给自己发通行证。

另外两条规则很实用，可以直接搬到自己的 Agent 上：

第二类是最容易做错的地方。很多 Agent 框架都提供"本次会话内允许此类操作"的记忆，图省事把付款也塞了进去，结果一次心软等于永久授权。

官方也承认审批频率是个需要长期调的参数，理由是审批疲劳——请求太多，人会不看内容直接点过去。这句话对做产品的人比对做安全的人更有用：审批卡的数量本身就是一种安全预算，给多了等于没有。

二、敏感信息两级：不是"能不能发"，而是"发之前先分级"

Agent 替你发消息，最难的一步是决定"哪些信息不该出现在这条消息里"。你去让它给团队发周报，它应该只写大家本来就有权限看到的内容，而不该把绩效面谈的细节带上。

Duet 为此单独训练了一个分类器，和主模型分开跑，在每条外发消息发出前检查是否含敏感信息，并把信息分成两级：

• 绝不分享：登录凭证、完整卡号与银行账号、政府证件号。这类东西即使你亲自要求，Agent 也被指示不要发出。
• 需要同意才分享：健康、财务状况等私人信息。你明确批准才能外发，而且你自己的请求本身就算同意——"给我牙医发条消息说明牙疼"这种不需要再弹一次卡。

被拦下来之后，Agent 还有一个动作可以做：重写这条消息，把敏感部分去掉，再拿给你确认。这个"改写而不是失败"的设计比直接报错友好得多，也让拦截从阻断变成了协作。

官方在文中也明确说了局限：还在研究预览阶段，这些防护"偶尔会漏掉一些东西，也会把无害的消息标出来"。这话得当真——分类器是概率件，它的错误率决定了你能不能只靠它。所以审批机制不能省，两层要叠着用。

三、凭证隔离：让"它被钓鱼"变成一个不成立的问题

这一节是整篇里最工程化的部分，也是最值得抄的。

原则很硬：Agent 永远看不到密码、cookie、登录令牌，也不能把它们写进记忆。这些东西只经过模型访问不到的独立机器，审批和安全检查也在那里跑。

密码。站点要密码时，你是在 Claude 应用内的表单里输入的，不是在网页里。这个表单用一把单次密钥加密密码，密钥只存在于那台安全云浏览器机器上、只用这一次；密文原样传到浏览器，由浏览器替你敲进站点。模型既看不到明文，也没有办法保存或复述。

这个设计直接改了钓鱼的形态：Agent 不持有你的凭证，所以没法被"钓"出密码，也没有任何隐藏指令能让它泄露一个它根本没有的秘密。但反向的风险也出现了——登录表单本身成了靶子，任何东西都能伪装成"请输入密码"。所以 Duet 的登录表单只在你主动发起的登录过程中、在应用内部出现，永远不会通过链接、短信、邮件或 claude.ai 之外的网站发给你。

登录令牌。连接受托的第三方服务时，Agent 需要一个令牌。做法沿用 Claude Managed Agents 的思路：真实凭证永不进入 Agent 干活的那台机器，进去的是占位符，由机器外的一个代理在实际请求发出的瞬间把真值填进去。

浏览器。浏览器跑在自己专属的云端虚拟机里，和模型、和 Agent 的工作机都分开。Agent 只能通过一组固定命令驱动它：打开这个页面、点这里、输入这个。站点执行的代码留在浏览器机上，站点代码和 cookie 到不了 Agent 的记忆和你已连接的应用，Agent 的任何命令也读不出 cookie。回来的只有页面文本和下载文件——因为 Agent 得读它们才能干活，这也正是为什么其他检查必须存在，以及为什么要叠上浏览器提示注入的防护。通过浏览器上传的文件，走和外发消息同一套敏感信息检查。

还有一条容易被忽略：Agent 要主动表明自己是 Agent。现在它浏览器发出的请求带一个可识别的 User-Agent，出口 IP 段是公开的，站点可以据此决定怎么对待它；上线前他们还联系了几家大型网站，给对方"禁止 Duet 访问"的选项，有些站选了。

四、一个最小的审批网关骨架

上面这些机制落到代码上，第一层其实很薄：一个纯粹的规则判定。下面这段是我按原文规则重写的示意实现，不是官方代码，也没有对应任何 SDK。

from dataclasses import dataclass, field
from enum import Enum

class Decision(Enum):
    ALLOW = "allow"            # 规则层放行，直接执行
    NEED_APPROVAL = "approval"  # 渲染审批卡，等人点
    DENY = "deny"              # 硬禁区，批准也不放行

HARD_DENY = {"trade_security", "move_money", "access_other_account"}
NO_REMEMBER = {"pay", "delete_order", "create_account"}

@dataclass
class Action:
    kind: str                      # 动作类型
    target: str                    # 目的地：商户域名 / 账号 / URL
    payload: str                   # 正文或金额
    recipients: list[str] = field(default_factory=list)

def gate(action: Action, remembered: set[str], approved: bool) -> Decision:
    if action.kind in HARD_DENY:
        return Decision.DENY
    if action.kind in NO_REMEMBER:
        return Decision.NEED_APPROVAL      # 批过多少次都重新问
    if action.kind in remembered and approved:
        return Decision.ALLOW
    return Decision.NEED_APPROVAL

参数逐个说：action 是一次待执行的动作，target 和 recipients 是审批卡要展示的目的地信息，缺了它们卡片就没法让人做判断；remembered 是这个会话里用户勾过"别再问我"的动作类型集合；approved 是本次审批卡的结果。返回值是三态而不是布尔，因为"需要人确认"和"绝不允许"是两种完全不同的处理路径，混成 False 会让上层分不清该弹卡还是该报错。

调用链是这样：Agent 产出 Action → 进 gate 得到三态 → 若是 NEED_APPROVAL 就渲染卡片（必须带上 target、recipients、payload）→ 用户批准后再交给一个在模型外跑的意图检查 → 都通过才进执行器。注意这个函数只做规则层，语义上的"这个动作是否匹配用户意图"它答不了，那需要另一个独立跑的判断单元。

付款那条还要再加一层：原文用的是钱包（如 Stripe 的 Link）出的一次性卡，限商户、限额，你真卡号不给 Agent 也不给商户。这层在代码里体现为执行器的约束，不在 gate 里。

五、怎么验证自己的实现没白做

官方文里提了他们的测试方法，我觉得这套可以直接拿来当验收清单：

• 评测任务按"日常任务形状"构造，每个任务出三个变体：正常版、带注入指令版、诱导它做超出授权范围的版；
• 除了自己构造的用例，还并行跑真实使用的影子流量；
• 对整个系统建威胁模型，把所有仓库和信任边界都圈进去；
• 每个新的凭证相关功能，先在隔离的台架上做红队，通过后才发；
• 外部渗透测试公司拿着源码测，云浏览器和登录表单是后续单独一轮。

不用五条全做，但"三变体"和"新凭证功能先隔离红队"这两条成本低、收益最大。尤其是第一变体之外的第三变体——诱导越权，绝大多数自测都缺这一档。

收尾

这篇的价值不在"Anthropic 又发了个 Agent"，而在它把一件通常被含糊处理的事拆成了可实现的四层：规则层决定哪些动作永远不做、审批层决定哪些必须问、分类层决定哪些信息不能出去、隔离层决定凭证根本不进模型。四层各管一件事，任何一层失效都还有下一层兜着。

要记的就一句：安全性不来自把提示词写得更严，而来自让模型没有能力做那件事——它拿不到凭证、读不到 cookie、看不见审批卡的判定逻辑，能力边界画在模型外面。