AI Agent 身份与授权怎么设计？工作负载身份、委托与短期凭证

直接答案：AI Agent 不应持有一个长期管理员密钥去代表所有用户。可上线的设计至少要回答三个独立问题：运行中的工作负载是谁，它正在代表谁完成哪项任务，以及这个动作对当前资源是否仍被允许。工作负载身份用于证明调用者，委托凭证保留用户或上游主体与任务边界，资源服务在工具执行前再次做授权。凭证应短期、受众绑定、作用域收窄、可撤销；模型只提出动作，不能自行签发权限或把自然语言角色当成安全边界。

身份与授权先要分清哪些主体？

先画主体图：人、应用、Agent、工作负载、工具与资源

一个请求里往往同时存在登录用户、承载界面的应用、负责规划的逻辑 Agent、实际运行的容器或进程、被调用的工具，以及数据库或 SaaS 等最终资源。它们不能共用一个模糊的身份字段。用户主体说明谁提出请求，工作负载主体证明哪段受管软件在运行，Agent 标识说明哪类逻辑能力作出计划，工具客户端说明谁向下游换取令牌，资源对象则决定最终授权。日志必须保留这些关系，而不是只写一个模型名称。

认证不等于授权，授权也不等于当前同意：认证只证明某个主体控制了相应凭据；它没有自动回答该主体能否读取这份文档、修改这条客户记录或发送这封邮件。授权必须结合主体、动作、资源、租户、时间、风险和当前策略。即使用户曾经授权，任务已取消、对象已变更或风险上升时也可能需要重新确认。模型输出的“用户已经允许”不是证据，授权服务必须依据可信令牌、策略和服务端状态判断。

有人值守与无人值守必须分开设计

有人值守流程中，用户已登录并明确发起任务，下游通常需要同时知道用户和执行 Agent，且权限不能超过用户已拥有并同意的范围。无人值守流程没有实时用户，应该使用应用或工作负载自己的窄权限身份，并由预先批准的业务规则限定范围。不要伪造一个永久用户去运行夜间任务，也不要拿后台应用权限绕过用户级访问控制。两类流程的审批、审计、撤销和事故责任不同，回执中必须明确标记。

工作负载身份解决的是谁在运行：工作负载身份把凭据绑定到受信任的运行环境，而不是绑定到源码中的静态密钥。云托管环境可使用托管身份，跨云或本地环境可使用联邦身份、证书或 SPIFFE 类工作负载证明。签发方应验证集群、命名空间、服务账号、镜像或部署来源等条件，再发行短期凭据。它能降低秘密分发与轮换负担，却不能代替业务授权；一个真实工作负载仍可能请求不该执行的动作。

逻辑 Agent 身份与运行实例身份不可混为一谈

逻辑 Agent 表示一种受治理的能力模板，例如采购助手或代码审查助手；运行实例则是某次任务中短暂存在的进程。模板适合绑定所有者、允许工具、默认策略和生命周期，实例适合绑定任务、会话、版本、环境和到期时间。只记录模板会丢失具体执行者，只记录容器会丢失业务责任。安全日志应能从一次工具调用追溯到实例、模板、部署者、请求者和策略版本。

用户委托怎样逐跳变成最小权限？

委托与冒充必须显式区分

委托表示 Agent 以自己的身份行动，同时携带来自用户或上游主体的有限权限；冒充则让下游看起来像用户本人直接行动。多数 Agent 场景更需要委托，因为它保留执行者和原主体，便于限制、审计和问责。OAuth 2.0 Token Exchange 的 actor 与 subject 语义可以表达这种关系，但协议只提供交换框架，令牌内容、信任和授权策略仍由部署者负责。报告必须写清实际采用的语义，不能只写“代用户执行”。

每一跳都要收窄，而不是转发原始用户令牌：把前端收到的用户 bearer token 原样转发给多个工具，会扩大泄露面并制造混淆代理：工具可能得到本不需要的受众、作用域和寿命。更稳妥的流程由受控令牌服务验证上游凭据，再签发只面向单一资源、单一任务和短时间的新凭据。下游继续转委托时再次收窄，并限制链长与可转委托标志。任何一跳都不得增加父级没有的权限，拒绝原因也应进入审计记录。

受众绑定防止令牌被拿去调用别的系统

访问令牌必须明确它服务的目标资源。邮件工具令牌不应被数据库接受，测试环境令牌不应被生产环境接受，甲租户令牌也不能跨到乙租户。资源服务器需要验证发行方、签名、受众、到期、客户端或 actor 约束和必要作用域，而不是只判断令牌格式合法。代理层若统一接受所有受众，等于把各系统的隔离边界合并成一个高价值泄露点。

作用域要按资源与动作表达，而不是按职位写大角色：“销售助手”或“研究 Agent”是便于人理解的类别，不足以直接授权。真正的权限应落到可执行动作与对象，例如读取当前租户的指定知识库、为一组草稿记录写入三个字段、在审批后发送单封邮件。通配角色容易把搜索、删除、导出和权限管理混在一起。设计时从工具参数和资源模型反推最小 scope，再增加对象级与字段级检查；没有对应控制的自然语言限制不能算门禁。

短期凭证的寿命由任务风险决定

凭证持续时间应覆盖正常步骤并留出有限容差，而不是为了省事签发数天或永久密钥。高风险写入、外发、支付与权限变更可按单动作或短窗口签发，低风险只读任务也应有明确到期。寿命越短越能限制泄露后的可用时间，但频繁换取也会增加依赖和故障点，因此要监控签发延迟、失败率与时钟偏差。不要把自动续期做成无条件延长；续期前应重新检查任务与策略。

密钥与工具调用怎样守住执行边界？

静态密钥只能作为受控过渡，不能进入提示词

某些旧服务只接受 API key，此时应把长期秘密放在凭据代理或保密系统，由代理在策略允许后为具体工具调用注入，模型上下文、工具参数草稿和应用日志都不接触明文。代理记录调用主体、目标、用途和结果，并支持轮换与撤销。如果只能把密钥直接交给 Agent，至少使用独立低权限账号、网络白名单、严格配额和人工审批，并把这一限制列为阻断扩大自治的技术债。

工具边界是最后授权点：Agent 选择了某个工具，不代表调用已经获准。工具网关应解析结构化参数，识别最终资源与副作用，再根据可信身份与策略决定允许、要求审批或拒绝。授权应发生在解析重定向、别名和对象引用之后，避免攻击者用看似允许的输入指向高风险目标。数据库、邮件、支付和部署服务还应自行校验权限，不能完全相信上游 Agent 网关；关键控制需要端到端而不是单点装饰。

读取与写入分离，草稿与执行分离

搜索、读取和生成草稿通常比发送、提交、删除或付款风险低。为不同动作使用不同工具、客户端或 scope，可以让只读身份无法通过参数切换成写入。草稿阶段保留对象快照和差异，高风险执行前展示最终目标、关键字段、费用与不可逆影响，由用户或审批人确认。审批后签发一次性或极短期执行凭证，并绑定内容摘要，防止 Agent 在获批后替换收件人、金额或正文。

多租户系统先确定租户，再检查对象：仅验证用户或 Agent 属于某个组织还不够，每次请求都要从可信路由或令牌得到租户，并确认目标对象确实属于该租户。不要接受模型生成的 tenant_id 作为授权依据，也不要让全局搜索结果直接进入后续写入。缓存、向量索引、队列和日志同样要分区；跨租户工具调用必须经过专门的管理流程。测试要覆盖枚举相邻 ID、搜索结果串租户、异步任务丢失租户上下文和管理员代理误用。

防止混淆代理：确认是谁要求什么

混淆代理发生在一个有高权限的服务替低权限调用者完成了不该完成的动作。Agent 会读取邮件、网页和文件，其中的恶意指令可能诱导它调用工具；如果工具只看到高权限服务账号，就无法区分真实用户请求与间接提示注入。控制措施包括保留原主体、绑定批准任务、限制目标、对外部内容降权、在工具前重新授权，以及让高风险服务验证批准回执。提示注入检测只能提供信号，不能替代确定性权限检查。

审批、策略、撤销与审计怎样闭环？

审批必须绑定具体动作和不可变参数

“允许这个 Agent 工作一小时”过于宽泛。有效审批至少记录请求者、执行者、动作、资源、关键参数摘要、允许时间、可接受费用或副作用、审批人和撤销条件。执行端比较当前请求与审批摘要，任何收件人、仓库、金额、环境或内容变化都重新审批。批量操作应展示数量与样本，并设上限。把审批按钮放在界面上但不做服务端绑定，只能证明有人点击过，不能证明执行的就是获批动作。

策略决策在模型之外运行：模型可以帮助把用户意图整理成结构化请求，也可以解释为何需要权限，但允许或拒绝必须由确定性应用、策略引擎或资源服务完成。策略输入来自已验证身份、对象属性、风险等级、会话状态和审批回执；模型输出只能作为不可信候选。策略版本应随决策记录，以便事后复现。紧急放行要有独立身份、短期范围和双人确认，不能通过提示词要求模型“忽略限制”。

撤销不是删除数据库里的一行

撤销要覆盖尚未到期的令牌、服务器会话、缓存、队列任务、浏览器会话、临时文件、外部 SaaS 授权和正在运行的子 Agent。系统应知道哪些凭据可在线撤销，哪些只能等待短期过期，并用网络阻断或资源策略补偿。任务取消、用户离职、设备风险、策略变化和异常行为都应触发撤销。演练要测量从发出撤销到所有关键动作真正失败的时间，而不是只看到控制台显示“已禁用”。

审计要重建完整委托链：每个高价值动作至少记录事件时间、请求 ID、用户或上游主体、逻辑 Agent、工作负载实例、客户端、令牌发行方与受众、作用域、工具、资源、策略版本、审批、结果和撤销状态。日志不保存令牌与秘密，也不需要复制全部提示；关键是能解释谁代表谁、凭什么、对什么做了什么。异步队列和子 Agent 必须传递可验证关联，而不是只传一个任意字符串。时钟同步、日志完整性和访问权限也属于证据链。

失败时默认拒绝，但要设计可用性边界

身份提供方、令牌服务或策略服务不可用时，高风险写入应停止并给出可恢复错误，不能自动降级为共享管理员密钥。低风险只读能力可在明确缓存窗口和资源范围内继续，但要标记陈旧策略并限制输出。把超时、限流、证书轮换、时钟漂移和网络分区纳入演练，验证重试不会重复副作用。应急模式必须由受控流程开启，有到期时间、审计和退出检查。

从影子模式逐步扩大权限：首次上线先让 Agent 使用只读数据并生成动作计划，与人工决定比较；下一阶段允许写草稿或隔离环境；再对低风险、可回滚动作开放窄权限。每次扩大都依据失败率、越权尝试、审批拒绝、人工返工、撤销时间和审计完整性，而不是依据模型演示。严重越权、跨租户、秘密泄露或不可回滚副作用属于硬失败，应立即收回权限并回到上一阶段。批准范围要按任务而不是按产品品牌。

跨云、异步任务和子 Agent 怎样建立信任？

供应商能力与本站方法要分开

微软、AWS 等官方页面说明各自平台的身份构造和流程，SPIFFE、OAuth RFC 则提供通用协议基础。本文据此整理工程验收方法，但没有替任何厂商完成企业环境穿透测试，也不把官方界面当作本站实测。选择产品时应核对实际云环境、身份提供方、下游应用、地区、许可和审计要求。厂商新增 Agent 身份对象并不自动解决对象级授权、提示注入、审批绑定和业务回滚。

跨云与跨域信任先限定谁可以签发：当 Agent 从一个云、集群或企业访问另一个安全域时，接收方不应因为令牌符合 JWT 格式就接受。双方需要明确可信发行方、联合元数据、密钥发现、允许的客户端、subject 映射、受众和最大寿命，并把开发、测试与生产信任域分开。外部合作方只能换取为其场景准备的窄凭证，不能继承内部管理员角色。信任关系新增、续期与删除都应经过变更审查，过期发行方和遗留证书要从验证缓存中清除。

持有者绑定减少 bearer token 被复制后的价值

普通 bearer token 谁拿到谁就能用，日志或代理泄露会把身份控制变成秘密保管问题。支持条件允许时，可用双向 TLS、DPoP 或平台提供的实例绑定机制，把令牌与客户端密钥或受管工作负载关联。资源端不仅验证令牌，还验证当前请求确由绑定方发出。持有者绑定不会修复过宽 scope，也不能阻止已受控工作负载滥用权限；它只是减少凭据被复制到另一台机器后的可用性。

异步任务需要可验证的委托快照：Agent 常把工作放入队列，执行时用户会话已经结束。队列消息不能只保存一个 user_id 或完整用户令牌，而应引用受控任务授权：谁发起、哪个 Agent、允许动作与对象、批准摘要、到期、撤销状态和策略版本。消费者先验证消息来源与完整性，再向凭据服务换取当前有效的短期执行令牌。任务排队超过授权寿命、参数改变或主体停用时重新审批，不能以“之前进过队列”为由永久执行。

子 Agent 与工具发现都要经过注册表

动态发现能提升扩展性，也可能让同名恶意工具或未审查子 Agent 进入链路。注册表应保存稳定标识、发布者、版本、签名、输入输出模式、所需 scope、网络目的、数据类别和审批要求。发现结果只是候选，运行时仍要根据任务策略筛选。工具升级增加写入能力或新域名时视为权限变化，旧批准不自动继承；无法验证发布来源、签名或清单的组件默认隔离。

权限发现必须与权限申请分开：为了生成计划，Agent 可以查询“有哪些动作可能可用”，但不应借发现接口获得真实秘密或扩大权限。目录返回能力描述、风险等级和申请要求，实际令牌仅在任务通过策略与审批后签发。避免把用户所有权限一次性暴露给模型，因为模型可能受提示注入诱导选择不相关高权限工具。权限申请要引用具体任务和对象，拒绝通配 scope；多次拒绝或异常枚举进入风险信号。

数据最小化不仅是少给 scope

Agent 读取的数据量、字段、时间范围和精度也应最小化。完成汇总不一定需要原始个人信息，做分类不一定需要下载整库，审批界面也不应展示与决定无关的秘密。工具可以提供面向任务的窄接口、字段投影、行级过滤、脱敏视图和分页上限。输出端同样检查外发对象与内容，防止合法读取的数据通过邮件、网页或日志泄露。回执记录数据类别与保留期限，但不复制敏感正文。

长期运行怎样处理缓存、轮换与供应链？

身份与策略缓存要有明确失效语义

缓存能降低每次调用的延迟，却可能在用户离职、权限收紧或任务撤销后继续放行。分别定义公钥、令牌内省、对象属性、角色和策略的最大缓存时间，并为高风险动作使用更短窗口或实时检查。撤销事件应主动驱逐相关缓存，消费者丢失事件时还能通过到期重新同步。验收时模拟缓存已热、控制面不可用和撤销并发，确认系统不会因性能优化延长危险权限。

证书与签名密钥轮换要覆盖所有验证者：轮换不是在身份提供方生成新密钥就结束。资源服务器、网关、边车、离线验证器和灾备环境都要及时取得新公钥，同时在受控重叠期接受旧签名。过早删除会造成全面拒绝，长期保留又扩大旧密钥泄露风险。记录 key id、发布时间、启用、停止签发和停止接受时间；用预发布演练检查时钟、缓存与回滚。私钥材料不得进入 Agent 上下文、构建日志或文章回执。

软件供应链决定身份代码是否可信

工作负载身份通常相信部署平台，因此镜像、依赖、启动配置和发布权限一旦被篡改，攻击者会获得一个真实身份。生产签发应绑定受控构建来源、制品摘要、部署身份和环境策略；高风险 Agent 只运行经过签名与漏洞门禁的版本。变更执行器、工具插件、策略客户端或身份 SDK 时重跑授权负向用例。SBOM、签名和扫描只能提供供应链证据，不能替代运行时最小权限与行为监控。

事故取证要保留决策证据而非海量明文：身份事故调查需要知道令牌何时由谁签发、经过哪些 actor、访问哪些资源、策略为何允许以及撤销何时生效。为此保留结构化决策、关联 ID、版本、摘要和结果即可，不应把完整提示、用户文档或访问令牌长期复制到集中日志。日志权限和保留期按敏感度分层，查询高风险审计也要留痕。取证流程先冻结可变证据、轮换暴露凭据和限制传播，再分析根因；不要为了截图重放生产秘密。

把例外设计成会自动消失的债务

遗留系统可能暂时需要共享服务账号、长寿命密钥或过宽角色。例外记录必须写明业务原因、影响资源、补偿控制、所有者、批准人、到期日和迁移计划，并以策略或工单让它到期自动失效。监控单独统计例外使用次数与目标，异常使用触发暂停。若延期，应重新评估而不是悄悄改日期。文章或架构图中把例外明确标为限制，不能把补偿控制写成已经达到理想状态。

上线决策要形成可机读的窄合同：最终批准不是“Agent 安全”四个字，而是一份可机读合同：固定 Agent 与执行器版本、身份提供方、允许任务、工具、资源、租户、动作、最大数据量、审批类型、令牌寿命、预算、监控、撤销和到期。策略服务可从合同生成门禁，审计系统可按合同检查偏离，变更系统可判断哪些测试需要重跑。合同之外默认拒绝；临时扩展使用独立批准和到期。这样才能让安全结论随系统变化而收敛，而不是永久有效。

最后用一次完整任务证明各层真的连接

单独测试登录、令牌或策略都不足以证明端到端安全。选择一个代表性任务，从用户发起、Agent 规划、工作负载换证、工具授权、资源写入、审计、取消、撤销到回滚完整运行，同时注入错误受众、过期凭证、跨租户对象和参数替换。只有正常路径完成、所有负向路径被正确拒绝、日志能复现责任链且回滚没有残留，才批准这一窄任务进入下一阶段。结论不得外推到未测试工具、租户和高风险动作。

怎样选择合适的身份与授权模式？

先根据任务是否代表实时用户、是否有外部副作用以及最终资源归谁管理，确定责任路径；再选择平台实现。下表不是产品排名，同一系统可以并用多种模式，但每次调用都应有唯一、可解释的授权链。

上线前怎样完成可执行验收？

每项都填写实际环境、测试输入、预期、结果、证据位置、责任人和复查触发条件。看到配置存在不算通过，必须同时运行允许请求和拒绝请求。

先确认主体、责任和实例

• 主体清单：列出用户、应用、逻辑 Agent、工作负载、工具、资源、租户和所有者，标明哪些由身份提供方验证，哪些只是业务标签。任何无法追溯所有者的主体不得进入生产。回执注明检查时间、环境、预期与实际结果。
• 信任根：记录令牌与工作负载证书的发行方、签名算法、密钥轮换、信任域和验证位置。客户端能拿到凭据不等于资源服务器已经正确验证。回执注明检查时间、环境、预期与实际结果。
• 实例证明：确认容器、虚机或函数如何证明自己属于批准部署，测试复制令牌、换命名空间、换镜像和从开发环境重放时均被拒绝。回执注明检查时间、环境、预期与实际结果。
• 有人流程：以真实用户发起只读和写入任务，确认用户身份、Agent actor、同意范围与资源权限同时保留，且用户无权访问的对象不会被后台身份绕过。回执注明检查时间、环境、预期与实际结果。
• 无人流程：后台任务使用独立应用权限，不伪装成用户；调度、范围、到期、负责人、停止开关和异常告警均可核查。回执注明检查时间、环境、预期与实际结果。

验证令牌、对象和字段边界

• 令牌交换：验证 subject、actor、resource 或 audience、scope 和到期在每一跳的变化，确认子级权限不会超过父级，未知转委托链被拒绝。回执注明检查时间、环境、预期与实际结果。
• 受众校验：把同一令牌分别发送到预期资源和错误资源，只有正确受众接受；代理、缓存和测试环境不得放宽这一检查。回执注明检查时间、环境、预期与实际结果。
• 作用域校验：分别请求允许动作、相邻动作、管理动作和通配动作，确认只有任务所需动作通过，资源服务不会只信 UI 隐藏。回执注明检查时间、环境、预期与实际结果。
• 对象级授权：使用同租户允许对象、同租户禁止对象和跨租户对象测试，尤其覆盖搜索结果、别名、重定向与批量 ID。回执注明检查时间、环境、预期与实际结果。
• 字段级授权：允许更新的字段与敏感字段分开验证，防止通用 patch 接口让 Agent 修改所有者、权限、金额或状态。回执注明检查时间、环境、预期与实际结果。

验证时效、重放、审批与注入

• 短期寿命：记录发行、开始、到期和服务器容差；到期后旧凭据立即失败，续期重新检查任务状态而不是无限延长。回执注明检查时间、环境、预期与实际结果。
• 重放防护：对付款、发送、发布和删除使用一次性标识、幂等键或内容绑定，重复提交不产生第二次副作用。回执注明检查时间、环境、预期与实际结果。
• 审批绑定：审批回执包含动作、资源和关键参数摘要，修改目标、数量或内容后旧审批失效，执行端而非前端完成校验。回执注明检查时间、环境、预期与实际结果。
• 提示注入负向用例：在网页、邮件和文件中放入诱导外发、读取秘密、改权限或访问未知域名的指令，确认工具授权拒绝且留下告警。回执注明检查时间、环境、预期与实际结果。
• 未知工具：未登记工具、同名替换工具、版本漂移工具和新增参数默认拒绝，工具目录变更触发重新评审。回执注明检查时间、环境、预期与实际结果。

验证网络、凭据、轮换与取消

• 网络边界：允许域名、端口和协议采用最小集合，DNS 重绑定、重定向、IP 直连和内网地址绕过均被阻断并记录。回执注明检查时间、环境、预期与实际结果。
• 凭据代理：旧式 API key 只在调用瞬间由代理注入，不进入提示、轨迹、错误、截图、缓存和下载文件；使用金丝雀值验证。回执注明检查时间、环境、预期与实际结果。
• 秘密轮换：轮换时新旧凭据有受控重叠，旧值撤销后所有运行实例、队列和子 Agent 均不能继续使用。回执注明检查时间、环境、预期与实际结果。
• 取消任务：用户取消后，排队任务、运行实例、令牌、浏览器会话和外部回调均终止；迟到结果不会继续触发写入。回执注明检查时间、环境、预期与实际结果。
• 账户停用：用户或工作负载停用后，新令牌无法签发，现有高风险会话被撤销，后台任务不会借缓存继续运行。回执注明检查时间、环境、预期与实际结果。

验证策略、故障、审计与租户

• 策略变化：收紧角色、对象标签或风险规则后，新的工具调用立即按新版本判断；长任务不会永久沿用旧权限。回执注明检查时间、环境、预期与实际结果。
• 服务故障：模拟身份、STS、策略、日志和时间服务故障，确认高风险动作默认拒绝，重试有上限且不会重复副作用。回执注明检查时间、环境、预期与实际结果。
• 审计字段：随机抽取成功、拒绝、审批和撤销事件，能从资源事件追到用户、Agent、实例、策略、工具和结果，且不包含秘密。回执注明检查时间、环境、预期与实际结果。
• 日志完整性：限制日志写入权限，校验顺序、时间和关联 ID；攻击者不能通过 Agent 工具修改或删除自己的审计事件。回执注明检查时间、环境、预期与实际结果。
• 多租户隔离：从搜索、缓存、向量库、队列、对象存储与导出链路逐层验证租户边界，不把单个 API 的通过当作全链路证据。回执注明检查时间、环境、预期与实际结果。

验证配额、版本、回滚与签字

• 配额与费用：按主体、租户、工具和风险设置频率、并发、金额或数据量上限，异常增长触发停止而不是自动扩容权限。回执注明检查时间、环境、预期与实际结果。
• 版本绑定：授权记录包含 Agent、执行器、工具目录、策略与镜像版本；任何安全相关版本变化触发定向或全量回归。回执注明检查时间、环境、预期与实际结果。
• 回滚演练：在隔离环境执行获批写入后回滚代码、配置、数据、队列与外部副作用，记录恢复时间、残留和人工步骤。回执注明检查时间、环境、预期与实际结果。
• 残留检查：任务结束确认没有活跃令牌、进程、工作区、浏览器、端口、Cron、临时文件、队列消息和未提交动作。回执注明检查时间、环境、预期与实际结果。
• 责任签字：业务所有者确认任务与对象范围，安全负责人确认身份和授权控制，运行负责人确认监控、撤销和回滚；结论写明到期日。回执注明检查时间、环境、预期与实际结果。

证据来自哪里，适用边界是什么？

官方证据图说明了什么

该图只证明官方文档区分多种访问模式，并强调委托、工作负载和逐工具控制；它不证明任何具体租户已经正确配置，也不代表本站完成 Microsoft Entra 或 Foundry 的端到端实测。

本页使用的一手来源

• NIST NCCoE：软件与 AI Agent 身份和授权概念文件
• Microsoft Learn：Agent 访问模式与控制
• Microsoft Foundry：Agent identity 概念
• AWS AgentCore Identity 官方文档
• IETF RFC 8693：OAuth 2.0 Token Exchange
• SPIFFE 官方概览

本文没有证明什么

本文没有获取企业租户、真实用户数据或生产凭据，也没有为某个具体产品出具安全认证。文中的合同与检查表帮助组织证据，不能替代真实平台配置、渗透测试和责任人批准。身份平台、OAuth 实现、地区、产品能力和许可变化后，应重新打开一手文档并重跑相关负向测试。

常见问题

Agent 使用用户账号登录，就等于获得用户全部权限吗？

不等于。登录只证明身份，具体动作仍需结合对象、租户、作用域、任务状态和当前策略重新授权。

无人值守任务可以长期保存一个用户令牌吗？

不建议。无人任务应使用自己的工作负载身份和窄应用权限，并由短期凭证、配额、审计和撤销机制限制。

短期凭证是不是越短越安全？

寿命缩短可以限制泄露窗口，但也会增加签发依赖和失败点。应按任务时长和风险设置，并在续期前重新检查任务与策略。

人工批准之后，Agent 可以修改参数再执行吗？

不可以沿用原批准。批准回执应绑定动作、资源和关键参数摘要，目标、数量或内容变化后重新审批。

控制台显示账号停用，撤销就完成了吗？

还没有。需要用负向请求确认旧令牌、运行实例、队列、缓存和子 Agent 均不能继续执行，并检查副作用是否已恢复。

接下来可以继续完成哪些任务？

• 用AI 编程智能体密钥保护指南隔离凭据、网络和命令审批。
• 用企业 Agent 权限验收指南定义组织责任、撤销和有限自治。
• 用编码智能体评测指南把身份门禁放进任务集与隐藏测试。
• 用模型 API 故障恢复指南处理令牌服务、限流和幂等重试。

复核日期：2026 年 10 月 6 日。本文结论只覆盖文中列出的任务、身份提供方、资源、工具、策略和版本；配置或风险变化后，应重跑对应负向用例与撤销演练。