MCP 让工具接入变容易，也让工具信任问题变复杂。一个 Server 暴露的工具描述不应被 runtime 无条件信任。规范本身也提醒，工具描述等行为注解应被视为不可信，除非来自可信 Server。 因此，MCP 工具审批建议按 Server 信任级别分层： Server 类型 默认策略 官方可信、
工具结果、日志、文件片段进入模型上下文前，应经过 secret scanning。至少检查： API key； OAuth token； 私钥； .env； cloud credential； 数据库连接串； 内部域名和个人信息。 发现 secret 后，不要把原文注入模型。可以替换成 REDACT
用户审批不能只当 UI 事件。对 runtime 来说，它是一条系统事实，每次都应写入 audit log： 恢复执行时，这些记录尤其重要。已经被拒绝的危险工具，不能因为进程重启就再次自动执行。已经批准的一次性操作，也不应无限期复用授权。
能力越大，边界越要清楚。本章谈权限和安全。 Agent 的能力来自工具，风险也来自工具。一个不会调用工具的模型，最多说错话；一个能执行命令、写文件、联网、访问数据库的 Agent，可能造成真实损失。Runtime 的安全目标不是把 Agent 绑住，而是让它在明确边界内做事；越过边界时，停下来请人确认，或者直接拒绝。 安全不是最后加的一层'确认弹窗'。它应该
目标：给 MCP 工具接入增加风险分类和审批层。 功能范围： MCP 工具 discovery 后先做 risk classification； 高风险工具需要用户确认； 非交互模式使用 policy 自动裁决； 所有审批写入 audit log； 工具列表变化时更新模型上下文。 适合证明： MCP
最基本的边界是 workspace。读写文件工具必须把路径解析到工作区内，禁止 ../ 逃逸，禁止跟随不可信符号链接访问外部敏感路径。 这段代码不是完整沙箱，但它表达了原则：所有文件能力都必须经过路径边界检查。不要把模型生成的路径直接交给文件系统。
你应该能解释为什么 Agent 不能直接执行任意 shell；能为 MCP 工具设计权限审批策略；能区分 schema 校验、权限策略和用户确认；能保证恢复执行后不会重复越权。
工具通常分散在文件系统、终端、浏览器、搜索、编辑、MCP 等模块里。读工具时问： 工具 schema 在哪里定义？ 描述如何送给模型？ 参数在哪里校验？ 执行前是否有 preview？ 用户确认如何表达？ 失败如何反馈给模型？ 输出如何截断？ 如果一个项目有 MCP，继续问： MCP Server
coding agent 很容易倾向'缺包就装'。但安装依赖是供应链入口。Runtime 至少应要求： 展示包名和版本； 优先使用 lockfile； 对陌生包提高审批等级； 对 install scripts 保持警惕； 必要时使用 ignorescripts； 记录 package manage
实现 Tool Permission Matrix： 对文件路径做 workspace whitelist； 对 shell 命令做风险分类； 对 destructive 操作默认拒绝； 对 write/network/install 操作生成 preview 并请求确认； 所有审批写入 audit
能力越大，边界越要清楚。本章谈权限和安全。 Agent 的能力来自工具，风险也来自工具。一个不会调用工具的模型，最多说错话；一个能执行命令、写文件、联网、访问数据库的 Agent，可能造成真实损失。Runtime 的安全目标不是把 Agent 绑住，而是让它在明确边界内做事；越过边界时，停下来请人确
高风险工具执行前，应给用户看到 preview。 写文件要给 diff preview；执行命令要给 command preview；联网请求要给域名、方法、数据范围；安装依赖要给包名、版本、lockfile 影响；数据库操作要给目标库、表、迁移摘要。 图 42：工具系统的风险矩阵。风险来自能力、参
Shell 是 Agent Runtime 中最危险也最有用的工具。建议把命令分级： 等级 示例 策略 safe read pwd, ls, rg, cat, sed, wc 可自动执行，限制路径和输出 write touch, mv, cp, applypatch 需要 diff 或 previe
