这两年 AI Agent 的落地速度确实超出了很多人预期。在政务专网这类高敏内网里Agent 的典型工作已经不再局限于聊天问答而是逐渐延伸到工单自动处理、文档智能检索、报表生成、流程审批辅助甚至跨系统数据比对。与此同时我也在不少交流群里看到同一种担忧“Agent 的权限到底该给多少给多了怕乱来给少了又干不了活。”这个担忧不是杞人忧天。我在内部做过一次攻防演练复盘当时被归档为 CVE-2026-26133 的问题本质上就是一个 Agent 权限治理失败的典型案例。虽然这个编号目前只出现在我们内部演练记录里但它背后的问题模型在 Agent 工程里非常普遍服务账号权限过大、工具调用没有细粒度管控、Agent 自主行动范围和用户对话目标完全脱节。今天这篇我想把当时的复盘思路和后来落地的 Least Agency最小代理权实践完整整理出来。如果你正在政务、金融或任何隔离网络环境下规划 Agent 项目这篇可以从底层帮你避免很多雷。1. 从最小权限到最小代理权传统 IAM 管不住 Agent 的根本原因1.1 最小权限为什么在 Agent 场景失效传统信息安全里有条铁律叫最小权限Least Privilege任何主体只应该拥有完成工作所必需的最小权限。这条铁律在“人 固定角色”的系统里很好使给运维开通服务器登录权限给财务开通财务系统权限给前端开发开通测试环境访问权限。但 AI Agent 不是“人 固定角色”它更像“一个弹性决策器 一组可编程操作接口”。同一套系统Agent 可以依据用户对话的上下文动态地决定调用哪个工具、按什么顺序组合、访问哪些资源。这就带来两个传统 IAM 很难处理的问题。第一主体的不确定性。你给 Agent 发一个服务账号这个账号是一条权限基线但 Agent 的行为却由大模型实时决策。模型看到对话里出现了“请帮我查一下本部门的考勤记录”它可能会决定去调用数据库工具执行一条 SQL。这个决策并不是你设计权限系统时能完全枚举的。第二资源和工具视角的叠加。传统系统里我们说“给某用户授予某资源权限”一般就结束了。但 Agent 场景里权限被传递了两层第一层是 Agent 能调用哪些工具第二层是这些工具本身继承了所在服务账号的资源访问能力。很多团队只管控了第一层限制了工具数量却没有管第二层工具背后权限过大。1.2 Least Agency 的两个维度我第一次听到 Least Agency 这个概念时下意识以为它只是把 Least Privilege 换个名字。后来在做权限治理方案时我逐渐意识到两者并不等价。Least Privilege 关注“能访问什么”Least Agency 关注“能自主做什么、能擅自行动到什么程度”。Least Agency 应该拆成两个维度去理解授权集合最小化Agent 能调用的工具、能访问的数据资源、能执行的动作都必须是最小的、可枚举的。这仍然是最小权限思想。自主行动范围最小化Agent 不能在没有约束的情况下自由串联工具和资源。关键操作要可拦截、可审批、可回退。这类似于“给 Agent 戴一个行动缰绳”。用一个不太严谨但容易懂的例子最小权限决定“给不给你这串钥匙”最小代理权则决定“给你钥匙之后你能按什么规则使用这把钥匙、哪些门开了需要再向主人确认”。维度传统最小权限Least Agency主体定义用户账号、角色、组Agent 会话 用户意图 运行上下文最小化目标资源权限尽量小而精确资源权限 工具动作 自主决策范围控制时机授权时一次性分配授权时分配 运行时持续管控典型风险静态越权动态越权、工具串联越权、提示注入放大审计粒度登录和资源操作日志会话级工具调用链、操作意图、资源目标表格里最后一行是我觉得最有价值的一点Agent 审计绝不能只记录“谁登录了、改了什么”得记录“用户说了什么 → Agent 选择了哪个工具 → 以什么参数摸了哪份资源 → 返回了什么摘要”这样一条完整链路才算闭环。1.3 为什么我不建议给 Agent 直接挂“服务账号”在踩过坑之前我也看过不少 Agent 项目直接采用“共享服务账号 本地文件权限”的方式。起先看起来没问题因为服务账号权限是运维规规矩矩申请的能访问的东西不越界。但实际上Agent 的内部逻辑和人的操作习惯差距很大。人会在一台机器上操作时带着常识和职业判断Agent 则只会严格按照工具返回的信息和上下文里的指令行动。只要用户的对话文本里混入了一段精心构造的指令Agent 就可能把工具用到设计者根本预想不到的地方。再说直白点服务账号给的是“机器身份”但 Agent 是“模拟人的行为做决策”。把机器身份直接裸露给一个具备自主决策能力的程序等于把一辆车的钥匙交给一个从未上过路的智能驾驶系统却没有限速、没有电子围栏。所以我在内部推动的第一个原则就是Agent 不允许直接使用高权限服务账号运行必须为每个 Agent 单独建立“最小代理身份”并在工具层挂上比服务账号更严格的 ACL。这个原则听起来不难实际执行时牵扯到很细的落地设计。后面第四章我会给一套便于复制的三层落地方法这里先把问题链条讲清楚。2. CVE-2026-26133 复盘一条从提示注入到数据越权的完整链路2.1 我是在什么场景下抓到这个问题先说清楚这个编号当时只是我们在内部攻防演练中做的问题归档。为了避免大家误解我在这里把背景交代一下我们在一个模拟政务内网的环境里部署了一套“文档助手型 Agent”。这个 Agent 具备三块能力挂载知识库做文档问答、调用数据库做结构化查询、调用文件接口做附件上传和目录浏览。部署的目的是让业务人员通过自然语言完成繁琐的业务资料查找。红队在演练时给它投喂了一份包含恶意嵌套指令的文档。Agent 读取文档后把文档里的伪指令当作自身的下一步行动指令调用了一个“附件检索”工具扫描同目录下的共享文件。由于服务账号本身对共享目录有读取权限整个扫描动作没有任何拦截最后这批非目标文件内容被带回了上下文并在一次普通问答的引用中被展示了出来。这不是什么复杂的漏洞逻辑链条短得可怕用户上传一份机密性较高的文档内容里夹带指令Agent 把文档内容视为合法上下文并按内容中的“伪指令”调整行为Agent 调用“附件检索”工具时没有校验当前会话用户是否有权访问扫描目录服务账号的高权限直接覆盖了资源级别的访问控制整个调用过程记录在日志中但因为审计只记录到“工具被调用”没有记录到“具体访问了哪些资源路径”事后排查还费了不少劲。2.2 核心根因工具权限与对话意图完全脱离复盘时我们最初把问题归因为“提示注入防御不足”。Prompt 注入确实是触发点但继续追下去会发现就算没有注入只要用户的自然语言表达足够模糊Agent 也有可能在权限范围内“自我发挥”去访问不该看的数据。所以真正的问题不是模型够不够聪明而是 Agent 的权限模型里缺了“对话意图”与“资源访问目标”的一致性校验。我用一句大白话总结Agent 有权限不等于用户有权限。Agent 是一个中间执行体它调用的每一个操作都应该在语义上符合“当前会话用户能够执行的最小范围”。如果一段对话是想查询某部门的报表Agent 就不应该去扫描网络共享目录如果用户是想上传一个附件Agent 就不应该顺手把同目录其他文件列出来。这个原则听起来温和落地却需要工具层配合。工具在被 Agent 调用时至少要能回答三个问题这个工具的调用者Agent 所代表的用户是谁这次的资源访问目标是什么这个访问目标是否落在调用者的授权范围里而我见到的很多 MCP 工具或 Function Calling 实现往往只把它当成一个“函数”看待参数传进去就执行完全没有资源级授权校验。工具层越薄权限治理的难度就越大。2.3 这次复盘的三个直接教训第一Agent 工具不能直接继承服务账号权限。工具需要的只是完成目标的最小权限这份权限必须能通过运行时检查动态收紧而不是一次性绑定在“进程以谁的身份运行”上。第二工具的输入参数必须做“资源目标合法性”校验。就像你给一个人开放了“读取文件”的能力不意味着他能读任何文件。工具内部应该有一个允许访问的资源前缀或资源标签列表超出列表就拒绝。第三审计必须带“调用链上下文”。只看日志里FileReader.run(path)是不够的要把 Agent 内部决策的 prompt 摘要、用户原始对话、工具返回内容的摘要、人工审核标记都串起来。否则一旦出了事排障时间会成倍增加。这三个教训后来就成了我们落地 Least Agency 方案的主线。在写代码之前先把权限模型画清楚比给 Agent 堆多少安全过滤插件都管用。3. 政务专网环境下的权限治理约束为什么不能照搬公网 SaaS 方案3.1 专网环境真正的硬约束不是网络隔离外界对政务专网的第一印象是“隔离网络安全问题不大”。这种想法非常危险。隔离解决的是边界问题它解决不了内部主体的越权和误操作。事实上专网内部的数据级别差异非常大有的数据可以共享给所有业务人员有的数据只能特定岗位查看有的数据连“搜索索引”都不允许建立。Agent 进入这套环境后如果只盯着“系统能不能连通”而忽略了“数据可被谁访问”基本上就是在埋雷。我在给一些项目做评估时最常看到的表现是给 Agent 配置了知识库检索工具于是知识库索引里把包括高敏文档在内的所有内容都一股脑地向量化了。用户随便问一个问题Agent 就能从向量库里捞出一大段不该出现在该用户问答界面里的内容。这个现象本质上不是技术问题而是权限设计问题——向量数据库的查询结果没有做细粒度的用户级过滤。所以我想强调的是一旦 Agent 介入政务专网它的每一次工具调用都会落成一条数据访问记录。这条记录将来可能被合规、审计甚至司法程序调取因此权限治理不是可选项而是准入条件。3.2 不能直接照搬公网 SaaS 方案的原因过去几年公网侧的 Agent 安全方案主要集中在几个方向给 LLM 网关加告警、在 Prompt 层做注入检测、配合内容审核服务做输出过滤。这些方案在公网场景非常好用但如果直接搬到政务专网会撞上几个现实约束。第一个约束是服务边界。很多公网方案依赖外部 SaaS 安全服务比如云上内容审核、第三方举报接口、外部威胁情报库。政务专网通常不允许数据随意出境也不能把内部对话内容送到未经评估的第三方服务去做安全分析。这就意味着安全能力必须内嵌到本地网关中而且要做成可审计、可关闭的模块。第二个约束是账号体系的复杂度。政务专网内部的账号通常由统一身份平台管理有的还涉及分级审批、多人复核、临时授权时间窗。Agent 作为新主体接入这个体系时不能自己另搞一套用户体系否则权限治理又会形成孤岛。最稳妥的方式是把 Agent 作为“具备工具调用能力的服务主体”纳入统一身份平台每个会话绑定真实的自然人账号再叠加工具级策略。第三个约束是审计要求。公网产品出问题可能主要影响商业声誉专网系统出问题影响面往往是全链路甚至更大的范围。审计上不仅要知道“哪个系统被访问了”还要能还原“这次访问由哪个自然人发起的、Agent 中间做了哪些决策”。这种偏重链路还原的诉求公网那些只看流量和 API 日志的 SaaS 工具基本满足不了。3.3 政务专网权限治理的架构取向基于这些约束我给专网内的 Agent 权限治理定了一个比较务实的架构取向不在模型层堆叠过多“魔法”而在工程链路里引入三个清晰角色。策略面Policy由统一身份平台下发权限策略定义“自然人角色 → 可访问资源 → 可调用工具”的映射关系。执行面Enforcement在 Agent 网关处拦截每一次工具调用校验资源目标、动作类型和会话身份不满足策略的调用直接拒绝。审计面Audit把用户对话、Agent 决策链路、工具调用参数、返回内容摘要、拦截事件全部结构化落库。这样一套架构并不花哨但很符合专网对稳定和可审计的要求。后面我落地 Least Agency 时基本就是围绕这三条线去做的。4. 落地 Least Agency 的三层实践权限建模、运行时拦截与行为审计4.1 第一层给 Agent 做“工具权限声明”而不是直接挂工具很多人给 Agent 接工具接口文档一拿到就去写 openapi.json然后让模型自己去选择。Less is more——在权限治理里这句话尤其正确。我在团队里强制要求Agent 接工具前必须为每个工具填写一份“权限声明”内容包括工具名称与用途它能访问的资源和动作例如读取 /data/pub/* 目录执行 SELECT禁止删除调用时需要携带的会话身份来源允许的最大结果返回范围防止 Agent 把整个目录树拉到上下文是否属于高风险操作是否需要人工审批。下面是一份简化后的策略文件示例我习惯用 YAML 维护agent: doc-assistant identity_source: iam.user_session time_window: 09:00-18:00 tools: - name: knowledge_search resource_prefix: [doc://pub/, doc://dept/hr/materials] actions: [read] max_return_items: 20 require_human_approval: false - name: sql_query resource_prefix: [query://finance/analytics] actions: [select] max_rows: 50 allowed_conditions: [dept_idcurrent_user.dept_id] require_human_approval: true - name: upload_attachment resource_prefix: [file://tmp/uploads] actions: [write] max_upload_size: 10MB required_confirm: true default_action: deny这份声明看起来像配置但意义很深远它把“Agent 能做什么”从模型的自由意志里剥离出来变成一份可以评审、可以测试、可以在日志里追踪的静态契约。模型只能在契约范围内选择工具超出范围就是非法调用。这里有个很容易忽略的细节resource_prefix必须同时作用于工具的实现层不能只写在 prompt 里。也就是说工具内部要做真正的校验。否则模型哪天被注入迷惑绕开 prompt 约束直接传一个外部的 path 参数进来服务端接不接得住就完全靠命了。很多 Agent 框架的 tool 函数只是浮在代码层面的普通函数根本没有统一拦截点。我的建议是所有工具都通过同一个 Tool Execution Proxy 调用由这个代理统一负责策略校验。4.2 第二层在 Agent 网关做运行时拦截权限声明是静态的运行时刻怎么检查就成了关键。我选择在 Agent 和工具注册中心之间加一层“运行时策略执行点”。每次模型决定调用一个工具调用请求会先到达执行点执行点根据会话上下文做校验校验通过才放行否则直接拒绝并返回错误信息。运行时检查至少要包含四类身份校验当前会话是否绑定了有效的自然人账号账号角色是否在工具允许名单内资源校验工具参数中的资源路径是否匹配该工具声明的resource_prefix动作校验实际执行的动作是否匹配声明的actions上下文校验本次调用是否符合对话中用户提出的目标。如果用户在对话里只是想查询 A 表数据Agent 却尝试扫描 B 目录这个调用必须被标记异常。前两类比较常规很多网关能实现。第三类也不难。第四类是最有挑战也最值得投入的因为它要求系统能理解“用户当前意图”和“工具调用参数”之间的一致性。现阶段我没有追求用另一个模型去做语义审核而是采用了两条相对可靠的策略高风险操作强制人工审批对资源路径做“增量权限”校验即工具只能访问用户已经明确授权过的资源范围而不是 Agent 自述“用户希望访问”的资源范围。4.3 第三层行为审计必须还原“一条会话决策链”在专网环境出事了能迅速还原过程比什么都重要。我的审计方案不是只记录工具调用日志而是记录完整的“会话决策链”每个环节都带上结构化字段{ session_id: s_20260218_001, user_id: u_0182, user_intent: 查询上月项目支出汇总, model_plan: decompose into: verify dept - query sql - aggregate, tool_calls: [ { tool: sql_query, params: {sql: select * from expense where month2026-01}, resource_target: query://finance/analytics, authz_result: allow, return_rows: 42 } ], human_approval: {required: false, operator: null}, security_events: [] }有了这种结构事后排查可以从 session_id 反向拉出用户说了什么、模型打算干什么、实际调了哪个工具、参数是什么、是否被拦截。很多 Agent 安全事故的“难查”难就难在日志颗粒度太粗只有工具名没有参数和意图。这个坑一定要提前避开。另外一个实践中很容易被忽视的点是AI Agent 的运行日志本身也是敏感数据。会话里可能包含业务敏感信息日志存储必须放在和 Agent 运行环境同一安全域内并且脱敏展示。给安全团队开放的日志视图最好能隐藏对话正文只保留意图摘要和工具调用链。这样既能保证排障需要又避免二次泄露。5. 从静态授权到动态授权让 Agent 每个“自主行动”都受控5.1 静态授权解决不了 Agent 的“自主组合”问题前面讲的权限声明和运行时拦截本质上还是静态策略加运行时校验。但它有一个明显的盲区Agent 可以把多个工具串联起来组合出一个策略没覆盖到的新行为。某个用户的账户可能只能查询报表但“查询报表”→“把报表内容写入附件”→“上传到共享目录”这样的链式操作如果三个工具分别授权Agent 是可以拼出一条越权路径的。这也是为什么我强调“动态授权”把权限控制下放到每一次实际操作而不是只做工具级授权。工具级授权管的是“能不能调用这个能力”动态授权管的是“这一次调用能不能作用在这个目标上”。5.2 三种动态授权模式我在不同 Agent 项目里实际用过的模式有三种按控制强度从高到低排序人工审批模式对所有高风险工具调用Agent 先把“请求详情”发送到审批队列由业务负责人或安全管理员确认后才执行。这种方式最安全但会明显拖慢效率适合删除、批量导出、跨目录写入这类操作。范围缩窄模式根据当前用户身份自动把工具的可用范围缩到最小。比如普通业务人员使用 SQL 查询工具时SQL 中的查询范围必须包含一个以本人部门为条件的约束否则拒绝执行。这个模式兼顾安全和效率但对工具改造能力要求高。事后复核模式不阻断调用但把高风险调用标记出来由审计人员在事后复核。适合一些无法实时审批又必须由 Agent 完成的自动化运维类任务。模式控制强度延迟影响适用场景人工审批高高删除、批量导出、跨目录写入范围缩窄中低SQL 查询、文件读取、文档检索事后复核低无自动化巡检、日志分析5.3 实现“动态授权”需要工具侧的配合改造动态授权并不是在网关加一个判断就完事它还要求工具本身能被“拆细”。比如一个“执行 SQL”的通用工具如果要支持范围缩窄就必须暴露 SQL 解析接口或者在支撑层做查询改写。MCP 工具生态里这类“可细粒度授权”工具还不多这也是当前 Agent 安全实践里最尴尬的地方框架跑得快安全水位跟不上。如果团队有条件我建议组件一个小的“工具能力层”对外暴露的业务动作尽量细化。比如不要给 Agent 一个run_sql万能工具而是给它query_monthly_expense、query_employee_info这类带有业务语义的专用工具。专用工具越细权限声明越精准动态授权的实现成本越低。这个设计和传统分布式系统里的“服务降级”思想有点像宁可工具多、语义明确也不要一个工具包打天下。6. 和 Agent 开发团队对线时最常被反驳的三个问题6.1 “给 Agent 限制太多效果就不好了怎么办”这是我最常听到的反驳。我的回应是限制权限不等于限制模型能力。模型的能力体现在理解、拆解和生成上工具权限只是在边缘划清边界。一个能区分“我有权读哪些数据”的 Agent并不会因为权限更小就变得更笨反而会因为误入歧途的机会减少产出更稳定。你在权限上投入的设计最终会等比例降低返工和排障成本。实际案例里我们限制了一个文档 Agent 的检索范围后它的回答准确率反而提升了。原因很简单权限范围限制了召回范围模型不再被大量不相关的高敏文档干扰引用来源也变得更可控。很多时候安全约束和业务效果并不是对立关系而是互相成就。6.2 “我们用的是服务账号切换成最小代理身份会破坏兼容性”在实际落地时兼容性摩擦主要集中在工具实现层有些工具写死了“读取服务账号配置文件”“连接数据库用服务账号密码”切换身份后确实会断。我的建议是分阶段推进第一轮先做日志审计和运行时拦截把“行为可见”这件事先立起来第二轮再把高风险的 Agent 工具迁移到独立身份。不要为了一个先行的沙盒项目做彻底重构但要明确演进路径否则你永远不会开始。6.3 “提示注入防不胜防是不是只能靠模型更聪明”大模型厂商确实在不断提升指令层级隔离能力但你不可能把安全完全托付给模型。模型再聪明也只是一个推理引擎真正兜底的是权限边界和执行阻断。提示注入的目标是操纵 Agent 的工具调用只要工具调用的资源目标被网关强制校验大部分注入脚本在到达资源前就被拦下了。所以不要追求“模型能识别所有恶意指令”而是假设“模型可能被操纵”然后把权限边界收得足够小。安全不是靠完美判断而是靠防止任何一个失败点演变成事故。写在最后把 Least Agency 当作一件持续维护的事我在实际项目里最深的体会是Least Agency 不是一锤子买卖而是伴随 Agent 生命周期的持续治理。工具会新增权限声明要及时更新业务会变化工具的resource_prefix要跟着调整用户角色会流动策略映射要同步刷新。建议把 Agent 权限治理纳入常规安全评审每发布一个新工具或一个新 Agent 版本就重新过一遍权限声明和运行时策略。另外一个小提醒Agent 的权限变更也要走变更审批流程不能由开发人员在代码仓库里默默改了 YAML 就上线。我们在演练中发现很多“漏网之鱼”恰恰来自一次无记录的服务账号提权或工具参数放宽。把这些环节纳入流程比事后加监控更便宜。如果你正在政务专网或其他高敏环境里规划 Agent 项目希望这篇复盘和落地思路能给你一点参考。安全治理没有银弹但把权限建模、运行时拦截、行为审计三件事做扎实至少可以让你的 Agent 在边界内“自由起舞”。
