AI同事上岗了，公司的门禁还是给人设计的？

深度思想，谈 AI 与向往 —— 字节深思圈

两件事凑到一起，说明同一个问题已经躲不掉了。企业数据安全公司 Cyera 宣布，以约 10 亿美元收购做非人类身份管理的 Oasis Security；几乎同一时间，Anthropic 推出 Claude tag，团队成员可以直接在 Slack 里 @Claude 派活。一笔十亿美元级的并购，一项嵌进日常工作流的功能，指向的都是同一件事：Agent 的身份和权限，正在从技术圈的讨论，变成企业必须回答的安全问题。

而大多数企业还没准备好。Okta 2025 年的调查显示，91% 的受访组织已经开始使用 AI agent，但只有 10% 制定了较为完善的非人类身份管理策略。九成在用，一成有准备，这个缺口就是风险敞口。

Agent 是一种没法提前审查的软件

要理解为什么老的权限体系会失灵，得先看清 Agent 和传统程序的差别。

传统程序的行为是可以穷举的：人先做判断，写定代码，程序按代码执行。安全团队审查一遍代码，大致就知道它会访问什么、做什么。但 Agent 不是这样。它只接收一个目标，比如"生产环境出问题了，查日志、建 issue、修复、提交 PR"，真正跑起来以后，它要结合当前上下文、可用工具和上一步的返回结果，自己决定下一步访问哪个系统、调用什么工具。同样一个目标，两次的执行路径都可能不一样。

这带来几个具体的麻烦。开发者没法在运行前列出它会碰哪些系统，因为工具是在模型的推理过程中被发现的；它会跨系统连续操作，而每个系统的权限和日志各管各的，单看每一步都合规，组合起来却可能出事——比如它合规地读了日志、建了工单、提了 PR，但把日志里的个人信息写进工单，又在公开 PR 里引用，泄露就这么发生了；它还可能把任务继续交给下一层 Agent，每传一层，最初的委托信息就丢一点，等请求到了链条末端，执行方已经不知道这活到底是谁让干的。

更现实的一点是速度。Agent 干得比人快得多，一旦同时跑很多个、或者让它跑长任务，人就根本来不及逐项审批。如果每次操作都弹确认框，用户很快就会审批疲劳，看都不看直接点允许。审批一旦变成走形式，等于没有审批。

旧门禁只认两种"人"

企业现有的身份体系，基本是为两种主体设计的。

一种是员工账号，验证你是谁，再按岗位和角色给你相对固定的权限。它默认的是：人在行动前会自己判断该不该做。另一种是应用和服务凭证，识别一个确定的程序，假设它的行为由预先写好的代码决定。

Agent 恰好落在两者的缝隙里。它代表人行动，需要用人的身份说清"它替谁干活"；它又作为软件在运行，需要用应用的身份去调用系统。单拿哪一套来描述它，都不完整。

而眼下最常见的做法，问题更大：很多 Agent 靠长期有效的 API key 访问系统，密钥直接放在它能读到的运行环境里。Agent 一旦拿到这把钥匙，就能用里面的全部权限，哪怕当前这个任务只需要做一件小事。安全领域把这种状态叫 ambient authority——Agent 直接继承了运行环境里现成的所有权限。

一个演示案例很能说明问题。有人让一个夜间运行的事故管理 Agent 连续处理五张工单：续签证书、删除计费数据库、重启生产服务、扩容。它手里的云服务密钥既能续签，也能重启，还能扩容，还能删库。处理删库那张工单时，它直接删了，却没法确认备份是否存在。一把钥匙开所有的门，这就是长期凭证的本质：权限在任务开始之前就被固定死了，和任务本身需不需要，没有关系。

真正变的是授权发生的时间

把这些问题归拢一下，会发现核心其实是一件事：授权发生的时间点，变了。

传统体系的授权是一次性的。登录时、发凭证时判断一次，之后长期有效。但 Agent 的授权判断，必须从"发凭证那一刻"挪到"每次实际操作之前"。系统在它动手前重新确认：它代表谁、要访问哪个资源、想执行什么操作、当前任务给了哪些上下文，然后再决定放不放行、放行多少。

换句话说，权限正在从"身份的属性"变成"任务的属性"。同一把钥匙，不再是长期挂在腰上，而是每一步临时发放、用完即收。行业里把这种任务结束后权限就失效的状态叫"零常驻权限"，把这种边走边调整授权的思路叫"渐进式信任"。名字不重要，方向是一致的：给 Agent 的授权，从一次性门禁，变成一个持续判断的控制平面。

这件事难，难在它要动的是整套身份基础设施的判断时机，修一两个功能解决不了。这也是为什么这个领域正在长出一批新公司：有从"先盘点企业里有哪些 Agent、凭证、服务账号"切入的，也有从"在每次工具调用时现场签发短期凭证"切入的。大公司也没闲着，微软、Okta 都在把 Agent 当作一种新的身份对象来管理。方向基本一致，只是入口不同。

但也别把门锁得太死

说到这里得收一收，别把结论推得太远。

权限管得越细，Agent 每一步都要申请、等待、被拒，它的效率就掉得越多。安全是为了让 Agent 能被放心地用起来，如果把门关死，等于为了不出事干脆不干活。这中间的度，行业自己也还没有标准答案——哪些上下文该进入授权判断，目前连从业者都承认没有统一结论；面向 Agent 的授权规范，有的还是提案，有的刚起步，远没有收敛。

所以更现实的路径是，先划一个安全区：让少数经过批准的 Agent，在有限的工具和资源范围内先跑起来；新的 Agent 或工具想接入，再逐项决定开放哪些，然后慢慢扩大。别等一套完美标准出来，也别上来就全量铺开。先让一部分跑通，再谈治理的精细化。

企业现在能做的三件事

对真要引入 Agent 的企业，有三件事不用等标准，现在就能动手。

第一，清点手里的长期凭证。查一查哪些 API key、连接字符串散落在 Agent 的运行环境里，各自能碰到哪些系统。很多风险不是 Agent 带来的，是本来就存在、只是被 Agent 放大了。

第二，把 Agent 登记成一个独立主体，而不是混在员工账号下。记录它代表谁、能进哪些系统、由谁负责。这样审计日志才回答得了"这次操作到底是哪个 Agent、替谁干的"，而不是全记在某位员工头上。

第三，把高危操作的开关留给人。删库、重启生产、扩容这类动作，默认要人工确认；而且系统还得检查，点批准的那个人自己有没有这个权限。授权可以动态，责任不能悬空。

Agent 进企业这件事已经拦不住了。拦不住的事，就得先立规矩。谁先把钥匙的发放和收回管明白，谁才敢真正把活交出去。