2024年9月，微软把Copilot塞进Windows内核的消息传出时，安全圈的人还在算CVE编号。3个月后，他们发现真正的问题不是漏洞——是整套权限叙事都在被重写。
Workload Identity（工作负载身份）这个听起来像HR术语的东西，正在成为AI时代的基础设施裂缝。它原本解决的是"程序怎么证明自己是谁"，现在却要回答"AI代理（AI Agent）到底算用户、算服务，还是算一个随时会分叉的新主体"。
从"人证合一"到"程序自证"
身份验证的老故事很简单：用户登录，系统查密码，放行。Workload Identity把这个逻辑搬给了机器——容器启动时，向身份提供商（Identity Provider）要一张临时令牌，证明自己有权访问数据库。
这套模型在云原生时代跑得很顺。Kubernetes集群里的Pod（最小部署单元）不需要硬编码密码，凭服务账号就能拿到密钥。2023年，Google Cloud的Workload Identity Federation已经处理了每月数万亿次令牌请求。
但AI代理的出现，把"工作负载"的定义撕开了。
传统的Workload Identity假设：一个程序的身份是静态的，启动时确定，生命周期内不变。AI代理却可能在一次对话中调用10个外部工具，生成子进程，甚至克隆自己到另一台机器。每个动作都需要身份，但每个身份的有效期、权限范围、责任主体都在动态变化。
内核里的主权让渡
微软把Copilot Runtime放进Windows内核，不是功能升级，是架构层面的领土割让。
内核（Kernel）是操作系统的"禁区"。普通程序进不去，进去了也不能随便出来。这个设计用了50年，核心假设是：内核里的代码可信，用户态的程序可疑。但现在，一个AI代理既运行在内核层，又在替用户执行操作——它到底继承谁的权限？用户的，还是系统的？
更麻烦的是推理链（Chain of Thought）。AI代理的决策不是原子操作，是一连串中间步骤。每一步都可能触发新的权限请求，但传统的Workload Identity模型没有"半途中断并审计"的机制。安全团队发现，一个被提示注入攻击的代理，可以在用户完全无感知的情况下，用它的身份令牌调用内部API。
2024年11月，某头部云厂商的内部复盘显示：AI代理相关的权限逃逸事件，有73%发生在"代理认为自己在帮用户做事"的场景。换句话说，恶意指令被包装成了用户意图。
OpenSSF的供应链赌注
开源软件安全基金会（OpenSSF）把Workload Identity列为2025年供应链安全的三大优先级之一。他们的逻辑很直接：AI代理会大量依赖开源工具链，而工具链的每个环节都需要身份验证。
但现有的标准全是为人设计的。OAuth 2.0的授权码流程假设用户会在浏览器里点"同意"，SAML的企业单点登录假设有HR部门管账号生命周期。AI代理没有手指，不会离职，它的"同意"到底怎么算？
一些厂商开始推新的令牌格式，把AI代理的推理步骤编码进JWT（JSON Web Token）的声明字段。理论上，接收方可以验证"这个API调用是代理在回答用户第3个问题时生成的"。实际部署中，令牌体积膨胀了40%，延迟增加了两位数毫秒——对高频交易系统来说，这等于不可用。
更激进的方案是硬件级身份。Intel的TDX和AMD的SEV-SNP都在推"可信执行环境+Workload Identity"的捆绑，让AI代理的每个推理步骤都带硬件签名。代价是：你得买新芯片，重写调度层，而且性能损失在15%-30%之间。
身份即边界
Workload Identity的演进史，其实是信任边界的收缩史。
十年前，边界是防火墙。五年前，边界是零信任架构的"永不信任，始终验证"。现在，边界缩小到了单个AI代理的一次函数调用。安全团队被迫承认：他们无法预判代理会做什么，只能尽量让每次操作都可追溯、可撤销。
这带来一个反直觉的后果——权限粒度正在无限细分。某金融科技公司的实践是：给每个AI代理的每个工具调用分配独立令牌，有效期90秒，单次使用。他们的令牌发放系统在2024年Q4处理了日均12亿次请求，是2023年同期的17倍。
成本炸了，但替代方案更贵。一次未被检测到的代理权限滥用，在2024年的平均损失估值是340万美元——来自Verizon DBIR的未公开细分数据。
微软、Google、AWS在2024年底密集发布了各自的"AI代理身份"方案，互不兼容。OpenSSF试图推动标准化，但进展缓慢。一个核心争议点是：代理的"子代理"算不算独立身份？如果AI生成了一个临时脚本，这个脚本的身份从哪来？
这些问题没有现成答案。Workload Identity的历史教科书只写到云原生时代，AI代理的章节还是空白页。
当你的AI助手下次说"我需要访问您的日历来安排会议"时，它拿到的令牌权限范围，是谁决定的？
热门跟贴