Newshot 
关于保护 AI agent 的安全，我们告诉客户三件事：它们需要有自己的身份，需要与其被赋予的职责相匹配的访问权限，以及独立于任何人类用户的可追溯性。这对我们在 Token 也是如此。然后，我们构建了一个默认就打破了这三条规则的 agent。
这帮助我们理清了应当如何防御这类 agent。当浏览器 agent 在用户已认证的会话中行动时，应用可能看到的是用户，却看不到 agent、看不到这种委托关系，也看不到任务的预期范围。通过创建一个打破所有安全规则的 agent，Token 了解到企业应当如何利用身份来获得控制权，尤其是在 agent 使用规模扩大之时。标准正在制定中，但安全团队今天就可以采取一些措施。
我们会标记出来的那个 agent
我们创建的 agent 名为 Rehearsal。它的职责是在 Token 平台内通过动手操作而非口头说明来回答问题。它会自主地在浏览器标签页中打开页面、设置筛选条件并填写表单。
从安全角度看，它是一个运行在用户浏览器中的典型 UI agent。这正是它有用的原因。但这也意味着该 agent 运行在用户的会话之内，并拥有用户的可及范围。
此外，对于页面背后的服务器而言，agent 的点击本质上与用户的点击无法区分，因为会话 cookie 中没有任何内容指明会话的驱动者是谁。
同时掌控两端带来了什么可能
由于 Token 同时拥有该 agent 及其运行的应用，我们可以从内部弥合每一处缺口。例如，Token 知道是谁在驱动会话，因为 Rehearsal 会告诉它。
我们了解到，当你掌控 AI agent 本身时，可以应用多项最佳实践：
- 当 agent 操作时，将应用变暗并锁定，并清楚标明谁拥有控制权。
- 记录每个会话的每一次操作，包括那些被阻止的操作。
- 将 agent 的可及范围缩小到低于用户。对于 Rehearsal，我们确保仪表盘为只读。未经用户批准它无法保存任何内容，不填写机密字段，也绝不发送平台已拒绝的调用。它还通过页面的无障碍标签来理解仪表盘控件。
这对我们自己的 agent 有效，但仅仅是因为它依赖的是外部 agent 所没有的访问权限。
谁来为其他所有人解决这个问题？
我们能够给 Rehearsal 一个执行者身份、一个作用域和一份页面地图，是因为我们是编写它的人。而一个驱动你的 CRM 或云控制台的浏览器 agent 这些都没有。应用无法察觉它的存在，agent 也无法分辨哪个字段存放着机密、哪个按钮会删除记录。会话本身携带的是用户的身份。
出路在于给 agent 分配独立于人类用户的专属通道。Web 已经开始构建这些通道，但未必聚焦于整体性的方法。
浏览器可以标记其 agent 何时在驱动，并据此限制自身。例如，Chrome 的自动浏览已经要求在支付或群发邮件等高风险操作前获得本人批准，将其 agent 限制在任务所需的站点内，并在用户的历史记录中标记 agent 访问过的页面。Microsoft 允许管理员按站点开启 agentic 浏览，并在输入密码和卡号之前暂停它。
应用可以将其操作发布为工具。WebMCP 是 Google 和 Microsoft 在一个 W3C 社区组中起草的规范，它让站点可以暴露 agent 能直接调用的操作，并将每个操作标记为只读或具有后果。这样一来，agent 无需猜测某个按钮的作用。
agent 可以对其请求进行签名。Web Bot Auth 目前是 IETF 的一个工作组草案，它让站点能够验证是哪个 agent 发送了请求。
缺的是一层把它们连接起来的东西。每条通道都掌握着其他通道不知道的信息，却没有一条把信息传递出去。浏览器知道是自己的 agent 在驱动，但 Chrome 和 Edge 都没有说明如何告知另一端的应用。WebMCP 工具在用户的会话内、以用户的权限运行，因此它本身并不能收窄 agent 可触及的范围。Web Bot Auth 标明了 agent 的身份，但草案明确表示它不涵盖委托，因此它遗漏了 agent 所代表的那个人。
应用最终只能握着一堆零散的上下文，而不是拿到可据以行动的东西。
再考虑到 agent 到来的速度快于标准。仅做到对 agent 友好还不够。每条为 agent 构建的通道都应携带 agent 的身份、一条指向其所代表之人的可验证链接，以及一个比该人更窄的权限范围。这三项信号合在一起，才能给应用提供做出授权决策所需的最低限度上下文。否则，更快的通道只是通往权限滥用的更快路径。
在标准跟上之前，安全团队能做什么
等待标准化不是选项。你需要尽快开始发现 agentic 浏览器和扩展，包括那些被借用了会话的用户。而且，虽然你无法判断是谁点击的，但你可以通过加入 passkey 提示这类 step-up 校验，来选择哪些点击需要真人操作。
- 盘点能够通过已认证会话行动的浏览器 agent、agentic 扩展和端点 agent，并将它们映射到用户和所有者。
- 追踪每一个 AI agent 消费者，以便知道哪些人（以及其他 agent）正在使用每一个单独的 agent
- 审查每一个单独的 agent 有权访问的每一个身份
- 识别利用 agent 绕过访问控制的潜在攻击路径
- 在敏感或不可逆的应用操作之前，要求显式批准或 step-up 认证。
- 询问关键 SaaS 供应商，他们的审计记录是否能区分 agent 活动与人类活动，以及他们是否支持任务范围的委托。
在浏览器和应用能够同时携带 agent 身份、人类委托和任务范围之前，公司应将每一个使用人类会话的 agent 视为委托访问，必须被发现、约束和审计。