摘要：工具调用是 agent 第一次把模型的决定落到真实系统、第一次产生副作用的环节。模型不是可信主体：它会被注入劫持、会误判、会被赋权过度。工具的安全执行由三道都在执行前的闸组成——权限决定能不能做，沙箱决定做坏了多大范围，human-in-the-loop 决定谁为后果拍板。本文拆开三者的分层与正交关系，讲清权限设计、沙箱谱系、HITL 闸门与编排决策，再按四家框架对照落地形态，落到一张风险分级到控制组合的矩阵。
《Agent 工程笔记》系列
- Agent Loop 工程笔记
- Agent 状态管理工程笔记
- Agent 消息与事件工程笔记
- Agent 中间件工程笔记
- Agent 工具调用工程笔记
- Agent MCP 工程笔记
- Agent Skill 工程笔记
- Agent Memory 工程笔记
- Agent 上下文工程笔记
- Agent 安全执行工程笔记（本篇）
《Agent 工具调用工程笔记》把工具调用讲成「请求 → 解析 → 执行 → 回写」的控制流，并点明它是 agent 第一次产生副作用（side effect）的环节——调数据库、发消息、改文件、跑代码，全都打破纯计算的边界，对外部环境造成不可逆的改变，或依赖会变的状态。前面几篇让 agent 会思考、会记忆、会传信号，但都不碰外部真实系统；工具调用是第一次真正动手。那篇文章末尾留了一句：权限、沙箱、HITL 三者都是执行前的闸，深度在第 10 期。本篇就是那句钩子的落点。
动手这件事的麻烦在于：模型不是可信主体。它会按指令办事，但指令可能来自别处——工具返回里夹带的恶意提示、检索到的投毒文档，都会让它调用不该调的工具；它也会单纯看错，把「删一个文件」理解成「删整个目录」；更常见的是被赋权过度，拿着能删库的凭证去跑一个本该只读的查询。所以工具的安全执行是独立学科，它不关心工具语义对不对，只关心「这一下调用到真实系统之前，怎么拦住不该发生的后果」。
这道关由三道闸组成，而且都在执行前，不在执行后：权限（permission）决定这次调用能不能做；沙箱（sandbox）决定即使被放行，做坏了能波及多大范围；human-in-the-loop（HITL，人在回路）决定这个后果要不要人先签字。三者守的层次不同，能互相补位，但也都不能替代彼此。
一、危险从哪来
先列清楚工具一跑会出什么岔子，才知道三道闸各自堵哪类。四类威胁不在同一层：
注入劫持。工具返回或检索内容里夹带指令，模型照做，调了不该调的工具、或给危险工具喂了恶意参数。这和《Agent 上下文工程笔记》里的上下文投毒是同一件事，只是视角从上下文窗口转到了执行边界——投毒的目的往往是拐弯让 agent 去执行一个动作。权限的 allow/deny 拦不住它（模型是「合法」地想调工具），防护的另一层在结果进模型之前：工具返回先过一层输出净化（剥离可执行指令标记、按 schema 归一化），把不可信输出和模型可执行指令隔开，防止结果里的指令被当成语意二次注入。
幻觉 / 误判。模型自己看错：调错工具、参数填错、范围过宽。一个「删日志」的请求被理解成「删整个数据目录」，一次「读公开资料」被扩成「抓取内网全文」。这类不依赖外部攻击，纯属模型的概率性失误，但后果一样严重。
越权 / 逃逸。工具拿到的凭证比任务需要的多（一把主密钥能碰所有库），或者沙箱没封住，工具摸到了宿主机文件系统、别的租户的数据、或本不该连的外网。权限和沙箱两道闸任一道失效，就会落到这一类。
凭证泄露。工具返回值里带出秘密（token、私钥），被写进上下文、落进日志、或回传给不可信的下游；另一种更隐蔽的是把主密钥直接塞进 prompt，让模型生成的代码在沙箱外也能用。OpenAI 的沙箱文档把这条写成一条硬原则：凭证是运行时配置，不是 prompt 内容。
四类威胁的层次错开，意味着一道闸堵不全：注入劫持靠权限的 allow/deny 拦不住（模型是「合法」地想调）；越权逃逸靠 HITL 拦不住（人批的是「调工具」不是「凭证范围」）；凭证泄露靠沙箱拦不住（它在执行前就发生了）。所以三道闸是正交的三层，不是同一个动作的三种说法。
二、三道闸分别守哪一层
把三道闸拆到层，各自回答的问题不一样：
权限（策略层）——这次调用是否被授权？在模型决定执行之后、runtime 解析工具名之后、真正跑之前，做一次 allow/deny 判定。它回答「能不能做」。判定的输入是工具、动作、资源、调用者身份、当前上下文，输出是一句话：放或不放。
沙箱（执行层）——即使被授权，爆炸半径（blast radius）多大？隔离文件系统、网络、凭证、进程，把「这一下调用的破坏范围」圈在一个可丢弃的边界里。它回答「做坏了能波及多大」。
HITL（判断层）——这个后果要不要人先签字？对不可逆、外部可见、或代价高的动作，在跑之前暂停，把控制权交回人，等一个明确决定再继续。它回答「谁为后果拍板」。
三者正交、互补：权限说 yes/no，沙箱给那个 yes 设上限，HITL 在 yes 之前插一个人。一个动作可能同时过三道——删生产库要先被权限放行（你在授权范围内）、在沙箱里预演或受限执行（范围可控）、还要人批（后果不可逆）。反过来，只读本地文件可能只要权限白名单兜住，不需要沙箱也不需要人。
还有一根贯穿的线：审计日志。它不是闸，是事后取证——记录谁、在什么上下文、调了什么、参数是什么、结果如何。三道闸挡住该挡的，审计兜住挡不住的（或挡错了的）那一小部分，让出了事能回溯。本篇把审计当贯穿能力讲，不单独成章。
三、权限的设计
权限这一层要解决的问题是「默认放行还是默认拒绝」。工程上的答案是默认拒绝（deny-by-default）：白名单列清楚能做什么，没列的一律不放行。黑名单（列清楚不能做什么）会漏——模型总能想出黑名单之外的写法。
最小权限（least privilege）。工具按动作和资源拆细：读配置和删配置不是同一个权限，读公开桶和读私有桶不是同一个权限。agent 用任务专属身份去执行，拿窄 scope，而不是一把主密钥走天下。OWASP 把这类风险叫「过度代理（excessive agency）」，它由三件叠出来——过度功能（暴露了不需要的工具）、过度权限（工具的 scope 太宽）、过度自主（不需要人批的也自己跑了）。减风险就是把这三件分别压下去：只挂任务要用的工具、给最小 scope、该批的批。
判定的维度。一次调用授权与否，通常看这几条：per-tool（这个工具本身在不在允许集）、per-action（同工具的危险动作是否单列，如 delete vs read）、per-resource（作用在哪个资源，路径/桶/库）、per-user / per-tenant（谁发起的，跨租户必须带 owner 维度，否则就是第 9 期讲的跨租户泄漏）、per-context（当前任务阶段是否允许，如规划期只读、执行期才写）。
闸的位置。权限判定在工具真正执行前，落在中间件「执行前」切面（《Agent 中间件工程笔记》里的 onActing 一类）——runtime 解析出工具名和参数后、调用函数前，先过一遍策略。这点和《Agent 工具调用工程笔记》的四步控制流对得上：解析之后、执行之前，正好是插权限闸的缝。
认证和授权分开。模型不是 principal（被授权主体），它只是提议「调哪个工具、传什么参」。真正执行用的是 agent 的凭证，授权策略决定这次提议放不放行。把模型当主体、用模型身份去执行，是后面失效模式里会单独点的坑。
用户身份透传（OBO）。企业级场景里真正的 principal 是触发任务的 en
