Agent risk review
Skill emaraschio/cursor-commands/.cursor/skill-contracts/agent-risk-review
Production-grade Cursor slash commands with paired skill contracts, behavioral evals, and ship-gate CI. Install as a user plugin.
npx -y skills add emaraschio/cursor-commands --skill agent-risk-reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.md
4.5 KB, as published. Nobody here has run it
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 asdocs/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.