智能体的最小权限怎样落地？使用独立身份、细分权限、短期凭证和高风险操作确认

先看结果：共享账号能做47类操作，最小权限改造把764个危险沙箱操作降到0

衡川制造让采购支持智能体读取供应商资料、发票和采购申请，抽取字段、检查缺件、生成采购单草稿，并协助处理供应商银行账户变更。初版智能体使用团队已有的服务采购共享账号：它横跨供应商主数据、采购、应付、文档、邮件和分析6个系统，拥有47项有效权限，其中18项可写、9项可导出或管理；同一长效机密同时装在开发、测试与生产运行者。

团队构造1,800个授权决策：900个低风险合法请求应直接允许，300个高风险合法请求应进入独立审批，600个跨租户、对象错误、目标系统错误、过期重放或未经批准的请求应拒绝。旧系统正确处理840+32+104=976例，即54.22%；60个正常请求被误拒，268个本应审批的操作被直接允许，另有496个本应拒绝的请求也被接受。所有写入都只在沙箱环境执行，没有触碰真实供应商或付款。

改造不是把47项权限换成一个更复杂的角色。每个生产工作负载都有独立身份；任务开始时只取得读取当前供应商、读取关联发票和创建当前案例草稿等3至6项能力；访问令牌限定目标系统、租户、案例、资源和权限范围，最长10分钟。银行变更由智能体提出，但不能由智能体执行；完成供应商回拨和双人批准后，专用的确定性执行器才能取得绑定变更哈希的一次性执行意图。

18个误拒来自资源归属同步延迟，4个状态未知来自授权服务超时，均安全转人工但计入可用性缺陷。本文公司、账号、任务、1,800次决策、权限、时间和结果均为虚构教学案例；它证明一套设计在指定套件中的表现，不代表任何真实组织或产品已经安全。

旧账号的危险不只在权限数量。它的长期机密可以被任一执行进程用来调用6个系统，资源服务器看不到任务和业务用户，夜间批量调用与正常采购操作还使用同一身份主体；即使安全运营中心发现异常，也只能整体停掉采购自动化。新设计把读取、提议、批准和执行分开后，可以只撤销某个部署修订、某类能力或一个工单意图，同时保留无关的只读任务。这种可收窄、可定位、可撤销，才是最小权限的运行价值。

最小权限不是“只给读取”：要同时约束谁、代表谁、对什么、做什么、为什么和多久

NIST把最小权限定义为只允许用户或代表用户的进程获得完成指定组织任务所必需的访问。对智能体而言，“采购角色”“可用ERP”或“只读”都太粗：读取可能跨供应商枚举和批量导出，写入可能只是当前案例草稿，也可能改变收款账户。

最小是针对一个具体任务求出的权限交集，不是永久角色的最小值：用户本人的权限、智能体产品获批能力、当前任务合同、资源属性、风险政策和实时状态都必须允许，最终才能执行。任一集合收窄都应立即生效；模型在参数里写“经理已批准”不能扩大交集。

可以把一次决策写成概念式：有效能力=人工授权∩工作负载能力∩任务范围∩资源策略∩当前条件。交集为空就是拒绝；需要外部决定才能成立就是“需要审批”；身份、策略或资源状态取不到就是状态未知。这个公式不是让模型计算，而是迫使工程团队指出每个输入来自哪个权威系统、缺失时如何失败，以及结果最终由哪个目标系统执行。

本文聚焦身份、授权和凭证生命周期。E17已讲工具契约，E18已讲系统集成，E24已讲审计链，E26已讲提示注入。本篇会引用这些边界，但主要交付是可执行权限矩阵、令牌/意图结构、负向授权套件和收权运行手册。

先把身份链拆开：发起人、业务主体、智能体进程、执行器和批准者不是同一个身份

共享账号让日志只剩“服务采购做了修改”，无法回答是哪名员工发起、智能体替谁工作、哪个版本作出决定、谁批准、哪个进程真正提交。设计时至少要列出六类身份主体，并让授权和审计都保留各自标识。

人类身份不能直接借给模型。员工登录会话证明发起人并带来其业务范围，工作负载身份证明哪个部署正在运行；委托记录工作负载代表哪名用户/任务行动，但智能体既不是员工本人，也不自动继承员工全部权限。批准者身份从隔离的审批会话取得，不从聊天文字取得。

身份还要区分环境、应用与功能。复核智能体的开发环境、复核智能体的生产环境和供应商主数据执行器的生产环境是不同身份；一个读取资料的智能体不能因为同属“采购AI”就继承付款执行器。身份目录保存负责人、环境、用途、允许访问的目标系统、部署证明、创建与到期时间、最后使用时间和撤销状态。

账号生命周期要与产品生命周期同步：部署创建时由基础设施注册身份主体，只有签名修订版可以取得证明；连接器下线时，先停止签发新凭证，再清空队列、等待或终止传输中的执行意图、撤销信任关系，最后关闭身份。负责人离职、代码仓库归档、90天无使用或环境删除，都触发复核。只删除应用界面却保留服务主体，会留下无人知道用途的“机器员工”。季度复核时，系统负责人应看到实际调用和资源，而不是在47项权限清单上机械点选“继续”。

从30天调用与变更记录盘点权限：先找真实需要，再删除“也许以后会用”

身份与访问管理系统导出的47项权限只是静态声明，团队还要对照30天接口追踪、数据库变更、审批记录和人工运行手册。22项曾被共享账号使用，其中14项属于已批准的智能体范围，8项其实属于运维或人工审批；25项从未使用。未使用不自动等于可以删除，但必须由负责人给出对应任务和复核日期，不能因为情况不明就无限保留。

盘点单位是权限原子：系统、资源类型、操作、字段、条件和影响。供应商读取若能返回全部银行字段，就不等同于普通供应商档案读取；搜索若可使用通配符跨租户，也不是普通读取。实际接口没有细粒度能力时，就用受控适配器只暴露窄查询，而不是把后端的宽权限令牌交给大语言模型，再靠提示词要求它克制。

每项保留权限都要绑定业务能力、负责人、数据分类、最大资源范围、调用量、可逆性、批准方式、失效时间和拒绝类测试。连续30天未使用就触发复核，但不自动删除值班所需的应急能力；紧急访问必须与日常身份分开，不能成为“偶尔可能要用”的理由。

追踪分析要处理“低频但必要”和“误用造成的高频”两个陷阱。月底结算权限可能30天只出现一次，需要用12个月流程日历和运行手册补充证据；反过来，共享账号频繁调用批量供应商搜索，并不代表智能体真的需要，可能只是旧代码先全量拉取、再在本地筛选。对每个权限原子都准备允许样本、拒绝样本并访谈业务负责人，最后明确作出“保留但收窄”“移交人工”“删除”或“继续调查”的决定；继续调查必须有截止日期，不能无限延后收权。

用能力矩阵代替大角色：同一任务中读取、草稿、提交和付款必须拆开

团队把14项真实需要重构为12个窄操作；单个任务不会同时拿到全部12项。矩阵由业务负责人、系统负责人和身份与访问管理团队共同签署，工具注册表只是它的使用方。下面是银行变更复核任务的已填版本。

“允许”“仅草稿”“需要审批”和“能力不存在”都要有机器可执行的语义。模型没有看到供应商银行更新工具时，仍可能在文本中提出建议，但不能产生实际影响；网关也会拒绝它伪造的操作名。若把创建、更新和删除重新塞进一个通用供应商工具的操作字段，权限就又被合并，矩阵也会失去执行力。

复用模板至少包含能力编号、身份主体、任务类型、资源选择器、允许字段、操作与影响、前置条件、审批类别、凭证有效期、目标系统、速率与数值限制、证据、负责人、复核日期和紧急停止开关。先从一个高风险任务填完整，不要从全企业角色目录开始。

矩阵发布前还要反向检查组合权限。单项的发票读取、供应商读取和外部消息草稿看似低风险，组合后却可能把银行资料发到外部；案件备注创建与后续自动执行器组合，也可能通过持久内容间接触发操作。把可以同时出现的能力画成集合，标出数据来源到外泄出口、提案到实际影响的路径；危险组合要么永不下发给同一身份主体，要么由网关在运行时按目的互斥。最小权限不只是逐行变窄，还要避免多项窄权限合成宽能力。

完整实例：智能体提出银行变更，凭证只在双人批准后的执行器中出现10分钟

09:04，采购分析员P-318在案件 CR-1842上传供应商V-2045的银行变更资料。任务服务从认证会话取得发起人、租户、供应商和目的；复核智能体获得8分钟读取令牌，只能访问V-2045的掩码银行摘要、关联的3张发票和案例文档，不能查询其他供应商或明文历史账号。

智能体生成提案时保留新账号的加密引用和哈希，不把明文放进提示词、日志或审批通知。M-044核对供应商身份、字段差异和材料，T-019独立核对回拨及付款风险；任何人修改目标、账号或证据都会改变哈希并使既有批准失效。

09:17真正调用供应商主数据系统的是不含模型的专用执行器。它用工作负载身份向意图服务换取只对供应商主数据有效的一次性凭证，服务端再次验证租户、资源V-2045、操作、哈希、旧版本v38、两份批准、过期时间，以及唯一令牌编号没有使用过；验证成功后返回回执。智能体从未看到该凭证，也不能把它转交给另一智能体。

对照失败案例把资源换成V-9901，或把操作换成付款放行。即使复制全部批准文本，执行意图的哈希、资源和目标系统仍然不匹配，因此分别返回“资源拒绝”或“操作拒绝”，同时不泄露目标是否存在。若09:26后才执行，则返回已过期，并重新检查当前状态与批准，不能延长原令牌。

这个实例还模拟了三条失败路径。09:14若供应商主数据从v38变为v39，旧提案立即过期，系统重新读取差异并让两名批准者复核；09:16若T-019拒绝，意图服务只记录拒绝结果，不签发任何凭证；09:17若目标接口超时，执行器先用意图编号查询操作状态，得到“状态未知”时冻结该案例，不能更换唯一令牌编号后盲目重试。每条分支都保留可恢复的业务动作，不能把“拒绝”当成流程终点，再让员工自己猜下一步。

每个工作负载有独立、可轮换身份：环境、功能和部署证明都进入注册

静态客户端密钥一旦被复制进容器、持续集成变量和调试脚本，就很难知道哪个副本还在使用。生产工作负载应通过平台证明取得身份，例如基于受信运行环境、服务账号、证书型工作负载身份或同等机制；具体产品不是关键，关键是凭证代理能够验证调用实例确实属于已注册部署。

SPIFFE的工作负载接口是实现参考之一：工作负载可以取得SPIFFE身份，以及短期证书或签名令牌；这说明没有必要把长期共享机密写入应用配置。但采用SPIFFE并不会自动提供业务授权，它只能证明“这是哪个工作负载”，仍要由策略决定该工作负载能否代表P-318读取V-2045。

身份粒度也有成本。若给每个临时子进程都建立一个永久身份对象，治理会变得困难；可以按稳定部署功能建立工作负载主体，再把任务与资源放进短期授权上下文。相反，把所有采购智能体合成一个身份主体，又无法独立撤销。粒度应由最大影响范围、负责人和部署边界决定，并通过故障演练验证。

工作负载证明也不能只在启动时做一次。调度器可能把镜像迁移到错误环境，负责代理调用的旁路组件可能失联，旧修订版也可能在回滚后继续运行；凭证代理在每次签发时，都要验证环境、命名空间与服务账号、镜像与修订版，或组织选择的同等属性，并把结果写入签发事件。证书自动轮换要演练重叠窗口、时钟偏差和旧证书拒绝：切换过快会让大量合法任务变成状态未知，重叠过久又会延长被盗密钥的可用期。

委托不同于冒名顶替：保留“智能体代表谁行动”，不要把智能体伪装成人

冒名顶替让下游只看到业务用户，容易丢失自动化执行者；委托同时保留业务主体与执行方，更适合证明P-318发起、复核智能体实际行动。并非所有系统都支持标准委托，不能用令牌交换包装后就假设这些语义已经成立。

RFC 8693定义了OAuth令牌交换，可以表达主体令牌、可选执行者令牌，以及资源、目标系统和权限范围；它也明确说明，交换本身不会自动撤销输入令牌，撤销如何传播取决于具体实现。因此，本文只用它说明委托字段，不能把“使用了令牌交换”当成单次使用、实时撤权或最小权限的证明。

代理在每一跳都验证：执行者是否被允许代表业务主体、原主体是否仍有效、目标资源是否接受这种委托、权限范围有没有扩大、委托链深度是否超限。下游审计保留完整执行者链；用户离职、案例关闭或委托被撤销时，停止签发新令牌，并让高风险执行意图失效。不能让智能体自己在令牌声明中填写操作或主体。

委托策略还要区分“用户有权做”与“用户有权让智能体代做”。P-318可以在原系统人工查看某些供应商字段，不代表任意自动化工作负载可批量读取；反之，组织级夜间校验任务可能不代表某个当前用户，而代表明确的业务权威。两者分别建模，避免把人类宽权限无条件向智能体下传，也避免为了自动任务虚构一名永远在线的员工。

短期凭证还要限制目标系统、资源和范围，并绑定持有者：有效期短不等于不能被盗用

10分钟只是本案例门槛，不是通用最佳值。有效期要覆盖单次调用与合理时钟偏差，但应明显短于任务生命周期；任务较长就重新评估并换取新令牌，而不是发放8小时凭证。令牌至少要限制签发方、业务主体与执行者、目标系统、权限范围、租户与资源选择器、生效时间、过期时间、令牌编号和策略版本，敏感写入还要绑定意图哈希。

RFC 9700说明，目标系统受限的令牌应由资源服务器验证令牌指定的目标，也列出双向传输层安全和请求证明两类发送方约束方法。RFC 8705的证书绑定令牌要求调用方持有对应私钥才能使用令牌。系统若支持，可以采用这些机制或同等的持有证明，降低令牌单独泄露后的可用性；若攻击者同时控制工作负载和私钥，这一层仍会失败。

资源服务器不能只验证签名和有效期；还要验证签发方、目标系统、权限范围、资源、执行者与主体关系、当前策略和业务对象。采用不透明令牌并实时查询，还是采用自包含签名令牌，取决于撤权时效、依赖可用性和隐私要求；无论哪种方式，都不应把敏感账号、长篇证据或完整权限表塞进可能被各层记录的令牌。

有效期要用实际调用数据计算。若99分位的单次接口耗时为6秒，凭证代理和时钟允许30秒偏差，那么2分钟读取令牌已经足够；若审批后写入通常在40秒内完成，10分钟是保守上限，不代表令牌从任务09:04开始就连续有效22分钟。令牌临近到期时不能由软件工具包静默延长，执行器要重新请求，并让策略看到最新案例状态。各服务使用统一时间源并对异常时钟偏差告警，否则一边已判定过期、另一边仍然接受，就会破坏停止时限。

凭证在执行边界即时取得：不进入提示词、记忆、追踪、队列或模型工具参数

凭证代理只接受经过认证的工作负载与结构化任务上下文。策略允许后，凭证只交给实际调用组件；模型收到的仍只是工具名称和业务字段。把访问令牌写进提示词、让工具结果回显机密，或让智能体长期记忆保存会话信息，都会绕开最小权限的生命周期。

执行进程崩溃后，不能从检查点恢复旧令牌，只恢复任务状态并向代理重新请求；代理重新检查案例、身份主体、策略和批准。重试继续使用同一业务意图和幂等键，但凭证可以更新，避免把安全身份生命周期与业务幂等混为一谈。

开发调试同样不用生产机密。提供合成系统与假账号；若必须诊断生产，受控支持会话由人申请、短时、只读并完整审计。任何密钥扫描器命中提示/追踪/队列都按凭证泄露处置：停止发行、撤销/轮换、范围查询和验证未授权调用，而不是只删日志。

间接句柄也要防止变成永久钥匙。任务中可以保存凭证请求编号，但代理只把它当作关联标识，不能凭这个字符串再次取得关键令牌；重新签发仍需要当前工作负载证明和完整策略输入。工具错误不能原样返回令牌，调用组件要把授权信息与业务回复分离，异常堆栈只记录签发方、目标系统和唯一编号的哈希。可以定期在提示词、追踪、对象存储和失败消息队列中放入无价值的合成诱饵，验证扫描与告警链，但绝不能用真实生产凭证做探针。

策略必须由凭证代理、网关和资源服务器执行：模型和工具描述都不能授权

模型可以提出候选操作，编排器可以选择流程，但最终决定必须由确定性策略执行点作出。凭证代理决定是否签发，网关校验数据结构与字段来源，资源服务器掌握真实资源和状态并再次授权；任何一层不可用时，高风险写入都返回状态未知，而不是默认允许。

决策结果至少包括允许、拒绝、需要审批和状态未知，并附原因代码、策略版本、已评估资源、凭证或意图编号和追踪记录。拒绝时不返回可被枚举的对象详情；状态未知时也不能诱导智能体不停更换参数。授权缓存的键必须包含身份主体、业务主体、租户、资源、操作、目的和策略版本，写入操作不能使用过期的允许缓存。

网络白名单、虚拟私有云或“只在内网”不是授权。NIST SP 800-207强调不因网络位置或资产归属给予隐式信任，并在建立资源会话前分别做认证和授权。内网智能体仍可能被提示注入、配置错误或凭证泄露，资源服务器必须守最后一跳。

三处执行要有一致的契约测试，但不必返回相同细节。代理拒绝不合格身份，网关拒绝错误数据结构和字段来源，资源服务器拒绝最终对象或状态；测试应故意让上游漏拦，证明最后一跳仍安全。相反，不能因为资源服务器会守住就省掉前两层：宽权限令牌会到达更多网络和日志，模型可以反复探测，旧版端点也可能没有同等策略。纵深防御的每一层都在减少不同的暴露面。

资源级、字段级和条件授权解决“有权限但改错对象”：角色权限只是起点

基于角色的访问控制可以表达采购分析员和复核智能体的大范围职责，却难以表达“只允许本案例中的V-2045”“地址字段只能生成草稿”“银行字段必须双人批准”“旧版本必须是v38”。因此要在角色基础上再结合资源、属性、关系和策略条件，不必拘泥于某一种缩写体系。

字段来源也必须进入策略：目标供应商来自任务绑定，银行账户来自加密材料提取并由人核对，审批人来自决策服务。外部文档不能指定目标、接收方、角色或批准状态。金额、记录数、时间窗口、地理与设备风险、案例状态和职责分离都可以成为条件，但条件越多，就越需要解释、测试和明确的故障策略。

资源过滤必须在服务端发生。先取全表交给智能体，再让它“只看V-2045”，数据已经泄露；搜索接口同样必须强制使用租户与案例选择器，并限制字段和结果数量。行列级控制失败，不能依靠输出端的数据防泄漏工具补救。

策略变更与资源变更之间存在“检查时合法、执行时已变”的时间差风险。智能体在09:05读取的脱敏档案只支持当时的提案；执行前，目标服务要用期望版本重新检查供应商状态、冻结标记和银行变更冷却期。若关系发生变化，就返回前置条件失败和最小必要原因，不能把当前敏感值送回模型。列表接口的每一页也都重新应用过滤器，分页游标必须绑定租户和查询，不能修改游标跳到另一个资源集合。

高风险确认是一次新的授权决定：批准精确对象和差异，不是给智能体永久升权

银行账户、付款、权限、对外发布、批量删除和安全控制等动作，风险不因智能体准确率高而消失。智能体只交付提案；复核界面从权威系统读取当前值，显示目标、执行前后、证据来源、异常、不可逆后果和被拒尝试，批准绑定标准意图哈希。

批准不会给复核智能体增加供应商更新范围；它只让意图服务为专用执行者签发一次对象级授权。批准后参数变化、策略升级、供应商冻结或风险信号出现都会重新判定。人在聊天里回复“可以”或文档写“财务已授权”没有权限语义。

低风险动作不必全部人工确认，否则审批疲劳破坏安全。风险矩阵预先区分读取、内部草稿、可逆更新、外部/财务/破坏性；只有达到门槛才调用对应决策者。人工确认的有效性用拒绝率、修改率、用时、异常捕获和事后撤销衡量，不以点击数量证明治理。

审批界面不得把最关键字段折叠在“查看详情”之后，也不能让智能体用自然语言替事实着色。目标供应商、旧值与新值的安全表示、金额与付款影响、材料来源、回拨结果、模型不确定性和任何策略拒绝，都按固定顺序展示；审批人先看差异，再看智能体说明。批量审批、短时间连续通过、同一人承担多个冲突角色，或从异常设备确认，都会触发升级或暂停。批准者可以要求补材料，但补材料必须生成新的产物和哈希，不能偷偷修改原决定。

职责分离阻止同一身份发起、批准和执行：双人并不等于点击两个按钮

NIST SP 800-53的AC-5讨论职责分离，AC-6要求进程权限不高于完成任务所需。案例据此把P-318发起、M-044主数据审核、T-019财务风险审核、专用执行器执行和审计复核人分开；冲突关系由身份图谱验证，不能只看姓名不同。

两名审批者若共享账号、同一上级代点或只看智能体摘要，仍不是有效双人复核。决策服务记录独立认证、职责、展示版本、决策、原因和时间；审批者能看原始证据的安全视图，并可拒绝/修改/升级。

小团队无法完全分岗时应降低自动权限：例如第二人由集中财务值班承担，或者智能体只生成离线核对包，由现有银行变更流程执行。不能用组织规模作为共享管理员令牌的理由。

职责分离也适用于配置面：编写能力策略的人不能独自发布并批准自己的高风险变更；能管理工作负载身份的人不能同时修改审计保留；事件响应人员的临时扩权，要在事件后由另一角色复核。若一个管理员在技术上可以绕过所有层，就通过变更双签、不可变审计和紧急访问告警降低风险，并把残余集中权限写进风险记录，而不是声称系统已经完全分离。

读取、搜索和导出同样有爆炸半径：最小权限同时控制数据可见性与外发通道

只读令牌可以遍历全部供应商、发票、员工和合同，泄露规模可能大于一次错误写入。读取能力必须限制租户、资源关系、字段、查询方式、页面大小、总记录数和使用目的；高敏字段默认不送入模型，返回掩码或派生值即可。

查询本身可能成为外发渠道，查询结果也可能包含提示注入。网关既检查输入是否携带机密、是否与任务相关，也要对返回结果做字段最小化并保留来源；外部搜索和内部读取令牌不能共处一个通用工具。

使用量门槛不能替代对象授权，但可以限制异常：单个任务最多读取3张关联发票和12份案例文档，超出就转人工；连续访问不同供应商编号、不断翻页或发出高随机度查询时触发停止。合法的大批量工作应走专用批处理作业、独立批准与审计，不能临时放宽交互式智能体。

读取误拒也有业务成本，所以用良性套件验证合同续签、供应商合并、发票转派和跨部门协作等合法关系。关系服务延迟时，不把“暂时查不到已分配”直接改为全租户读取；返回未知来源或转由人从原系统查看。对高敏数据，宁可多一次明确升级；对低敏公开目录，可在风险接受后使用短时缓存，但缓存条目仍带租户、字段集合和策略版本。

长任务、队列和重试不延长旧权限：每次恢复都重算，影响未知时先对账

任务可能等待审批数小时，10分钟令牌自然过期。检查点保存任务、产物哈希、工作流状态和意图引用，不保存凭证；恢复时重新认证工作负载、检查用户/供应商/工单/策略/审批并取新令牌。任务仍存在不代表原授权仍存在。

写入超时且结果状态未知时，执行器用意图编号向目标系统查询回执；只有确认未执行才可以重试，并继续使用同一个业务幂等键。换取新的访问令牌，不能生成第二个业务操作。重复执行、凭证刷新和工作流重试是三个不同的状态机。

长期离线工作若确需用户不存在权限，由业务权限明确授予自主工作负载能力、范围和有效期，不伪装成仍代表一名已离线员工。该身份有自己的负责人、停止开关和复核，不把用户刷新令牌永久交给智能体。

撤权目标要量化：停止某个身份主体后30秒内，代理不再签发新凭证；已有读取令牌最多存活2分钟；高风险的未使用意图立即标为已撤销；已经提交的操作则依靠回执逐项对账。短有效期不能撤回已经发生的银行变更，因此收权运行手册必须区分未来访问、待处理意图、进行中操作和已完成的业务影响。最后一类需要补偿、冻结或人工联系，不能用一句“令牌已经撤销”宣称恢复完成。

多智能体交接传递任务与证据，不传递凭证：接收方按自己的身份重新授权

研究智能体可以读取文档，规划器整理提案，专用执行器提交操作。若编排器把上游访问令牌塞进消息，下游就会继承不属于自己的权限；若只传一句“已授权”，又会丢失业务主体与资源证据。

每个智能体只拥有完成自己步骤所需的身份与目标系统；规划器不能调用供应商主数据，执行器不能自由浏览文档。接收方从可信任务和决策服务重新组装授权上下文，不能相信摘要里的角色、批准或目标。跨智能体的链路深度、允许消息类型和最大范围都有上限，任何一跳都不能扩大原业务主体的权限。

如果下游系统只能接受上游共享机密，就先用适配器隔离：适配器认证各工作负载、强制限制资源与操作，并独自持有后端机密；智能体只面对窄范围契约。长期应推动下游原生支持细粒度身份，但不能因为遗留系统存在，就让凭证进入模型上下文。

跨组织或供应商智能体不能默认接受内部委托链。接收方只信自己配置的签发方、目标系统和联合信任关系，并把外部业务主体映射到本地最小角色；未知主张只能被忽略，不能变成权限。交接产物可以跨边界，凭证不能跨；若确需令牌交换，双方必须明确权限范围映射、撤销联系和日志责任。否则，采用审批后的文件或消息接口，比建立双向高权限信任更安全。

紧急访问和依赖故障有独立路径：紧急不等于让智能体自动获得管理员权限

凭证代理、策略引擎或身份服务故障时，草稿读取可以降级到缓存的低敏资料；银行变更、付款、权限修改和外部发送则必须标为状态未知并停止。业务连续性由人工应急流程承担，不能把“故障时默认放行”藏在软件工具包的降级逻辑里。

紧急访问身份默认禁用，启用时需要强认证、工单、理由、范围、双人批准和很短的有效期；使用后立即告警、逐项复核操作，并轮换可能暴露的凭证。它由人控制，不暴露给模型，也不能成为自动重试的目标。

案例中的4个状态未知来自凭证代理超时：任务转人工且没有造成影响，因此安全，但仍不能计入正确授权结果。服务目标必须同时关注授权可用性与安全；若团队只把状态未知算作“已阻断”，就会掩盖业务实际上无法运行。依赖恢复后，要重放原来的决策输入验证结果一致，不能自动恢复高风险队列。

紧急访问每季度做一次无真实影响演练：验证谁能发起、两名值班者是否收到通知、范围与有效期是否符合模板、智能体是否完全看不到凭证、安全运营中心能否在5分钟内定位，以及结束后是否自动禁用。演练如果要靠临时修改身份权限、在聊天中共享机密，或事后补工单才算成功，说明应急路径本身比正常智能体更危险，应暂停生产中的高风险能力。

用1,800个决策和逐层拆分试验验收：既测越权，也测合法任务是否被错误阻断

600个非法请求包括跨租户120、资源错误120、目标系统错误80、过期或重放80、未批准高风险操作100、敏感字段扩张60、继承或转发凭证40，合计600。每例都定义预期拒绝、禁止影响、原因类别和回执；另有900个低风险允许请求与300个审批请求，防止系统通过“全部拒绝”作弊。

对相同套件做成对拆分试验：A0共享账号有764个审批绕过或禁止影响；A1只改为独立工作负载身份，仍有491个；A2增加操作和资源范围限制后降到187个；A3再加入短有效期、目标系统和发送方限制后降到73个；A4加入对象绑定审批、职责分离和专用执行器后才降为0。各层之间存在交互，差值不能解释成独立因果贡献。

测试还覆盖签名错误、签发方错误、跨环境、唯一令牌编号重放、批准后修改参数、旧版本、撤销、代理超时、回执丢失和日志机密扫描。真实生产资源由模拟接口替代，红队没有取得实际令牌。危险操作为0只表示本套件没有观察到；模型、工具、策略、身份或资源结构发生变化时，都要触发回归和E25所述灰度发布。

生产监测、收权与交付包：权限增长必须可见，撤销必须在演练中真的生效

生产环境按工作负载、任务和操作报告已签发令牌、拒绝、批准、状态未知、误拒、资源广度、有效期、未使用权限、重放、紧急访问和凭证泄露；不能记录令牌正文。关键不只是调用量，而是每个实际影响能否关联到人类主体、工作负载、策略、批准、执行意图和回执。

上线顺序是：合成授权套件→后台对照决策但不签发令牌→只读小组→仅草稿→绑定批准的专用写入。每个阶段都验证身份紧急关闭开关、用户离职、案例关闭、策略更新、证书轮换、代理中断、令牌盗取与重放，以及回执对账；任何跨租户允许、审批绕过、无法撤销，或凭证进入模型数据，都立即退回前一阶段。

交付的最小权限包包括：身份清单、人员—业务主体—工作负载链、47→14权限盘点、12项能力矩阵、凭证代理与令牌配置、审批与职责分离矩阵、目标系统策略、1,800个授权案例套件、凭证泄露运行手册、紧急访问和季度访问复核。负责人要同时签署业务可用性、最大影响和撤销时限，提示词团队不能独自批准权限。

来源边界：NIST SP 800-53修订版5的AC-5与AC-6用于职责分离，以及用户和代表用户的进程都只取得最小权限；NIST SP 800-207用于说明不能因为网络位置而隐式信任，应以资源为中心，并在建立资源会话前分别认证与授权；RFC 8693用于令牌交换中的主体、执行者、资源、目标系统和权限范围，以及交换本身不会自动撤销输入令牌；RFC 9700用于目标系统限制和发送方受限令牌的当前OAuth安全建议；RFC 8705用于证书绑定令牌的持钥约束；SPIFFE文档只作为工作负载标识与短期证书或签名令牌的一种实现参考。这些来源都不提供本案例的47项权限、10分钟、1,800个结果或组织门槛。来源核验于2026-07-21。

• NIST SP 800-53 Rev.5：Security and Privacy Controls
• NIST SP 800-207：Zero Trust Architecture
• RFC 8693：OAuth 2.0 Token Exchange
• RFC 9700：Best Current Practice for OAuth 2.0 Security
• RFC 8705：OAuth 2.0 Mutual-TLS and Certificate-Bound Tokens
• SPIFFE：Working with SVIDs

今天先选一个智能体可能造成真实影响的任务。不要先建立笼统的“AI角色”，而是写出一个具体请求：发起人、业务主体、工作负载、租户与资源、操作与字段、目的、影响、批准、目标系统和最长时限；再从现有追踪中确认真正需要的读取与写入。把高风险写入从智能体身份中删除，改成“提案→独立决定→一次性执行意图”，然后同时运行一条合法案例和一条对象错误案例。若下游只能识别共享管理员账号、目标系统不复核权限范围，或令牌会进入提示词，就先保持读取和草稿能力，不进入生产写操作。