KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
07. 工具、代码和网络如何把文本风险放大？ — keel 龙骨
没有工具的模型最多生成不当文本；连接文件、Shell、浏览器、数据库和外部 API 后，文本决策可以转化为代码执行、数据外泄和业务破坏。工具能力决定攻击面的大小。
没有工具的模型最多生成不当文本；连接文件、Shell、浏览器、数据库和外部 API 后，文本决策可以转化为代码执行、数据外泄和业务破坏。工具能力决定攻击面的大小。
Tool Misuse 不一定利用软件漏洞
一个完全正常的 send_email(to, body) 工具，也可能被模型用来把内部数据发给攻击者。工具实现没有缓冲区溢出，行为仍然不安全。
因此要同时检查：
- 工具是否应该对当前 Agent 可见；
- 当前主体是否有权调用；
- 参数和资源是否在 scope 内；
- 调用序列是否符合业务约束；
- 结果是否可能形成新的不可信指令；
- 副作用是否需要审批、幂等和隔离。
结构化动作代替任意命令
危险接口：
subprocess.run(model_output, shell=True)
更安全的方向：
RestartService(service_id="payment-service", environment="staging")
执行器使用固定二进制和 argv，不经过 Shell 解释；service_id 解析到注册资源，不直接拼路径。即使 shell=False，任意 argv 仍可能调用高权限程序，所以动作白名单和低权限运行同样必要。
SSRF 不只检查 URL 长相
攻击者让 Agent 请求 http://169.254.169.254/、localhost、内网管理地址或经过 DNS rebinding 的主机。URL 语法完全合法。
防护组合：
- 只允许明确业务域名和协议；
- 解析 DNS 后拒绝 loopback、link-local、private 等禁用网段；
- 每次重定向重新校验；
- 禁止用户控制 OAuth metadata 和 callback 地址；
- 通过受控 egress proxy 发出请求；
- 云环境阻断 metadata 访问并使用工作负载身份。
MCP 安全文档把 OAuth metadata discovery 引发的 SSRF、session hijacking、本地 server compromise 和 scope minimization 单独列出，说明协议连接层本身就是安全边界。
沙箱限制最坏影响
对代码、Shell 和浏览器执行，至少考虑：
非 root 用户
只读基础文件系统 + 独立临时工作区
CPU / 内存 / 进程数 / 磁盘 / 时间限制
默认关闭网络，按任务开放域名
不挂载宿主 Docker socket、SSH key、云凭据
系统调用 profile、capability drop、no-new-privileges
每次任务使用新环境并销毁
沙箱逃逸仍可能存在，所以外部账号与 token 也必须最小权限。不能因为“在容器里”就放入生产管理员凭据。
Tool result 也要校验
外部工具可能返回恶意文本、超大数据、错误 MIME 类型或伪造状态。Adapter 应限制大小、解析结构、校验签名/状态码并标记来源。工具返回 {"approved": true} 不能覆盖审批存储中的事实。
运行隔离策略实验
python courses/advanced/safety-controls/course/project/examples/03_isolation_policy.py
示例只验证结构化网络目标和命令动作，不执行真实网络或 Shell。把域名改成 IP、私网地址或未注册命令，观察它在执行前被拒绝。
检查理解
- 合法工具为什么仍可能被滥用？
shell=False为什么不等于任意命令安全？- 域名 allowlist 为什么还要检查 DNS 解析和重定向？