专题演讲嘉宾：黄鸿波

当 Agent 能够调用工具后，模型生成的 ToolCall 就可能转化为文件读取、数据修改和外部发送等真实操作。本次演讲将围绕 ToolCall 的授权问题，介绍如何将主体、任务与工具能力建模为程序可检查的权限数据，并通过 Policy Engine 和统一执行入口强制控制工具调用。最后结合审计追踪、确定性重放与 CI 测试，构建可验证、可回归的 Agent 工具权限边界。

演讲提纲

1. ToolCall 为什么不能直接执行
   • 从模型判断到真实副作用用一个简短攻击场景说明：外部内容影响模型后，候选 ToolCall 如何被执行器转化为文件读取、数据修改或外部发送
   • 候选动作与授权事实拆解 ToolCall 中缺失的信息：当前主体是谁、正在执行什么任务、工具拥有什么能力，以及该动作是否符合程序侧权限
2. 建模：把工具权限变成程序可检查的数据
   • ToolManifest 与 Capability通过 READ、WRITE、EXECUTE、NETWORK 等 Capability 描述工具能力，并使用参数 Schema 对模型生成的调用进行 fail-closed 校验
   • SubjectContext 与 TaskContract将主体角色、任务允许的工具和能力固化为可信上下文，演示同一个 write_file 为什么在不同主体和任务下分别得到 ALLOW 或 DENY
3. 强制执行：让 Policy 真正控制工具调用
   • 默认拒绝与固定检查顺序实现参数合法性、工具注册、主体角色、任务工具白名单和 Capability 等检查；首项失败立即拒绝，未执行的检查记录为 NOT_RUN
   • PolicyEnforcedToolExecutor将 Request Builder、Policy Engine 和 Delegate 封装在统一执行入口，确保只有 ALLOW 能够到达下层工具，业务代码不能把策略判断当作可选建议
4. 工程验证：把执行边界做成可回归契约
   • 参数冻结与 Policy Trace通过 Canonical JSON 和不可变参数快照，保证权限检查与实际执行使用同一组参数；同时记录每一步检查及其失败原因
   • Deterministic Replay 与 CI使用固定 Scenario 生成权限矩阵和测试断言，在工具、任务和策略配置变化后，通过 CI 检查授权边界是否发生退化或漂移

听众收益

• 理解 ToolCall、工具能力与真实执行权限之间的区别，避免把模型判断误认为系统授权
• 掌握一套可落地的工具权限建模方法，明确“谁在什么任务中，可以使用什么工具、执行什么能力”
• 学会设计默认拒绝、失败即停止的权限检查链，覆盖参数、工具、主体、任务和 Capability 等关键维度
• 掌握 PolicyEnforcedToolExecutor 的实现思路，让所有工具调用必须经过统一的策略决策与执行入口
• 学会利用 Policy Trace、确定性重放和 CI 测试持续验证权限边界，及时发现配置漂移和授权退化

演讲亮点

• 从真实攻击链切入：完整呈现“外部内容影响模型—生成 ToolCall—执行器产生真实副作用”的风险路径
• 不依赖模型自觉：权限判断由可信的程序上下文和确定性策略完成，不把安全建立在提示词或模型拒绝之上
• 同一动作的差异化授权：通过具体示例展示同一个 write_file 调用，如何因主体和任务不同分别得到 ALLOW 或 DENY
• 策略与执行强绑定：把 Request Builder、Policy Engine 和 Delegate 封装为统一入口，防止业务代码绕过权限检查
• 完整工程闭环：从权限建模、强制执行到审计追踪、确定性重放和 CI 回归，形成一套可以直接迁移到 Agent 项目的 Tool Permission System