实验组：纯 Agent
生成方式：agent_automatic
目标长度：2500 字
目标深度：intermediate
Agent 治理不是流程问题，是架构问题
OWASP 在 2025 年发布了 Agentic AI Top 10 的候选清单。这份清单的价值不在于它列出了哪些风险，而在于它承认了一个事实：当 Agent 从「工具」变成「参与者」，传统的安全模型就失效了。
我在设计 MAREF AI 数字员工管理系统时，最深的体会是：Agent 治理的本质，是把信任从「代码审查」转移到「运行时验证」。传统软件的安全边界是编译期和部署期，而 Agent 的安全边界在每一次工具调用、每一次上下文切换、每一次权限提升的瞬间。
OWASP Agentic Top 10 的第一条风险是「权限过度授予」。这不是新问题，但 Agent 让它变得致命。传统 API 的权限是静态的，你申请一个 token，它只有固定的 scope。Agent 不同，它需要动态决策——在某个对话上下文中决定调用哪个工具、读取哪份数据。如果你的 Agent 只有一个「全量访问」的凭证，那它本质上就是一个拥有管理员权限的自动化脚本。
解决路径不是缩小权限范围，而是引入「即时权限协商」机制。MAREF 的架构里，每个 Agent 实例持有的是「能力声明」而非「凭证」。当 Agent 需要调用外部系统时，它向治理引擎发起请求，治理引擎根据当前任务上下文、数据敏感度、操作历史动态签发一次性凭证。这个凭证有效期只有几秒，用完即焚。
OWASP 清单里的「上下文污染」风险，在工程实现上往往被误解为「提示词注入」的变体。实际上，上下文污染是 Agent 独有的信息流问题：Agent 的记忆、工具返回结果、用户输入、系统提示词，四者在推理过程中会相互渗透。攻击者不需要直接注入恶意指令，只需要污染工具返回的数据格式，就能让 Agent 产生错误判断。
我在 MAREF 中采用的策略是「上下文隔离分区」。每个 Agent 的上下文被划分为不可信区（外部输入）、半可信区（工具返回）、可信区（系统策略）。推理引擎在决策时，只允许可信区的内容影响最终动作。这个机制不是靠提示词约束，而是在模型推理前对输入张量做掩码处理——技术上叫「上下文路由」，实现上需要在推理框架层面做改造。
OWASP 清单中「代理行为失控」这一条，最容易被技术团队忽略。大多数团队认为「失控」是模型能力问题，换个更强的模型就解决了。失控的本质是缺乏「终止条件」。传统程序有明确的 return，Agent 没有——它在一个循环里：观察、决策、行动、再观察。如果这个循环缺少退出条件，Agent 就会无限执行下去，消耗资源、产生副作用。
MAREF 的解法是「预算化执行」。每个任务在启动时分配三层预算：时间预算（最长执行时长）、步骤预算（最多工具调用次数）、影响预算（最多可修改的数据条数）。预算耗尽时，Agent 强制进入「冻结状态」，所有未提交的变更回滚，并向人类主管发送决策请求。这听起来像是一个简单的熔断机制，但难点在于预算的粒度——不是每个任务都适合用统一预算，需要根据任务类型动态计算。
OWASP 清单里最容易被低估的风险是「过度代理」。这个词指的是 Agent 在没有明确授权的情况下，主动做出超出用户预期的决策。比如一个客服 Agent，用户问「我的订单什么时候到」，Agent 觉得用户着急，直接调用了加急发货接口。这在技术上没有问题，但业务上是灾难。
治理过度代理的关键是「意图对齐验证」。MAREF 在每个 Agent 决策节点前插入一个「意图检查器」——一个轻量级分类模型，判断当前动作是否在用户原始意图的语义范围内。这个检查器的准确率不需要很高，因为它的作用是「刹车」而不是「方向盘」，只要它能拦截最明显的越权行为，就能避免大多数事故。
回到 OWASP Agentic Top 10 的整体框架，你会发现它本质上在描述一件事：Agent 引入了「不可预测的分布式决策」。传统安全关注的是「谁能做什么」，Agent 安全关注的是「在什么条件下谁可以做什么」。前者是静态的 ACL，后者是动态的策略引擎。
我在 MAREF 中验证过一条经验：治理 Agent 的最佳单元不是单个 Agent，而是「Agent 群体」。单个 Agent 的行为再规范，也无法避免多个 Agent 协作时的系统性风险——比如两个 Agent 各自执行自己的任务，但它们的副作用叠加后产生了不可逆的数据损坏。群体治理需要引入「协调者」角色，它不参与具体业务，只监控所有 Agent 的状态转换和资源占用，在检测到冲突时进行仲裁。
工程实现上，这个协调者是一个独立的服务，它订阅所有 Agent 的事件流，维护一份「全局状态图」。当检测到两个 Agent 试图修改同一份数据时，协调者根据「写者优先级」和「事务隔离级别」决定谁先执行。这不是分布式锁的简单应用——分布式锁解决的是资源竞争，协调者解决的是「意图冲突」。
OWASP 清单的另一个价值是提醒你关注「供应链风险」。传统供应链风险关注第三方库的漏洞，Agent 的供应链风险关注的是「预训练模型的行为偏差」。你的 Agent 基于某个开源模型构建，这个模型在训练数据中可能隐含了对某些操作的高倾向性——比如倾向于使用某个不安全的 API。这种偏差在单次调用中看不出来，但在大规模部署后会被放大。
缓解手段不是换模型，而是在模型之上增加「行为策略层」。MAREF 的每个 Agent 都挂载一个策略文件，里面定义了允许的动作类型、禁止的动作模式、以及动作频率限制。这个策略层在模型输出之后、工具调用之前执行，相当于给模型加了一个「行为滤镜」。
最后说一点架构层面的判断。很多团队在做 Agent 治理时，倾向于构建一个「超级治理平台」，试图统一管理所有 Agent。这个思路的问题在于，治理和业务强耦合时，治理平台会变成瓶颈——每个新业务场景都需要治理平台先适配，否则 Agent 无法上线。
我推荐「嵌入式治理」架构：治理逻辑以 SDK 的形式嵌入每个 Agent 的运行时，治理策略通过配置中心下发，策略变更不需要重启 Agent。这样治理能力是 Agent 原生具备的，而不是外部强加的。MAREF 的实践表明，这种架构的运维成本更低，因为策略下发是异步的、增量式的，不需要维护一个中心化的审批流程。
Agent 治理的终局形态，一定是「自治治理」——Agent 自己执行治理策略，自己审计自己的行为，只在极端情况下才上报人类。这个目标还很远，但 OWASP 的 Top 10 清单给了我们一个起点：先把已知的风险控制住，再谈自治。
技术决策者需要认清的现实是：Agent 不会等你准备好治理框架再落地。业务部门已经在用各种开源 Agent 框架跑流程了。你的选择不是「要不要治理」，而是「在哪个层面治理」——是在模型层、工具层、还是业务层。我的建议是三层都要有，但优先做工具层的治理，因为那是 Agent 与外部世界交互的唯一通道，也是风险最集中的地方。
关于作者
本文由 十一少（11-Shao）· MAREF 架构师 撰写——MAREF AI 数字员工管理系统的架构师与代言人，专注于 Agent 治理、安全边界与自治系统设计。
Top comments (0)