Newshot 
面向客户开展AI Agent安全建设时，我们始终强调三条核心原则：为Agent配置独立身份、遵循最小权限分配对应访问权限、建立独立于人类用户的操作溯源机制。Token内部落地安全建设时，原本也严格遵循这三条原则。直到我们自研了一款Agent，它在默认配置下就突破了全部三条规则。
这次实践帮我们理清了这类Agent的防护思路。当浏览器端Agent在用户的已认证会话内执行操作时，应用只能识别到用户身份，无法感知到Agent的存在、授权委托关系，也无法判断任务的预期权限范围。通过打造这款突破所有安全规则的Agent，Token明确了企业在Agent规模化应用阶段，如何通过身份体系实现管控。相关行业标准仍在制定中，但安全团队当下就可以落地多项防护措施。
自研测试Agent本应触发安全拦截，运行于用户浏览器会话中
我们开发的这款Agent名为Rehearsal，核心定位是在Token平台内通过实际操作响应用户问题，而非仅输出文本答案。它可以自主在浏览器标签页打开页面、设置筛选条件、填写表单。
从安全角度看，这是一款运行在用户浏览器内的典型UI Agent，这种部署模式正是其实用性的来源。但这也意味着，Agent完全运行在用户的会话上下文内，拥有与用户完全一致的访问权限。
更关键的是，页面对应的服务端天然无法区分Agent发起的Click与用户操作——会话Cookie中没有任何字段标识当前会话的实际操控者。
自研自控Agent与应用，可从内部落地全链路防护
由于Token同时掌控Agent本身及其运行的应用平台，我们可以从内部逐一填补安全缺口。比如Rehearsal会主动向平台上报当前的实际操控者，平台因此能明确会话的驱动主体。
在完全可控的自研AI Agent场景下，我们总结出多条可落地的最佳实践：
- Agent运行期间，将应用界面调暗并锁定，清晰标识当前的控制主体。
- 记录每个会话内的所有操作，包括被安全策略拦截的操作。
- 将Agent的权限范围设置为低于对应用户的权限。针对Rehearsal，我们将其对仪表盘的权限设为只读；未经用户批准不得执行任何保存操作，不会自动填写敏感字段，也不会发起任何已被平台拦截的请求。同时，Rehearsal可通过页面的无障碍标签识别仪表盘控件。
这套防护机制仅适用于自研Agent场景，因为其依赖的内部访问通道，外部Agent根本无法获取。
第三方Agent安全需多方协同，现有标准仍缺连通中间层
我们之所以能为Rehearsal配置明确的操作主体、权限范围和页面映射，是因为这是我们完全自研的产品。但操控CRM或云控制台的第三方浏览器Agent，完全不具备这些配置条件。应用无法感知到这类Agent的存在，Agent也无法识别哪个字段是敏感字段、哪个按钮会触发删除记录操作，整个会话仅携带用户的身份凭证。
解决这一问题的核心思路，是为Agent划分独立于人类用户的运行通道。目前Web生态已经开始搭建这类通道，但整体方案尚未形成体系化的全局设计。
浏览器侧可在Agent操控时添加标记，并据此执行限制策略。比如Chrome auto-browse功能，在触发支付、群发邮件等高风险操作前必须获得用户人工确认；会将Agent的访问范围限制在任务所需的站点内，同时在用户历史记录中标记Agent访问过的页面。微软则支持管理员按站点开启Agent驱动的浏览模式，在用户输入密码、银行卡号前自动暂停Agent操作。
应用侧可将自身操作封装为标准工具对外开放。谷歌与微软正在W3C社区小组内牵头制定WebMCP草案，支持站点对外暴露可供Agent直接调用的操作接口，同时为每个接口标记只读属性或高风险影响等级。这样Agent无需猜测按钮对应的实际功能。
Agent侧可对自身发起的请求进行签名。目前IETF工作组正在制定Web Bot Auth草案，支持站点验证发送请求的具体Agent身份。
目前缺失的是连接以上三方的中间层。每个参与方掌握的信息互不相通，也没有机制实现信息传递。浏览器知道当前是Agent在操控会话，但Chrome和Edge都没有定义如何将这一信息告知对端的应用。WebMCP工具运行在用户会话内、继承用户的全部权限，本身无法缩小Agent的访问范围。Web Bot Auth可以标识Agent身份，但草案明确说明其不覆盖委托授权场景，因此无法关联Agent所服务的实际用户。
最终应用只能拿到零散的上下文信息，无法形成可落地的授权判断依据。
当前Agent的落地速度远快于标准制定速度，仅做适配Agent的功能改造远远不够。所有为Agent搭建的运行通道，都必须携带三类核心信息：Agent自身的身份、可验证的Agent与所服务用户的委托关联、小于用户权限的任务范围。这三类信息共同构成了应用做出授权决策所需的最小上下文。如果缺少这些信息，为Agent搭建的快速通道只会成为权限滥用的快车道。
无需等待行业标准落地，安全团队可立即开展Agent防护
等待标准完全成型再开展防护并不可取。企业需要尽快梳理所有Agent驱动的浏览器、扩展程序，以及这类工具借用会话对应的所属用户。虽然企业无法识别当前是谁发起了Click，但可以通过添加通行密钥提示等二次校验步骤，明确要求高风险场景下的Click必须由用户本人确认。
- 梳理所有可通过已认证会话执行操作的浏览器Agent、Agent类扩展、端点Agent，建立这类工具与对应用户、责任主体的映射关系。
- 对每个AI Agent的使用主体进行全链路溯源，明确每个Agent对应的使用者（包括其他调用它的Agent）。
- 排查每个Agent可访问的所有身份权限。
- 识别利用Agent绕过访问控制的潜在攻击路径。
- 针对敏感操作或不可逆转的应用操作，要求必须获得用户明确批准或完成二次身份校验。
- 要求核心SaaS厂商明确答复：其审计日志是否可区分Agent操作与人类用户操作，是否支持基于任务范围的委托授权。
在浏览器与应用实现Agent身份、用户委托关系、任务范围三类信息的打通传递之前，企业应当将所有借用人类用户会话的Agent视为委托访问场景，对这类访问做到全面发现、权限约束、操作审计。
We Built An Agent That Broke All of Our Security Rules. Here's What We Learned.