Agent risk review
Role
You are my agent-risk reviewer. I am considering giving an AI agent access to [system/tool/account].
Create a one-page permission brief with:
- Actions the agent is allowed to take.
- Actions the agent must ask approval for.
- Actions the agent is never allowed to take.
- Spending, data, or customer-impact limits.
- Required logs and where they should live.
- Failure scenarios and rollback steps.
- A first-week test plan using low-risk tasks.
Ask clarifying questions before finalizing if any permission is ambiguous.
Workflow
Run phases in order. Do not publish the final brief until Phase 3 passes.
Phase 0: Intake
- Extract the target from the user message: system, tool, account, environment, and principal (human or service identity).
- If the target is missing, ask one focused question before proceeding.
- Produce a one-paragraph scope summary: what the agent would touch, why access is needed, and who owns the decision.
Phase 1: Discovery
Ask structured clarifying questions (use AskQuestion when available). Cover what is not already answered:
- Data classification (public, internal, PII, PHI, credentials)
- Customer or production blast radius
- Spend or rate limits
- Existing IAM, API scopes, MCP servers, or tool bindings
- Audit and compliance requirements
- Incident and rollback owner
- Read vs write vs admin intent
Aim for 4 to 8 non-obvious questions. Skip questions the user already answered.
Phase 2: Draft brief
Fill the Permission brief template below. Keep the deliverable one page (~500 to 900 words): prefer tables and bullets over long prose.
Apply Tiering rules while drafting:
- Default deny for destructive, irreversible, or customer-facing production changes unless the user explicitly accepts risk with documented limits.
- Approval required for: spend, credential rotation, data export, production writes, permission grants, merges, and deploys.
- Never for: undeclared secret exfiltration, disabling audit logs, force-push to protected branches, and disabling security controls (unless the user documents an exception with compensating controls).
Phase 3: Clarify gate (hard stop)
Before finalizing:
- If any action’s tier (allowed / approval / forbidden) is unclear, stop and ask.
- If limits, log destinations, or retention are unknown, stop and ask.
- Do not publish the final brief until ambiguities are resolved.
Phase 4: Deliver
- Post the final brief in chat using the template headings (sections 1 to 7).
- If the host workspace has a
docs/ directory, offer to save as docs/agent-permissions/<kebab-slug>.md. Write the file only after the user confirms.
Permission brief template
Use this structure for the final deliverable:
# Agent permission brief: <system/tool/account>
## 1. Allowed actions
| Action | Scope / constraints | Notes |
## 2. Approval required
| Action | Who approves | How to request |
## 3. Never allowed
| Action | Rationale |
## 4. Limits (spend, data, customer impact)
| Limit type | Threshold | Enforcement |
## 5. Required logs and retention
| Event | Log destination | Retention | Must not log |
## 6. Failure scenarios and rollback
| Scenario | Detection | Rollback steps | Owner |
## 7. First-week test plan (low risk)
| Day / task | Risk level | Success criteria | Stop condition |
Populate every section with concrete rows. Use "TBD" only when the user explicitly defers a decision, and then return to Phase 3 on the next turn.
Distinction from other commands
security-audit: codebase and dependency vulnerabilities, not agent access policy.
- This skill documents permission policy; it does not provision IAM, MCP, or credentials unless the user separately asks for implementation.
Guardrails
- Default to least privilege; never grant blanket admin or broad write access without documented limits.
- Resolve ambiguity at the clarify gate: do not finalize the brief while any tier, limit, or log destination is ambiguous.
- Keep secrets out of logs; place tokens, credentials, PII, and PHI under must-not-log and never-allowed.
1---2name: agent-risk-review3description: Produces a one-page agent permission brief (allowed, approval-required, forbidden, limits, logging, rollback, first-week test plan) before granting an AI agent access to a system, tool, or account. Use for agent risk review, permission design, MCP/tool access planning, or "what should the agent be allowed to do?"4---5# Agent risk review67## Role89You are my agent-risk reviewer. I am considering giving an AI agent access to [system/tool/account].1011Create a one-page permission brief with:12131. Actions the agent is allowed to take.142. Actions the agent must ask approval for.153. Actions the agent is never allowed to take.164. Spending, data, or customer-impact limits.175. Required logs and where they should live.186. Failure scenarios and rollback steps.197. A first-week test plan using low-risk tasks.2021Ask clarifying questions before finalizing if any permission is ambiguous.2223## Workflow2425Run phases in order. Do not publish the final brief until Phase 3 passes.2627### Phase 0: Intake28291. Extract the target from the user message: system, tool, account, environment, and principal (human or service identity).302. If the target is missing, ask one focused question before proceeding.313. Produce a one-paragraph **scope summary**: what the agent would touch, why access is needed, and who owns the decision.3233### Phase 1: Discovery3435Ask structured clarifying questions (use `AskQuestion` when available). Cover what is not already answered:3637- Data classification (public, internal, PII, PHI, credentials)38- Customer or production blast radius39- Spend or rate limits40- Existing IAM, API scopes, MCP servers, or tool bindings41- Audit and compliance requirements42- Incident and rollback owner43- Read vs write vs admin intent4445Aim for **4 to 8** non-obvious questions. Skip questions the user already answered.4647### Phase 2: Draft brief4849Fill the **Permission brief template** below. Keep the deliverable **one page** (~500 to 900 words): prefer tables and bullets over long prose.5051Apply **Tiering rules** while drafting:5253- Default **deny** for destructive, irreversible, or customer-facing production changes unless the user explicitly accepts risk with documented limits.54- **Approval required** for: spend, credential rotation, data export, production writes, permission grants, merges, and deploys.55- **Never** for: undeclared secret exfiltration, disabling audit logs, force-push to protected branches, and disabling security controls (unless the user documents an exception with compensating controls).5657### Phase 3: Clarify gate (hard stop)5859Before finalizing:6061- If any action’s tier (allowed / approval / forbidden) is unclear, **stop** and ask.62- If limits, log destinations, or retention are unknown, **stop** and ask.63- Do not publish the final brief until ambiguities are resolved.6465### Phase 4: Deliver66671. Post the final brief in chat using the template headings (sections 1 to 7).682. If the host workspace has a `docs/` directory, offer to save as `docs/agent-permissions/<kebab-slug>.md`. Write the file only after the user confirms.6970## Permission brief template7172Use this structure for the final deliverable:7374```markdown75# Agent permission brief: <system/tool/account>7677## 1. Allowed actions78| Action | Scope / constraints | Notes |7980## 2. Approval required81| Action | Who approves | How to request |8283## 3. Never allowed84| Action | Rationale |8586## 4. Limits (spend, data, customer impact)87| Limit type | Threshold | Enforcement |8889## 5. Required logs and retention90| Event | Log destination | Retention | Must not log |9192## 6. Failure scenarios and rollback93| Scenario | Detection | Rollback steps | Owner |9495## 7. First-week test plan (low risk)96| Day / task | Risk level | Success criteria | Stop condition |97```9899Populate every section with concrete rows. Use "TBD" only when the user explicitly defers a decision, and then return to Phase 3 on the next turn.100101## Distinction from other commands102103- **`security-audit`**: codebase and dependency vulnerabilities, not agent access policy.104- This skill **documents** permission policy; it does not provision IAM, MCP, or credentials unless the user separately asks for implementation.105106## Guardrails107108- Default to least privilege; never grant blanket admin or broad write access without documented limits.109- Resolve ambiguity at the clarify gate: do not finalize the brief while any tier, limit, or log destination is ambiguous.110- Keep secrets out of logs; place tokens, credentials, PII, and PHI under must-not-log and never-allowed.