1. 从“声明了权限它照样读了 18.7 万行”说起“声明了权限它照样读了 18.7 万行”——这句话我第一次看到的时候脑子里蹦出来的不是愤怒而是一种很熟悉的无力感。做过 agent 开发的人大概都经历过类似的场景你在配置文件里写得清清楚楚这个 agent 只能访问某个目录、只能调用某几个工具、只能读某个级别的数据结果跑起来之后它该读的还是读了该碰的还是碰了日志里一翻18.7 万行数据安安静静地躺在那里仿佛你的权限声明只是一张贴在墙上的告示谁都可以绕过去。这不是某一个框架的 bug而是当前 agent 治理体系里一个结构性的缺口。我们花了大量精力在“声明”上——声明角色、声明权限、声明边界、声明工具白名单但真正决定 agent 行为的从来不是声明本身而是拦截点和尺子。拦截点是你在执行链路上真正能卡住动作的那个位置尺子是你用来判断“这个动作该不该放行”的量化标准。缺了这两样权限声明就只是一份文档而不是一道闸门。这篇文章想聊的就是这件事。我会从 agent 治理的整体设计思路讲起拆解为什么“声明式权限”在 agent 场景下天然容易失效然后落到具体的拦截点设计、评测尺子构建、实操排查方法上。内容适合正在做 agent 开发、agent 安全、agent 评测集构建的同行参考也适合刚接触 agent 框架、想搞清楚“权限到底该怎么管”的朋友。全文基于常见工程实践展开涉及具体参数和步骤的地方我会说明推导过程方便你直接抄作业或者按自己的场景调整。2. agent 治理的整体设计与思路拆解2.1 为什么声明式权限在 agent 场景下天然漏风传统软件的权限模型是“静态边界 单次判定”。一个进程启动时拿到一组权限之后每次系统调用由内核统一检查检查点是固定的、不可绕过的。这套模型能成立是因为执行路径是收敛的——程序怎么写它就怎么跑内核只需要在系统调用这一层设卡就够了。agent 不一样。agent 的执行路径是发散的。它根据上下文动态决定下一步调用哪个工具、读哪个文件、发哪个请求。你今天给它声明了“只能读 /data/reports 目录”明天它在推理过程中自己拼出一个../../etc/config的路径或者通过某个工具的间接能力把数据带出来。声明是静态的行为是动态的两者之间的缝隙就是那 18.7 万行数据溜出去的地方。更麻烦的是agent 的工具调用往往是多层嵌套的。A 工具内部调 B 工具B 工具内部又走了一个 shellshell 里再执行一条命令。你在最外层声明的权限到了第三层早就被稀释得差不多了。这就是为什么很多团队发现权限配置文件写了一版又一版审计日志里该出现的越权行为一个没少。2.2 拦截点治理真正生效的前提拦截点的本质是执行链路上一个不可绕过的检查位置。注意“不可绕过”这四个字它是拦截点和“声明”之间最根本的区别。声明是给 agent 看的拦截点是给执行引擎看的声明可以被忽略拦截点忽略不了因为动作根本走不到下一步。一个合格的拦截点需要满足三个条件。第一它位于所有敏感动作的必经之路上不能有旁路。第二它的判定逻辑独立于 agent 自身的推理不能由 agent 自己决定要不要检查。第三它的判定结果可记录、可回溯每一次放行或拦截都要留下痕迹否则出了问题你连复盘都做不了。在 agent 架构里常见的拦截点位置有这么几类工具调用入口、文件系统访问层、网络请求出口、以及 shell 命令执行层。每一层的拦截粒度和实现难度都不一样后面我会展开讲。2.3 尺子从“能不能”到“该不该”的量化标准有了拦截点下一个问题就是拦下来之后凭什么判断这个动作该放行还是该拒绝这就是尺子的作用。很多团队的权限系统只有“能不能”这一层——这个 agent 有没有 read 权限。但 agent 场景下真正需要的是“该不该”——它这次读这个文件是不是在完成当前任务的合理范围内读 100 行和读 18.7 万行性质完全不同读配置文件里的一个字段和把整个配置文件 dump 出来性质也完全不同。尺子就是把这些“程度”量化的东西。它可以是行数阈值、可以是访问频率、可以是数据敏感度分级、可以是任务相关性评分。没有尺子拦截点就只能做粗粒度的黑白判定要么全放要么全拦实际用起来不是误杀就是漏杀。2.4 方案选型的几个关键取舍在实际落地时有几个取舍点值得提前想清楚。第一个取舍是拦截点放在框架层还是系统层。框架层实现快、和 agent 逻辑耦合紧但容易被绕过系统层比如文件系统钩子、网络代理更硬但部署复杂、性能开销大。我的经验是核心敏感动作放系统层普通工具调用放框架层两层配合。第二个取舍是尺子用规则还是用模型。规则尺子可解释、可审计、性能好但覆盖不了复杂语义模型尺子灵活但引入不确定性和额外成本。常见做法是规则做第一道粗筛模型做第二道细判。第三个取舍是拦截是硬阻断还是软告警。硬阻断安全但影响 agent 完成率软告警灵活但依赖后续人工或自动处置。生产环境里通常是分级高危硬阻断中危软告警加降级低危只记录。3. 核心细节解析与实操要点3.1 工具调用入口的拦截设计工具调用是 agent 和外部世界交互最主要的通道也是拦截点最该优先覆盖的位置。设计这里的拦截核心是把“工具名 参数”当成一个完整的动作单元来检查而不是只看工具名。具体做法是在工具注册表外面包一层 dispatch 层所有工具调用必须经过这个 dispatch。dispatch 拿到调用请求后先做参数规范化比如把相对路径转成绝对路径、把 URL 解析出 host然后交给尺子判定判定通过才真正执行工具函数。这里有个容易踩的坑参数规范化必须在判定之前做。我见过不少实现是先判定再规范化结果 agent 传一个./reports/../secret.txt判定时看到的是./reports/前缀放行了规范化之后才发现实际指向的是secret.txt。顺序反了拦截点就形同虚设。另一个细节是工具的组合能力。有些工具单独看很安全组合起来就能越权。比如一个“读文件”工具加一个“发 HTTP 请求”工具单独用都没问题但 agent 可以先读敏感文件再通过 HTTP 把内容发出去。这种跨工具的链路拦截需要在 dispatch 层维护一个会话级的上下文记录本次任务已经发生过哪些敏感动作做关联判定。3.2 文件系统访问层的拦截与行数尺子回到标题里那个“18.7 万行”的场景问题就出在文件系统访问层。声明了“只能读某目录”但没声明“一次最多读多少行”agent 就把整个大文件读了个遍。文件系统层的拦截我建议用路径白名单 行数/字节数阈值双尺子。路径白名单解决“能不能碰”行数阈值解决“能碰多少”。阈值怎么定我的经验是按任务类型分档配置读取类任务单次读取上限设 500 行日志分析类任务上限设 5000 行全量数据处理类任务走单独的审批通道不设默认上限但强制记录。阈值不是拍脑袋定的可以从历史数据里推。把过去一个月的 agent 文件读取记录拉出来按任务类型分组看 P95 的读取行数是多少阈值设在 P95 的 1.5 倍左右既能覆盖绝大多数正常请求又能卡住异常的大批量读取。这个推导过程比直接抄一个数字靠谱得多。注意行数阈值要按“单次调用”和“单任务累计”两个维度分别设。单次调用防的是“一口气读太多”累计防的是“蚂蚁搬家式”的多次小量读取。两个维度缺一不可。3.3 网络出口的拦截与数据外带防护网络出口是数据外带的主要通道也是很多团队最容易忽略的拦截点。agent 通过 HTTP 请求把数据发出去如果出口不做检查前面所有的文件读取限制都可能被绕过。网络出口的拦截核心是目标地址白名单 请求体敏感度检查。目标地址白名单相对好做维护一个允许访问的域名/IP 列表不在列表里的一律拒绝。请求体检查复杂一些需要判断发出去的内容里有没有敏感数据。一个实用的做法是数据指纹比对。对敏感文件的内容计算指纹比如对关键字段做哈希agent 发出去的请求体里如果命中了这些指纹就触发拦截或告警。这个方法不需要理解请求体的语义纯靠指纹匹配实现简单、误报可控。3.4 shell 命令执行层的拦截shell 层是最难拦也最该拦的地方因为 shell 的能力太强了一条命令能干的事情比十个工具加起来还多。很多 agent 框架为了灵活性会给 agent 开 shell 权限这时候拦截点必须做得很细。我的做法是命令白名单 参数模式匹配。不是白名单里的命令直接拒绝白名单里的命令再用正则匹配参数比如cat命令只允许读白名单目录下的文件curl命令只允许访问白名单域名。正则写起来麻烦但比事后追责省事得多。还有一个技巧是禁用命令组合符。;、、||、|这些符号能让 agent 把多条命令串起来绕过单条命令的检查。如果业务上不需要命令组合直接在拦截层把这些符号过滤掉能省掉一大堆麻烦。3.5 评测尺子的构建从“能跑”到“跑得对”拦截点和尺子建好了怎么知道它们真的有效这就需要评测。agent 评测集的构建不能只测“任务能不能完成”还要测“越权行为能不能被拦住”。评测集应该包含三类用例。第一类是正常用例验证拦截点不会误杀正常请求这类用例要覆盖各种任务类型和参数组合。第二类是越权用例故意构造各种绕过尝试比如路径穿越、参数注入、工具组合验证拦截点能拦住。第三类是边界用例测试阈值附近的请求比如刚好 500 行和 501 行的读取验证尺子的判定是否精确。评测的指标也要设计好。除了常规的拦截率、误杀率我建议加一个拦截延迟指标——从动作发起到被拦截的时间。延迟太高说明拦截点位置太靠后数据可能已经部分泄露了。4. 实操过程与核心环节实现4.1 拦截点的部署位置与顺序实际部署时拦截点不是随便放的顺序很重要。我的建议顺序是网络出口 → 文件系统 → shell → 工具调用。为什么网络出口放最前面因为数据一旦发出去就收不回来了出口拦截是最后一道防线必须最先检查、最严格。文件系统放在网络之后是因为文件读取是数据外带的前置动作先卡住读取出口的压力就小很多。shell 放在工具调用之前是因为 shell 的能力更强需要更早介入。工具调用放最后是因为它最贴近业务逻辑拦截逻辑可以做得更精细。每一层拦截点都要有独立的日志日志里记录时间戳、agent 会话 ID、动作类型、动作参数、判定结果、判定依据。这些日志是后续复盘和调优的基础不能省。4.2 尺子参数的推导与配置尺子参数不能拍脑袋我一般用“历史数据 安全余量”的方法推导。具体步骤是这样第一步拉取过去 30 天的 agent 动作日志按动作类型分组。第二步对每组计算关键指标的分布比如文件读取的行数分布、网络请求的响应体大小分布。第三步取 P95 作为基准值乘以 1.5 作为初始阈值。第四步上线后观察一周根据误杀和漏杀情况微调。以文件读取为例假设历史数据显示配置读取类任务的 P95 是 320 行那么初始阈值设为 480 行。上线后发现有些正常任务需要读 600 行误杀了那就把阈值调到 700 行左右。这个过程要迭代两三轮才能稳定。配置示例YAML 格式示意用interceptors: filesystem: path_whitelist: - /data/reports - /data/configs read_limits: config_task: per_call: 700 per_session: 3000 log_task: per_call: 5000 per_session: 50000 network: host_whitelist: - api.internal.example.com body_fingerprint_check: true shell: command_whitelist: - cat - ls - grep forbid_operators: true4.3 一次完整的越权拦截实录讲一个我实际遇到的案例。某个 agent 任务需要分析一份销售报告声明权限是“只能读 /data/reports 目录”。任务跑起来后agent 先正常读了报告文件然后推理出“需要参考配置里的字段映射”于是尝试读/data/configs/field_mapping.yaml。文件系统拦截点拿到请求先做路径规范化得到/data/configs/field_mapping.yaml。然后查路径白名单发现/data/configs不在当前任务的允许列表里这个任务的声明只有/data/reports判定拒绝。日志记录会话 ID、动作类型 read、路径、判定结果 deny、依据 path_not_in_whitelist。agent 收到拒绝后尝试了另一条路径通过 shell 执行cat /data/configs/field_mapping.yaml。shell 拦截点拿到命令先匹配命令白名单cat在白名单里通过。然后匹配参数模式发现参数路径不在允许目录内判定拒绝。日志记录动作类型 shell、命令 cat、参数路径、判定结果 deny、依据 arg_path_not_allowed。两次拦截之后agent 放弃了越权尝试转而用已有信息完成任务。整个过程的拦截延迟都在 10ms 以内对任务完成时间没有明显影响。4.4 评测集的构建与跑法评测集我一般分三个文件维护normal_cases.jsonl、violation_cases.jsonl、boundary_cases.jsonl。每个用例包含任务描述、预期动作序列、预期拦截结果。跑评测的时候用一套独立的评测 runner把 agent 放进沙箱环境喂入用例收集实际动作序列和拦截结果和预期对比。对比结果输出成表格方便看哪些用例通过了、哪些失败了。评测频率建议是每次拦截规则变更后跑全量日常每天跑一次抽样。全量评测耗时较长抽样评测控制在 10 分钟内保证能进 CI 流程。5. 常见问题与排查技巧实录5.1 拦截点失效的典型原因拦截点失效最常见的原因有这么几个。第一个是旁路存在比如 agent 通过一个没被拦截的工具间接访问了敏感资源。排查方法是把所有工具的能力列出来逐个分析能不能触达敏感资源找出漏网的。第二个是判定顺序错误前面提到的先判定后规范化就是典型。排查方法是 review 拦截代码的执行顺序确保规范化在判定之前。第三个是配置未生效比如规则更新了但拦截点没重新加载。排查方法是加一个配置版本号每次加载后打日志。5.2 误杀率高的调优思路误杀率高说明尺子太严了。调优思路是先放宽再收紧。先把阈值放宽到明显不会误杀的程度观察一周收集所有被放行的动作分析哪些是真正危险的、哪些是正常的。然后针对真正危险的那部分设计更精细的规则而不是简单地把阈值调回去。举个例子如果发现“读大文件”被大量误杀不要直接把行数阈值调高而是先分析这些大文件读取的任务类型看看能不能按任务类型分档设阈值。分档之后正常任务用宽阈值敏感任务用严阈值误杀和漏杀都能降下来。5.3 拦截延迟过高的优化拦截延迟高通常是拦截点位置太靠后或者判定逻辑太重。优化方向有两个。第一个是把拦截点前移比如把文件读取的检查从“读取后”移到“读取前”在打开文件之前就判定。第二个是简化判定逻辑把复杂的语义判定拆成“快速粗筛 慢速细判”两级大部分请求在粗筛阶段就能放行或拒绝只有少数需要细判。5.4 常见问题速查表问题现象可能原因排查方法解决思路越权动作未被拦截旁路存在列出所有工具能力分析触达路径补全拦截点覆盖正常动作被误杀阈值过严分析被拦截动作的任务类型按任务类型分档设阈值拦截延迟高拦截点靠后或判定重打点测量各阶段耗时前移拦截点拆分判定配置更新不生效未重新加载检查配置版本号日志加配置热加载机制日志缺失无法复盘日志未覆盖检查各拦截点日志统一日志格式补全字段5.5 几个踩过的坑第一个坑是只拦工具不拦 shell。早期我们只在工具调用层做了拦截结果 agent 通过 shell 绕过了所有限制。后来补上 shell 拦截才堵住。第二个坑是阈值写死在代码里。一开始阈值是硬编码的每次调整都要改代码、重新部署效率极低。后来改成配置文件驱动调整阈值不用动代码迭代速度快了很多。第三个坑是评测集长期不更新。评测集建好之后用了半年没动结果 agent 的能力升级了新的越权方式评测集里没有跑评测全绿但实际有漏洞。后来定了规矩每次 agent 能力有重大更新评测集必须同步补充用例。提示拦截点和尺子不是一次建好就完事的它们需要跟着 agent 的能力一起演进。建议每个月做一次拦截规则 review看看有没有新的绕过方式需要覆盖。6. 关于 agent 治理的一点个人体会做 agent 治理这几年我最大的体会是声明是给人看的拦截点是给机器看的尺子是给判断看的。三者缺一不可但优先级上拦截点和尺子远比声明重要。声明写得再漂亮没有拦截点就是一张废纸拦截点建得再多没有尺子就只能做粗粒度判定。另一个体会是治理这件事没有“一劳永逸”的方案。agent 的能力在变绕过的方式也在变治理体系必须跟着迭代。与其追求一个完美的初始设计不如建立一个能快速迭代的机制——配置能热加载、评测能自动化、日志能支撑复盘。机制建好了具体规则慢慢调就行。最后分享一个小技巧如果你刚开始做 agent 治理不知道从哪下手就先从文件系统拦截 行数尺子做起。这两个东西实现成本低、覆盖场景广能挡住大部分常见的越权行为。等这套跑顺了再往网络出口、shell 层扩展。一步一步来比一上来就搞大而全的方案靠谱得多。