Install
$ agentstack add skill-emaraschio-cursor-commands-agent-risk-review ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
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/.md. Write the file only after the user confirms.
Permission brief template
Use this structure for the final deliverable:
# Agent permission brief:
## 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.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: emaraschio
- Source: emaraschio/cursor-commands
- License: MIT
- Homepage: https://github.com/emaraschio/cursor-commands#readme
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.