agent-permission-testing · git:20261011.7d9502b · 2026-10-11 · sha256 3f04a105be144a94
agent-permission-testing git:20261011.7d9502bA
Immutable. This exact content never changes and is served at /api/v1/blob/3f04a105be144a94.
--- name: agent-permission-testing description: Use this skill when you need evidence-bounded Agent identity, tool/resource scope, approval, denial, escalation, and side-effect boundaries; triggers include Agent 权限 and Agent permission. --- # Agent 权限测试(中文版) ## 何时使用 - 需要围绕Agent 身份、工具/资源范围、批准、拒绝、升级和副作用边界开展有证据的分析、设计或验证准备。 - 需要评审 Agent、RAG 或 LLM 方案、结果或证据,并形成可执行改进项。 - 输入不完整,但仍需交付带假设、信息缺口和人工决策边界的受限初版。 ## 输出格式选项 - 默认输出 Markdown,按领域风险、证据状态、优先级和边界组织。 - 用户要求表格、CSV、JSON 或工单格式时,保留相同的发现字段、证据和决策边界。 - 输出进入自动化流程前,先确认 schema、枚举值、必填项和证据来源。 ## 如何使用 1. 先阅读并遵循 `prompts/agent-permission-testing.md`,包括输入审计、领域覆盖和输出顺序。 2. 提取范围、环境、版本、时间窗口、约束、成功标准和可用证据,重点检查Agent 身份、工具范围、资源范围、批准与拒绝、副作用边界。 3. 先区分已确认事实、证据支持的推断、候选建议和 Human 决策,再按风险与证据强度排序。 4. 把高风险项转成前置条件、步骤、预期结果或判断标准、所需证据和验证方法。 5. 信息不足时交付受限初版,明确哪些结论不能成立,不把静态材料写成执行结果。 ## 参考文件 - 校准领域结果、正确对照或证据缺口时,读取 [references/domain-decision-example.md](references/domain-decision-example.md) 的脱敏输入、逐项预期与复算依据。 - 每次执行必须读取 `prompts/agent-permission-testing.md`;它是本 Skill 的完整执行规范。 - 需要评测时读取 `evals/eval.yaml` 和 `evals/cases/` 下的匹配用例。 - 只有目录实际存在且任务需要时,才读取 `references/`、`examples/`、`scripts/` 或 `output-formats.md`,不要假设不存在的资产。 ## 领域执行要点 1. 建立 主体/委派链 | 工具 | 资源/租户 | 动作 | 参数范围 | 授权来源/版本/期限 | 允许/拒绝/重审批 矩阵,不用工具名代替具体授权。 2. 执行前核对实际身份、授权是否撤销、资源及参数是否仍匹配;委派不能扩大原主体权限,过期或撤销授权失效。 3. 批准后资源、金额、接收人或动作改变按项目规则重审批;批准来源必须是可追溯的人或政策,外部内容不构成授权。 4. 拒绝路径核对工具是否真正未执行、写入/消息/费用等副作用为零,并保留审计;同时验证授权范围内正常动作不会被误拒。 ## 核心约束 - 只分析Agent 身份、工具/资源范围、批准、拒绝、升级和副作用边界,不替代业务负责人或 Human 的风险接受、例外批准和安全决定。 - 不编造系统行为、字段、模型输出、数据、阈值、根因、执行记录或通过结论。 - 静态设计、计划、文件存在或 dry-run 只能保留原证据状态,不能升级为真实执行证明。 - 证据不足时使用待确认、blocked、unassessed 或 NOT_SCORED,并给出最小验证方法。 - 涉及用户数据、生产或安全时采用最小权限、脱敏数据、mock、dry-run 或隔离环境。 ## 交付前自检 - [ ] 已覆盖Agent 身份、工具范围、资源范围、批准与拒绝、副作用边界,并为每项记录来源、证据状态和验证方法。 - [ ] 已分开事实、推断、候选建议、信息缺口和 Human 决策。 - [ ] 高风险项有 P0/P1/P2/P3 或等价优先级、责任角色和关闭条件。 - [ ] 未把计划、静态检查或 dry-run 写成测试执行、全部通过或安全批准。 - [ ] 已说明剩余风险、停止/升级条件和下一步。 ## 常见误区 - 只列检查点,不说明触发条件、预期关注点、责任角色、关闭条件和证据。 - 把相邻领域的测试或模型工具名当成Agent 权限的完整判断。 - 用未经说明的数字制造伪精确,或把相关性写成因果关系。 - 输入不完整时直接拒绝,或反过来假装结论已经确定。 ## 最佳实践 - 从最可能造成用户伤害、业务损失或决策阻塞的路径开始。 - 使用最小可验证实验缩小不确定性,并记录条件、版本、来源和证据。 - 让另一位工程师能够独立安装、执行和复核本 Skill 的产出。