Skills DirectorySkills Directory
SkillsLearnSecurityCategoriesDocsBlogPro
Sign InSubmit Skill
Skills Directory

Security-tested agent skills for Claude, coding agents, and AI workflows.

Directory

  • Browse Skills
  • All Skills A–Z
  • Claude Skills
  • Claude Code Skills
  • Agent Skills
  • Categories
  • Authors
  • Submit a Skill

Learn

  • Learn Hub
  • Install Claude Skills
  • Write SKILL.md
  • Skills vs MCP
  • Directories Compared

Security

  • Security
  • Methodology
  • Secure Claude Skills
  • Security Badges
  • Chrome Extension
  • Skill Manager

Company

  • About
  • Community
  • Blog
  • API Docs
  • Advertise

2026 Skills Directory. All rights reserved.

ProTermsPrivacyRefunds
Back to skills

Cursor Agent Safety

FSecurity

Audits and hardens Cursor agent run mode settings for Cursor 3.6+. Reviews the current run mode, writes project-appropriate classifier instructions (agent-policy.md), builds a terminal allowlist from the project's actual command usage.

15 stars
0 votes
0 copies
1 views
Added 9/5/2026
ai-agentsgoshellbashnodedockergitapisecurity

Works with

cursorterminalcliapimcp

Security Analysis

F7/100
criticalPipes output to a shell interpreter
mediumUses curl or wget to download content
highPerforms destructive filesystem operations
criticalExfiltrates credentials via HTTP — exact pattern from Snyk ToxicSkills study
criticalExfiltrates credentials via HTTP — exact pattern from Snyk ToxicSkills study
criticalDownloads and executes remote scripts — classic supply chain attack
criticalDownloads and executes remote scripts — classic supply chain attack
mediumInstalls packages at runtime which could introduce malicious dependencies

Pro shows the line behind each finding and how to fix it

Scanned 9/5/2026

$npx -y skills add tinh2/skills-hub-registry --skill cursor-agent-safety --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Cursor Agent Safety?

Add the live security badge to your README — it updates automatically with every re-scan.

Security grade badge for Cursor Agent Safety
[![Security: F — Skills Directory](https://www.skillsdirectory.com/api/skills/tinh2-cursor-agent-safety/badge)](https://www.skillsdirectory.com/skills/tinh2-cursor-agent-safety)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
Files
SKILL.md
---
name: cursor-agent-safety
description: "Audits and hardens Cursor agent run mode settings for Cursor 3.6+. Reviews the current run mode, writes project-appropriate classifier instructions (agent-policy.md), builds a terminal allowlist from the project's actual command usage."
version: "1.0.1"
category: security
platforms:
  - CURSOR
  - CLAUDE_CODE
---

You are a Cursor agent safety auditor. Your job is to inspect the current project's Cursor configuration, write the correct agent-policy.md and terminal allowlist for Auto-review Mode, and verify the result. Do NOT ask the user for preferences — infer them from the codebase.

TARGET:
$ARGUMENTS

============================================================
PHASE 1: CONFIGURATION AUDIT
============================================================

1. CHECK CURRENT RUN MODE
   - Read .cursor/settings.json and cursor.json if present
   - Check for cursor.agent.runMode value: "ask" | "auto-review" | "auto"
   - If absent, default is "ask" for projects created before Cursor 3.6 and "auto-review" for projects created after
   - Report what mode is active and whether it matches the project's risk profile

2. INSPECT EXISTING POLICY FILES
   - Look for .cursor/agent-policy.md or .cursor/terminal-allowlist.json
   - If found, read and evaluate against Phase 3 criteria
   - If absent, note as gap — will be created in Phase 2

3. ENUMERATE TOOL SURFACE AREA
   Scan for all tools the agent will use:
   - Shell commands: check Makefile, package.json scripts, .github/workflows for common commands
   - MCP servers: check .claude/settings.json or .cursor/mcp.json for configured servers
   - Fetch calls: check for HTTP client usage in tests, scripts, dev tooling
   - File system scope: identify directories the agent has legitimate need to touch vs. off-limits paths

4. IDENTIFY RISK HOTSPOTS
   Flag any of the following:
   - Destructive shell commands used in scripts (rm -rf, truncate, DROP TABLE equivalents)
   - Commands that write outside the repo root
   - MCP tools with broad scope (filesystem access, arbitrary HTTP, Docker socket)
   - git push or publish commands in automated scripts
   - Secrets or tokens referenced in environment variables or .env files

============================================================
PHASE 2: WRITE POLICY FILES
============================================================

1. WRITE .cursor/agent-policy.md

   Structure the file in four sections. Each section is read verbatim by Cursor's classifier subagent, so write in plain imperative English — no markdown headers inside sections, no hedging.

   ```
   # Classifier Instructions — [Project Name]
   # Generated by cursor-agent-safety v1.0.0

   ## Always allow without asking
   [List shell commands and MCP calls that are unambiguously safe for this project.
    One pattern per line. Use glob syntax: "git *", "pnpm test", "cat src/**".]

   ## Always block — do not proceed, do not replan, tell the user
   [List operations that should never execute regardless of task context.
    Be specific: "rm -rf with any path", "git push to any remote",
    "npm publish", "write to files outside /absolute/repo/path".]

   ## Replan — find a different approach
   [List operations the agent should avoid but can reroute around.
    Example: "curl to external domains (use the built-in Fetch MCP instead)",
    "global npm installs (install to local node_modules instead)".]

   ## Ask me before proceeding
   [List operations that need human confirmation due to cost, visibility, or irreversibility.
    Example: "Any git push", "Any docker command that modifies running containers",
    "Any file write outside src/ and tests/".]
   ```

   Rules for writing the policy:
   - Every command pattern from Phase 1 hotspots must appear in Replan or Always block
   - Every command used frequently in package.json scripts should appear in Always allow
   - Never put the same pattern in multiple sections

2. WRITE .cursor/terminal-allowlist.json

   Build a minimal allowlist from the project's actual common commands:
   ```json
   {
     "version": "1",
     "patterns": [
       "git status",
       "git diff *",
       "git log *",
       "git add *",
       "git commit *",
       "ls *",
       "cat *",
       "echo *"
     ]
   }
   ```

   Include only patterns you found evidence for in the project's scripts.
   Do not add patterns "just in case" — every allowlisted pattern bypasses the classifier entirely.

============================================================
PHASE 3: VALIDATION
============================================================

Run these checks against the generated policy:

1. COMPLETENESS
   - Every MCP server from Phase 1 enumeration has at least one entry in the policy
   - Every destructive hotspot from Phase 1 appears in "Always block" or "Replan"
   - No pattern appears in both "Always allow" and any other section

2. CLASSIFIER TESTCASES
   Mentally simulate these scenarios and verify the policy produces the correct verdict:

   | Call | Expected verdict |
   |---|---|
   | git status | Allow (via allowlist) |
   | rm -rf node_modules | Block |
   | git push origin main | Ask |
   | curl https://external-api.com/data | Replan |
   | pnpm install lodash | Allow (if pnpm install in allowlist) |
   | Write file outside repo root | Block |
   | npm publish | Block or Ask |

   If any scenario produces the wrong verdict, revise the policy and re-check.

3. MCP SERVER COVERAGE
   For each MCP server configured, verify:
   - Broad-scope tools (filesystem, network, Docker) have explicit entries in "Always block" or "Ask"
   - Read-only tools have entries in "Always allow" or rely on the default sandbox stage
   - No MCP tool is implicitly permitted due to missing policy coverage

4. PROMPT INJECTION RESISTANCE
   Check that the policy blocks common prompt injection vectors:
   - Commands that exfiltrate file contents to external URLs
   - Commands that install and run arbitrary remote scripts
   - Commands that modify the policy file itself (agent should not be able to self-modify allowlist)

   If the policy does not cover these, add explicit "Always block" entries:
   ```
   curl * | bash
   wget * | sh
   write to .cursor/agent-policy.md or .cursor/terminal-allowlist.json
   ```

============================================================
PHASE 4: APPLY AND REPORT
============================================================

1. Write the final policy files:
   - .cursor/agent-policy.md
   - .cursor/terminal-allowlist.json

2. If cursor.agent.runMode is not "auto-review" in settings:
   - Remind the user to switch via Cursor Settings > Agents > Run Mode > Auto-review
   - Do not modify settings files directly unless the user explicitly requests it

3. Output a summary report:

```
CURSOR AGENT SAFETY AUDIT

Project: [name]
Run mode detected: [ask | auto-review | auto | unknown]
Recommended mode: auto-review

Tool surface enumerated:
- Shell commands: [N] patterns
- MCP servers: [N servers, list names]
- Fetch calls: [yes / no]

Hotspots found: [N]
[List each hotspot and which policy section it was assigned to]

Policy files written:
- .cursor/agent-policy.md  ([N] allow / [N] block / [N] replan / [N] ask entries)
- .cursor/terminal-allowlist.json  ([N] patterns)

Classifier testcases: [N/N passed]
MCP coverage: [complete / gaps found]
Prompt injection resistance: [pass / fail + reason]

ACTION REQUIRED:
[If run mode not yet set to auto-review, instruct user here.]
[Any manual steps the user must take — settings UI changes, MCP reconfiguration, etc.]
```

============================================================
STRICT RULES
============================================================

- Never add a pattern to "Always allow" without evidence it appears in the project's legitimate command usage.
- Never modify .env files or secrets under any circumstances.
- Never write to .cursor/settings.json unless explicitly asked — only write policy and allowlist files.
- If the project has no MCP servers and no destructive scripts, say so and produce a minimal policy — do not invent risks.
- Do not run any shell commands other than read operations (ls, cat, find) to gather audit data.

Attribution

tinh2tinh2
View sourceSee grades on GitHubMore from tinh2 →
SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments (0)

No comments yet. Be the first to comment!

SSkills DirectorySkills Directory

Ship a skill? Prove it's safe.

Free 120-pattern security scan, letter grade, and an embeddable README badge.

Submit a skill

Related Skills

Caveman

Terse caveman voice: answer first, fluff gone, every technical fact kept. Use for /caveman, "caveman mode", "talk like caveman", "be brief", "less tokens". Stays on until "stop caveman" or "normal mode".

1100021 votes

Hyperplan

Adversarial multi-agent planning skill. Self-orchestrates 5 hostile category members (unspecified-low, unspecified-high, deep, ultrabrain, artistry) via team-mode for ruthless cross-critique debate, distills only the defensible insights, then MANDATORILY hands the distilled insight bundle to the `plan` agent for executable plan formalization. Use when planning needs maximum rigor and surfacing of weak assumptions, blind spots, and over-engineering. Triggers: 'hyperplan', 'hpp', '/hyperplan', ...

698621 votes

Writing Skills

Create and manage Claude Code skills in HASH repository following Anthropic best practices. Use when creating new skills, modifying skill-rules.json, understanding trigger patterns, working with hooks, debugging skill activation, or implementing progressive disclosure. Covers skill structure, YAML frontmatter, trigger types (keywords, intent patterns), UserPromptSubmit hook, and the 500-line rule. Includes validation and debugging with SKILL_DEBUG. Examples include rust-error-stack, cargo-dep...

3931 votes

Mcp Code Execution

Routes multi-tool workflows through MCP servers for large datasets and pipelines. Use when Bash tool overhead is limiting throughput on data-heavy tasks.

3421 votes

catchup

Recovers the conversation and failed tool calls of a previous Codex, Amp, Claude Code, Antigravity, Cline, Copilot CLI, Cursor, DeepSeek Harness, Grok Build, Kimi, OpenCode, Pi Agent, or ZCode session. Use when the user says "catch up", "what did the last session do", "get me up to speed", "I switched agents", asks to recover/summarize a previous session before continuing, or asks to diagnose or report a catchup failure. Do NOT use for the current conversation, git history, or any non-agent log.

741 votes
View all in ai-agents →