先讲一个我最近常说起的场景纯虚构但类似案例我见过不少某公司上线了一个自动处理客服退款申请的AI助手它每天读取客户工单、核实订单条件再发起退款。某天凌晨它竟然通过了一笔远超授权上限的退款。复盘的时候所有人翻审计日志都沉默了——系统里记录的操作人是一个客服账号而拥有这个账号的员工当天根本没有登录过。真相说出来有点荒诞这个Agent在启动时拿到了客服账号的长期凭证之后一直以一个人的身份在系统里替人干活。用一句话概括Agent已经大规模进入生产系统但我们给它的身份模型还停留在人类静态账号的年代。这几年我帮不少团队梳理过权限和安全体系发现最普遍的问题不是技术选型而是所有人默认身份必须属于一个人。Agent没有人类身份就只能伪装成人类或者被塞进一个没有灵魂的服务账号。这两种做法都有严重的后遗症。这篇文章不聊Agent本身能不能把事做对只聚焦一个问题为什么传统身份模型在Agent时代失效以及用什么思路重建才靠谱。适合正在做Agent产品、或者在系统里接入自动化流程的研发和安全同学参考。1. Agent 到底是谁传统身份模型回答不了的问题1.1 传统身份模型的三个隐含前提在互联网这套身份体系里主体principal也就是系统认为正在操作的那个身份有四个默认前提。第一主体是单一且稳定的一个人、一台设备或一个固定服务不会今天是这个、明天变成那个。第二动作背后有意识任何可审计的操作最终都能追溯到某个做出决定的人。第三权限是预先分配且长期有效的角色一旦挂上默认能用很久。第四授权是一次性的用户点一次同意之后的操作基本都在这个授权范围内进行。这四个前提支撑了从员工系统到互联网服务几十年的运转在人类操作时代确实够用。你登录网银、提交工单、审批流程系统都能把操作映射到某个清晰的人。主体、动作、权限、审计整条链路是一根闭环的线。1.2 Agent 把这套前提全部推翻Agent是程序不受上下班时间影响也不会因为我累了而拒绝操作。更麻烦的是同一个Agent可能会同时为多个用户服务一个日程助手上午帮A安排会议下午帮B整理出差它的身份到底是哪个用户再叠加权限委托链条比如用户授权Agent去访问某个SaaS工具工具又去调用另一个API身份在每一跳都可能被重新解释。结果就是系统问这次操作是谁干的Agent时代根本给不出一个唯一答案。不是日志没记而是概念模型里从来就没有AI执行者这个位置。你给Agent发一个机器人账号它是没有生命周期的你让它借用用户账号它又越过了用户本人的控制边界。怎么选都是错。1.3 一次请求背后其实有四个主体很多团队说我把Agent也当主体不行吗但真正落到一次调用上你会看到至少四个参与者目标用户真正提出需求的人比如帮我把明天会议改到下午两点。Agent本体执行这个需求的那段程序带着上下文和工具清单。工具/API服务被调用的日历、邮件、支付等系统。底层模型决定怎么调用、何时调用的决策者。传统身份模型把所有角色折叠成一个账号等于把审计线索人为烧掉了。门禁卡上的名字写的是张三但真正刷卡的可能是一个替张三跑腿的机器人。安保系统只看到张三进来了却不知道机器人是谁、为什么进来、准备去哪个房间。身份模型的第一场危机就是它没有给AI执行者预留应有的位置。2. 静态授权与动态意图的错配权限不是太大就是太小2.1 RBAC 角色天然假设人会稳定工作基于角色的访问控制RBAC在设计时有一个隐含假设人的职责相对稳定。客服专员就是处理工单财务就是审核报销角色挂上去基本可以管一个月甚至一年。Agent完全不是这样。一个Agent在同一个下午可能经历查一趟车次读用户资料调用支付接口发送邮件四种完全不同的行为而这些行为分别属于四个不同角色。你给它挂客服角色它拥有了太多无关权限你按最小权限拆角色角色数量会爆炸到无法维护。本质上角色的时间粒度和Agent的任务粒度根本不匹配。2.2 OAuth 作用域是按资源类别切的不是按意图切的再往下一层看授权协议。OAuth这类授权方式通常把权限定义成资源类别动作的集合比如calendar:read、calendar:write、files:write。对一个人类用户来说这样足够用户自己会判断什么时候该写日历、什么时候不该写。Agent不行。Agent虽然拿到了calendar:write但它写哪一条会议记录、为什么要写、写到什么程度完全取决于当前任务。传统OAuth的授权发生在任务开始之前而且默认长期有效。用户希望的是只帮我把明天会议改到下午其他日历数据不要碰但授权协议表达不了这么细的粒度。最尴尬的是如果你要求每个动作都重新授权自动化的意义就不存在了如果不重新授权Flag永远打得太开。2.3 最小权限原则在Agent场景下的执行矛盾安全领域常讲最小权限原则每个主体只拥有完成当前任务所必需的权限。但这个原则在人类场景容易操作在Agent场景几乎没法落地原因是任务意图在运行时才知道。拿购票场景举例Agent第一步查车次只需要只读权限第二步填乘车人信息需要写权限第三步跳转支付涉及敏感操作。如果用一套静态权限你只能在预授权一大堆和频繁请求新权限之间二选一。前者违背最小权限后者拖垮自动化。很多团队最后选择了把权限做大用管理成本换实现速度结果就是Agent的权限面越滚越大直到某一天失控。这不是Agent本身的问题是授权模型的时间和意图维度都太粗了。3. 责任链断了审计日志里缺少真正的主体3.1 审计日志的主谓宾缺了谁传统审计日志长这样user_id1001actionrefund.applyresourceorder_8899time2025-03-14 02:10:11。主谓宾齐全看起来没有任何问题。但到了Agent场景这个结构立刻露馅。user_id1001到底是谁的ID如果是客服账号那真正执行动作的Agent是谁如果是Agent账号那背后发起需求的用户又是谁更别说需要记录的任务上下文、模型版本、工具调用链。你可以把这些全部塞进一个扩展段但本质上老数据库表结构没有为多主体联合操作建模。你终于记下了谁做了什么却说不清在谁的授权下、以谁的名义、通过什么推理路径做的。等到要追责时日志就变成一堆填不满的空洞。3.2 模型决策的可解释性缺席就算你把agent_id、run_id都记全了还有一个更扎心的问题Agent的决策来自大模型而模型的推理过程并不天然透明。你问它为什么调用退款接口它可能只会给你一段根据工单内容判断符合条件的模糊描述。所以完整审计必须额外记录几类信息模型版本、本轮任务的输入摘要、用到的检索资料、工具候选列表以及最终选择的理由如果产品允许输出。记录这些不是为了做可解释AI研究而是让安全团队在事故复盘时至少有证据链可看。很多Agent产品现在根本不存这些字段出事只能靠猜。3.3 追责时的经典三问答不上每次安全事件管理层只会问三句话谁授权的谁批准的为什么系统没拦住在传统身份模型下答案极其尴尬。系统日志说操作人是客服账号客服本人说我没干运维说账号没被劫持安全说权限配置符合规范。四个人说的都是真话但没人能负责。这说明事故不是某个人的操作失误而是整个身份链路上缺少可问责的节点。责任链断裂比技术漏洞更危险。技术漏洞可以修责任链断裂会让团队在复盘时陷入无限扯皮最后只能用一个加强监控的结论草草收场。下次同类事故继续发生。4. 为 Agent 重建身份四个可以立刻上手的改造方向先看一张传统模型和Agent就绪模型的对比方便后面展开维度传统账号体系Agent 就绪模型身份主体人类用户或僵化的服务账号Agent本体 on_behalf_of 委托链凭证长期口令/静态Token任务级短命Token运行时动态签发授权粒度角色或Scope粗颗粒Purpose Resource Action 三元约束同意方式一次授权长期有效低危按会话授权高危实时审批审计user_id action timeagent_id run_id model_version 委托人 purpose生命周期账号长期有效每次运行自启动结束后吊销所有临时权限4.1 用委托链替代账号借用第一件事永远不要让Agent把自己的身份伪装成用户。Agent需要拥有一个独立的agent_id同时记录它代表哪个用户做事也就是actsOnBehalfOf。这样资源系统看到的不是一个客服在操作而是AI助手代表用户X做某件事。这条委托链不是形式主义。它让三方各归其位用户负责表达意图和授权范围Agent负责执行资源系统负责根据委托链校验权限。校验时只认agent_id不够只认用户ID也不够必须同时确认Agent是否被允许执行此类操作以及用户是否有权做这件事。两者取交集才能放行。4.2 抛弃永久凭证换成任务级短命凭证Agent接入传统系统时最省事的做法是把一个长期有效的API Token配进去。这个Token一旦泄露等于把整个系统的后门钥匙交给了攻击者。更隐蔽的问题是一张永久Token会让Agent的所有行为都“合法”你根本分不清哪些是任务需要、哪些是逻辑跑偏。改造方向是引入凭证代理Credential Broker。Agent启动时用自己的身份信息向代理申请一张短时TokenToken里只包含本次任务需要的最小权限过期时间控制在几分钟到十几分钟。用完即焚。这样做还有个额外好处每次任务都是一个新的Token审计日志可以精确到哪次运行使用哪张凭证权限回收也不再依赖运维手动清理。4.3 授权策略里加入目的维度传统策略模型是资源 动作Agent场景必须升级成主体 目的 资源 动作。purpose目的字段是这类场景的锚点Agent这次运行到底是“处理退款”、“整理日程”还是“群发通知”决定了它能触碰哪些资源和操作。资源服务方在收到请求时做三方校验用户授权范围、Agent的目的声明、资源自身的策略。三方有任意一方不允许请求直接拒绝。比如一个日程Agent声明purposecalendar.rearrange那它就不该拥有删除整个日历的权限一个退款Agent声明purposerefund.standard那它就绝不能调用审批通过接口——审批是人类的事。4.4 在护栏里让人类保留最终否决权自动化程度越高越需要人为熔断机制。不是说每个动作都要人来点头而是把操作按风险分级低危操作读资料、查列表自动执行中危操作修改文档、发送内部消息允许执行但实时记录高危操作退款、删除数据、对外发送消息必须进入人工审批队列。Agent只能提交申请不能自己批准自己。审批通过后系统发一张临时提升权限的凭证用完立即回收。同时必须提供全局急停开关一旦某个Agent出现异常安全人员可以在十秒内熔断它的所有活动。没有最后一道人形闸门Agent的运行速度越快灾难扩散的速度也越快。5. 最小可实施的改造路径从传统模型迁移到 Agent 就绪5.1 先盘点身份与授权盲区改造不是从零开始而是先摸清现状。你需要回答四类问题现有系统里有哪些Agent在跑每个Agent由哪个团队或哪个负责人维护这些Agent都持有哪些长期凭证凭证能访问哪些系统和API当前Agent能触达的最高权限是什么有没有超出其业务目的的高危权限用户的原始授权是怎么落到Agent身上的有没有经过用户明确的、最小化的确认这个盘点阶段最容易暴露问题。我见过不少团队做完盘点才发现某个Agent的Token居然挂在离职员工名下或者一个只该处理数据分析的Agent拥有管理员的写权限。先看清盲区才知道从哪里下刀。5.2 为每个Agent定义主体与策略建议把Agent的身份信息当作基础设施配置来管理放在代码仓库里走版本控制。每次Agent更新身份策略一起评审、一起发布。一个完整的定义至少包含Agent标识、负责人、代表哪些用户、允许的purpose列表、允许/禁止的资源和动作清单、以及高风险动作是否需要人工审批。策略越明确Agent在运行时的越界行为越容易被发现。5.3 设计Token生命周期与审计结构接着改造凭证流程Agent运行开始 → 向凭证代理申请Token → 获得带有run_id的短时凭证 → 在任务期间携带该凭证调用API → 任务结束立即吊销。所有Token都绑定唯一的run_id后续审计可以直接按运行追溯。审计系统需要同步调整。至少增加以下字段agent_id、on_behalf_of委托人、run_id、purpose、model_version、input_digest输入摘要、tool、action、decision_id。关键业务操作建议长期留存别只放七天的热存储里Agent事故复盘往往需要回看很久以前的行为。5.4 一个参考策略示例伪配置下面是一个简化的Agent授权配置用来演示字段之间的关系{ agentId: agent://acme/refund-assistant-v2, owner: user://acme/zhangsan, runId: run-7f3a11, purposes: [refund.standard, customer.reply], policy: { allow: [ { resource: payment.refund, action: create, risk: high, humanCheck: required }, { resource: user.profile, action: read, risk: low, humanCheck: none } ], deny: [ { resource: payment.refund, action: approve } ] }, credential: { type: ephemeral, issuer: credential-broker, issuedAt: 2025-03-14T00:00:00Z, expiresAt: 2025-03-14T00:15:00Z, scopes: [payment.refund.create, user.profile.read] } }这个配置刻意把发起退款和审批退款拆开Agent可以提交退款申请但审批权限被显式禁止必须走人工队列。credential.expiresAt限定了凭证只有十五分钟寿命即使泄露攻击者拿到的也只是一把短命钥匙。6. 我在一线踩过的几个坑和你会遇到的版本6.1 把 Agent 当成普通用户注册的后果最早做接入的时候我也图省事给Agent开一个机器人账号挂上跟客服一样的角色认为这样就够了。结果几天后Agent在调试时把测试环境的API Key发到了外部服务。问题不是Agent想使坏而是这个机器人账号没有任何任务边界它不知道自己在哪个会话中也不知道哪些行为超出当前目的。后来我们给Agent加上了委托链和任务级凭证权限面一下子收紧了很多。这个教训告诉我Agent身份的第一原则是最小生存周期而不是最小权限。权限再小如果凭证永久有效风险依然存在只有生命周期和任务绑定失控才可止损。6.2 权限越做越大的渐进式失控Agent集成越深业务方就越想省事。最常见的对话是这个Agent只跑一次就删给个写权限临时用一下它只是查数据配个只读管理员就行。一次两次可以理解但半年下来临时例外会堆成一张巨无霸权限网。我现在要求团队做一件事每次给Agent增加权限都必须走审批并且必须填写为什么需要这个权限的说明。系统会自动统计每个Agent的权限增长曲线一旦偏离其核心目的立刻告警。把权限变化变成审计事件之后渐进式失控就变成了可视化失控至少你能在失控之前看到苗头。6.3 如果重新来一遍我会先解决的三件事给每个Agent一个可撤销的、独立于人的主体ID哪怕初期只是打一个标记也要做。把高风险操作的审批队列放在Agent行动链路上不要等操作完成之后才看日志。提前定义好事件的归因字段别等出了事故再去数据库里加列。最后送你一个我自己很受用的小技巧每当系统里要接入一个新的Agent第一件事不是问它需要什么权限而是问如果它完全失控我怎么在十秒内切断它。这个问题能帮你过滤掉一大半糟糕的身份设计。毕竟Agent最大的优点就是速度快而速度在没有边界的前提下恰恰是最危险的属性。