直接答案
编码代理威胁模型应把提示、仓库内容、工具结果和外部资源视为可能不可信的输入，把文件写入、命令执行、网络访问、凭据和发布视为特权动作；在每个边界实施最小权限、沙箱、审批、秘密隔离、输出审查和可审计验证。
关键结论
- 分别建模数据输入与动作能力的信任边界。
- 按任务和环境授予权限，而不是按使用便利性。
- 秘密不得进入提示、仓库、生成补丁和普通日志。
- 预防控制必须配套检测、吊销、回滚和事件证据。
关键事实
这篇内容解决什么问题
帮助工程与安全团队在开放真实能力前审查编码代理部署。
核验范围与限制
- 证据类型
- 官方文档协议规范
- 核验范围
- 模型把已公开的客户端控制映射到仓库、执行、凭据、网络和交付边界。
- 限制与失效条件
- - 不能替代针对具体系统的安全评估。
- - 云端、IDE 与 CI 控制存在差异。
- - 不宣称任何客户端配置可以消除提示词注入。
先画系统，再列威胁
标出用户、客户端、模型端点、仓库、Shell、工具服务器、网络目标、秘密存储、CI Runner 与部署目标，注明数据跨越进程、机器、账号和组织的位置。绑定到具体数据流的威胁比泛泛的 AI 风险更容易控制。
读取能力与动作能力必须分开。读取公开源码和执行源码注释里的命令，即使出现在同一对话中，也属于不同安全事件。
优先保护资产和可信的滥用途径
重点资产包括凭据、专有源码、个人数据、签名密钥、生产状态与发布权限。可信滥用途径包括恶意仓库指令、依赖脚本、被入侵的工具服务器、过宽 Shell 权限、日志泄密和未经审查的补丁进入生产。
应结合真实环境评估影响和可能性。只读的一次性克隆与持有云凭据和发布权限的长期 Runner，风险等级完全不同。
在任务开始前实施最小权限
使用干净 worktree 或一次性 Runner，收窄文件系统范围，限制网络目标，只把短期凭据注入真正需要的进程，并对改变外部状态的工具单独审批。工具服务器和依赖安装命令必须固定来源并经过审查。
- 先只读探索，再允许写入
- 先限定工作区，再考虑更广权限
- 命令和网络目标采用允许列表
- 本地会话不持有生产凭据
- 发布与破坏性操作必须由人批准
把检测和恢复与预防一起设计
记录脱敏动作元数据、权限变化、工具身份、仓库 revision 与验证结果。对意外网络目标、受保护路径变更、秘密扫描命中、连续审批失败和异常发布动作发出告警。
在开放自治动作前准备密钥吊销、工具停用、Runner 隔离、补丁回滚和制品作废流程。
能力变化时重新审查模型
增加模型供应商、启用新 MCP、调整沙箱、迁移到 CI 或开放部署权限时，都应重复审查。可以用无害测试验证被拒绝的路径、目标或动作，但禁止在生产环境测试破坏性行为。
官方来源与核验范围
本文以公开官方文档为事实依据；命令和配置可能随客户端版本变化，执行前请同时核对对应来源。
查看技术核验方法