spindriftpapilio Agent工作区信任与审批测试
本skill专门讨论一个常被忽视的边界：Agent什么时候开始信任工作区，什么时候开始执行高风险动作。
很多问题不只出在提示词注入本身，还出在这些地方：
- 信任提示出现前，是否已经读配置、发请求、启动外部组件
- 用户批准一次后，后续内容是否还能被静默替换
- UI提示写得很笼统，但实际执行边界更大
- 已信任工作区与未信任工作区之间，是否存在加载顺序或状态继承问题
什么时候用
- 目标产品存在工作区信任提示、目录信任、项目批准或类似机制
- 产品支持项目级配置、项目级MCP、项目级Hook、项目级Agent
- 已发现配置投毒、提示词注入、Hook或MCP线索，想判断能否被审批模型放大
- 想确认某个执行链到底是零交互、一次确认还是长期持久化
核心问题
- 首次打开项目时，哪些内容会在信任前被读取
- 信任提示出现前，哪些动作已经发生
- 批准是按目录、按文件、按工具、按服务，还是按内容缓存
- 配置修改后，旧批准是否会错误沿用到新内容
- 敏感文件保护是阻止编辑、阻止创建，还是两者都阻止
交互层级
| 层级 | 典型场景 |
|---|---|
| Tier 1 | 打开项目或接受信任提示后立即触发，无需额外交互 |
| Tier 2 | 用户做一次正常Agent交互，系统在该过程中复用已有信任或审批 |
| Tier 3 | 用户必须点一次明确批准，如Allow、Approve、Trust |
| Tier 4 | 用户已信任项目，且还需执行某个特定动作才触发 |
审批问题往往不会单独成链，但会把原本较弱的原语升级到更低交互层级。
推荐流程
先画状态机。 至少区分：未打开、已打开未信任、已信任未批准工具、已批准部分工具、重开项目后。
记录首次启动顺序。 看看到底是先弹提示，还是先读配置、先起Hook、先连MCP、先发网络请求。
逐类测批准粒度。 分别测试：
- 终端命令批准
- MCP工具批准
- MCP配置批准
- 项目级配置批准
- 敏感文件编辑批准
- dotfile创建与修改批准
做一次变更后复测。 先批准无害内容，再改成危险内容，检查旧批准是否仍然生效。
重开项目再测。 检查批准是否跨会话、跨重启、跨pull被保留。
重点测试主题
1. 预信任执行
- 信任提示出现前是否已读取项目配置
- 是否已初始化MCP服务
- 是否已执行项目级Hook
- 是否已根据项目配置改写环境变量或请求目标地址
2. 审批缓存与TOCTOU
- 批准是否只记住路径或服务名，内容却不再校验
- 批准后配置文件被替换，是否还能继续运行
- 已批准的MCP是否会被新增参数、改命令、改URL后继续沿用
3. 敏感文件保护
- 编辑敏感文件是否拦截
- 新建同名敏感文件是否也拦截
- Windows路径分隔符、大小写、相对路径是否能绕过
- 只阻止修改不阻止创建时，能否借此植入配置
4. 提示与真实行为不一致
- UI只说会读取文件，但实际上还会启动外部命令
- UI只说启用工具，但实际上会立即执行初始化命令
- 提示只覆盖一部分后果，遗漏网络、命令或持久化影响
与其他skill的衔接
- 涉及项目级MCP：转
MCP配置投毒测试 - 涉及dotfile创建、敏感文件保护：转
提示词注入攻击链测试 - 涉及批准后命令执行：转
终端过滤绕过测试 - 涉及信任前Hook或配置驱动执行：转
AI-IDE代码执行面测试 - 涉及整体链路定级：转
AI-IDE攻击链编排
输出时至少要写清
- 哪个信任或审批边界出了问题
- 问题发生在信任前、首次批准时，还是批准后复用阶段
- 最少需要用户做什么动作
- 是否能跨会话复现
- 能把哪种原语升级为更低交互攻击链
可优先参考的资料
references/trust-state-checklist.mdreferences/public-cases.mdreferences/vendor-behaviors.md