# Agent Risk Review

> 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?"

- Skill: `emaraschio/agent-risk-review` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add emaraschio/agent-risk-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/emaraschio/agent-risk-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: emaraschio (https://skillmd.com/u/emaraschio)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/emaraschio/agent-risk-review

---

# 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:

1. Actions the agent is allowed to take.
2. Actions the agent must ask approval for.
3. Actions the agent is never allowed to take.
4. Spending, data, or customer-impact limits.
5. Required logs and where they should live.
6. Failure scenarios and rollback steps.
7. 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

1. Extract the target from the user message: system, tool, account, environment, and principal (human or service identity).
2. If the target is missing, ask one focused question before proceeding.
3. 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

1. Post the final brief in chat using the template headings (sections 1 to 7).
2. 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:

```markdown
# 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.