| name | Agent工作区信任与审批测试 |
| description | 测试Agent或AI IDE的工作区信任、审批提示、敏感文件保护与权限缓存模型。 适用于评估首次打开项目、切换信任状态、批准工具调用、批准MCP或批准配置后, 是否存在预信任执行、审批复用、TOCTOU、提示弱化或范围漂移。
|
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.md
references/public-cases.md
references/vendor-behaviors.md