Agent-native 身份系统 6 要素
Agent 进入真实工作流以后，安全问题不再只是“它能不能登录”，而是它代表谁、为了什么任务行动、每一步究竟应该拿到多少权限。
这不是给现有账号体系增加一个 Agent 类型就能解决的问题。Agent 是会根据上下文临时选择路径的非确定性软件。身份系统也必须从静态门禁，变成伴随任务全过程的控制平面。
Agent 的风险来自行动方式
传统应用按预先写好的程序运行，调用哪些系统、需要什么权限，大多可以在上线前审查。
Agent 通常只接到一个目标。比如处理一次生产事故，它可能自行选择日志系统、工单系统和代码仓库，决定运行哪些命令、修改什么代码，再提交 PR。相同目标也可能产生不同的执行路径。
这带来四类新风险。
第一，企业无法在运行前穷举 Agent 的行为。它会从 MCP Server、本地命令、skills 和配置文件中发现工具，路径选择发生在模型推理过程中。
第二，单个动作合规，不代表整条链路安全。读取日志、创建工单、提交 PR 都可能分别获得合法授权，但如果 Agent 把日志中的个人信息写进工单，又在公开 PR 中引用工单，组合起来仍然会泄露数据。
第三，任务可能继续委托给 sub-agent，或者经 MCP Server 转到其他 API。链条越长，最初是谁提出任务、批准了什么、限制条件是什么，就越容易丢失。
第四，Agent 的速度使逐次人工审批失去可行性。确认窗口太多，最终只会制造审批疲劳，让“人在回路”变成机械点击。
旧身份体系描述不了委托关系
现有系统通常把主体分成两类：员工身份回答“这个人是谁”，工作负载身份回答“这个应用是谁”。
Agent 同时跨越两类主体。它先接受人的委托，又以软件身份调用系统。因此真正需要表达的是：哪个用户把哪些权限交给了哪个 Agent，允许它在什么条件下访问哪些资源。
如果任务继续向下委托，用户身份和限制条件也必须随之传递。
现实中，大量 Agent 仍依靠 API key、.env 密钥或数据库连接字符串工作。这些长期凭证把权限预先装进运行环境。Agent 只要读到凭证，就继承其中的全部能力，而不是只得到当前步骤需要的能力。
素材中的事故处理案例很典型：同一枚云服务 API key 既能续签证书，也能重启生产服务和扩容；数据库连接字符串甚至允许 Agent 直接删除数据库，却不能帮助它确认备份是否存在。
问题不只是凭证泄露，而是权限从一开始就给得过多、存在得过久，也没有和具体任务绑定。
Agent-native 身份系统的六个要素
我认为，一套真正面向 Agent 的身份系统，至少要解决六件事。
第一，Agent 必须是可识别、可验证的独立主体。系统不能只记录运行它的员工账号或应用账号，否则出了问题，无法区分是人还是 Agent 在行动。同一个 Agent 跨越不同系统时，身份还应保持一致。
第二，每次真实操作都要重新授权。判断不能只发生在登录或签发 token 时，而要发生在 Agent 准备访问某项资源、执行某个动作之前。用户委托、当前任务、运行组件、目标资源和环境安全性，都可能影响结果。
第三，信任应该渐进建立。Agent 申请的范围过大，系统可以缩小权限；风险较高，可以要求人工批准；上下文不足，可以暂缓决定。授权不是只有全给或全拒两种选择。
第四，默认零常驻权限。任务结束，相关权限也应失效。短期 access token 比长期 API key 更安全，但仅仅缩短 token 有效期还不够：只要应用仍保留用户授权，就可能继续换取新 token。真正需要结束的是与任务绑定的授权关系。
第五，日志要保存完整委托链。审计记录不仅要写 Agent 做了什么，还要说明它代表谁、获得了什么权限、为什么获准，以及请求经过了哪些 Agent 和系统。
第六，也是最难的一点：每个动作都必须受用户目标约束。Prompt 未必完整表达意图，Agent 对任务的理解也可能逐步偏移。系统不仅要判断“有没有权限”，还要判断“这一步是否仍然服务于最初目标”。目前行业对如何可靠做到这一点，还没有成熟答案。
企业应先建立有限安全区
Agent 身份管理仍在早期阶段。素材引用的调查显示，91% 的受访组织已经开始使用 AI Agent，但只有 10% 建立了较完善的非人类身份管理策略。使用速度远快于治理速度。
更现实的风险是 shadow IT：员工可能已经在本地安装 Agent，并为它配置内部系统权限。下游系统只看到员工访问 Snowflake 或修改 GitHub，却不知道操作者究竟是员工本人，还是代表他行动的 Agent。
企业第一步不是追求一套完美平台，而是先看清现状：有哪些 Agent，它们能读取哪些凭证，连接了哪些系统，由谁负责。
然后建立一个有限安全区，只允许经过批准的 Agent 使用有限工具和资源。新增 Agent、工具和权限逐项开放，再根据真实运行记录扩大范围。
这比一开始给予广泛权限、出事后再收缩更可控，也能为后续策略积累证据。
市场正在从两个入口切入
现有玩家大致分成三类：Microsoft、Okta 等大型安全公司，把 Agent 纳入原有身份平台；Anthropic 等模型公司，在自己的 Agent 产品中加入访问控制；Oasis Security、Keycard 等初创公司，则从新的身份和授权问题切入。
从产品问题看，我更关注两个入口。
一类是 Agent 生命周期管理：发现企业里有哪些 Agent、服务账号和长期凭证，明确负责人、访问范围、审查和停用机制。
另一类是运行时授权：在 Agent 真正调用工具时，根据委托关系、任务和目标资源，决定当前动作能否执行，并签发短期凭证。
两者最终会合流。只登记 Agent 而不控制每次行动，解决不了动态风险；只判断单次调用而不了解 Agent 的归属和生命周期，也缺少治理基础。
Keycard 展示了一种运行时控制思路
Keycard 最初想做“面向机器的 SSO”，减少应用和服务之间散落的长期 API key。Agent 进入工作流后，它把方向延伸到人的委托与 Agent 授权。
它并不替模型规划任务，也不执行工具调用。企业原有身份系统继续验证用户，Agent runtime 继续运行模型和 agent loop。Keycard 位于授权环节，在每次工具调用前综合用户委托、运行组件、目标资源和企业 policy，决定是否签发面向当前目标的短期 token。
下一次调用如果目标资源或操作范围变化，就重新申请、重新判断。演示中的 token 通常只在几分钟内有效，只能交给指定的 MCP Server，并把权限限制在当前操作所需范围。
这套流程建立在 OAuth 2.0 和 RFC 8693 Token Exchange 等现有标准上。标准解决 token 如何交换，但不会自动判断操作是否符合用户任务。Prompt、运行环境和任务上下文是否进入 policy，仍要由企业决定，面向 Agent 的授权规范也尚未收敛。
身份系统控制权限，不替代 Agent 能力
在事故处理案例中，接入运行时授权后，续签证书只得到对应 scope；删除数据库被 policy 直接阻止；重启生产环境虽然经过人工批准，但批准人自己没有权限，操作仍被拒绝；扩容在有权限的人批准后才执行。
这说明系统可以产生直接放行、直接拒绝、人工批准后拒绝、人工批准后放行四种结果。人工确认不是越权通道，审批者的权限仍然有效。
但身份系统仍然不能判断数据库备份是否存在，也不会让 Agent 更懂事故处理。它解决的是“这一步能不能获得权限”，不是“这一步做得对不对”。
这是我认为最需要守住的边界：模型负责理解任务和制定路径，身份系统负责约束每一步可以调用的能力。安全不能依赖 Agent 自觉，也不能期待授权系统替 Agent 做业务判断。
Agent 成为 coworker 以后，身份管理的对象已经从账号变成了委托链，从静态角色变成了动态任务，从一次登录变成了连续决策。谁能把这三次转换做扎实，谁才真正建立了 Agent 进入企业核心流程的基础设施。