Cursor AI Guardrails: Stop Unsafe Commands Before They Run

Correction note (2026-10-13). An earlier version of this article showed an ssg status sample that listed an audit file named ~/.sigmashake/audit.sqlite and lines that ssg status does not print. The local audit log is the audit_log table in ~/.sigmashake/rules.db. The per-call timings and latency figures that appeared in this article had no benchmark behind them and were removed. Sample output in this article is illustrative, not a recorded run. The only published measurement is p50 0.39 ms and p99 1.91 ms (sigmashake-bench daemon-socket run, 2026-06-10, ssg 0.29.156, n=500). Sub-2 ms evaluation is a design target. The local audit log records decisions on a best-effort basis: entries can be dropped if the daemon queue is full, and old rows are deleted at the row caps. It is local, not append-only, and not immutable. The init adapter ids are claude-code and copilot, not claude or vscode. The pricing section was corrected: SSG is free to download and install, $5/month unlocks the SSG product and the Desktop agent environment, and there is no free tier or trial of the value.

Cursor runs shell commands as you

Cursor's Composer and Agent modes execute terminal commands, edit files, and call external tools with your credentials and your filesystem access. When the agent is working well, this is powerful. When it miscalculates a path, misreads an environment variable, or follows an instruction that turned out to be ambiguous, the result is a real command that runs on your real machine.

The built-in approval prompt helps for single commands. For a multi-step agent session, approving every operation is not workable: you either approve everything quickly without reading it, or you become the bottleneck that eliminates the agent's speed advantage.

SSG gives you a third option: rules that run deterministically on every tool call, locally, before execution. Routine operations pass silently. Dangerous ones are blocked or routed to an approval dashboard where you review them once and move on.

Connecting SSG to Cursor

SSG integrates with Cursor through the Model Context Protocol (MCP). Cursor supports MCP servers natively; registering SSG takes one command:

# Install SSG
# macOS / Linux — free installer
curl -fsSL https://install.sigmashake.com | sh
# Windows (PowerShell): iwr -useb https://install.sigmashake.com/install.ps1 | iex

# Initialize for Cursor (writes the MCP server entry to .cursor/mcp.json)
ssg init --client=cursor

# Start the daemon
ssg daemon &

After initialization, Cursor routes all tool calls through the SSG MCP server before executing them. No manual JSON editing is required; ssg init writes the server entry to your project's .cursor/mcp.json.

Confirm the connection:

ssg status

ssg status prints the protection state, the account, and the daemon check. The local audit log is the audit_log table in ~/.sigmashake/rules.db. Read it with ssg audit search --since 24h.

The ruleset that covers the common risks

Add to .sigmashake/rules/cursor-safety.rules. These rules apply to Cursor, and because the rules are agent-agnostic, they also apply to any other governed agent on the same project:

rule no-rf-outside-project {
  enabled true
  priority 100
  severity error
  DENY execution
  IF command REGEX "rm\\s+-[a-zA-Z]*r[a-zA-Z]*f"
  AND command NOT CONTAINS "./dist"
  AND command NOT CONTAINS "./build"
  AND command NOT CONTAINS "./node_modules"
  AND command NOT CONTAINS "./.next"
  AND command NOT CONTAINS "/tmp/"
  MESSAGE "Recursive force-delete outside known build directories is blocked. Use a specific path."
}

rule no-secret-read {
  enabled true
  priority 100
  severity error
  DENY read
  IF path GLOB "**/.env*"
  OR path GLOB "**/credentials*"
  OR path GLOB "**/*.pem"
  OR path GLOB "**/*.key"
  OR path GLOB "**/id_rsa"
  OR path GLOB "**/id_ed25519"
  MESSAGE "Secret file read blocked. Pass credentials via environment variables, not direct file reads."
}

rule no-credential-in-cmd {
  enabled true
  priority 100
  severity error
  DENY execution
  IF command REGEX "([sS][kK]_[lL][iI][vV][eE]_|[sS][kK]-[aA][nN][tT]-|[aA][kK][iI][aA]|[xX][oO][xX][bB]-|[gG][hH][pP]_)[A-Za-z0-9_\\-]{10,}"
  OR command REGEX "([aA][uU][tT][hH][oO][rR][iI][zZ][aA][tT][iI][oO][nN]|[bB][eE][aA][rR][eE][rR])\\s*[=:]\\s*[A-Za-z0-9_\\-]{16,}"
  MESSAGE "Credential string detected in command. Use a shell variable reference instead."
}

rule ask-deploy {
  enabled true
  priority 95
  severity error
  ASK execution
  IF command CONTAINS "deploy"
  OR command CONTAINS "kubectl apply"
  OR command CONTAINS "helm upgrade"
  MESSAGE "Deployment command paused for human review."
  PROMPT "Allow this deployment command to run?"
}

Pull a complete set from the Hub:

ssg hub pull rules-shell
ssg hub pull rules-secrets
ssg hub pull rules-deployments

One ruleset, every editor

The rules in .sigmashake/rules/ are not Cursor-specific. If you also use Claude Code on the same project, the same rules govern both editors simultaneously. Initialize each client once:

ssg init --client=cursor         # adds .cursor/mcp.json
ssg init --client=claude-code         # adds hook entry to .claude/settings.json
ssg init --client=copilot         # adds MCP entry to .vscode/mcp.json

All three now share the same rules, the same audit log, and the same approval dashboard. When a Cursor session and a Claude Code session are running simultaneously, both route their ASK decisions to ssg serve, and both are blocked by the same DENY rules.

This matters practically: if your team uses Cursor on one machine and Claude Code on another, and you have an established ruleset from Claude Code, applying it to Cursor is one command. No rewriting rules in a different format.

Cursor-specific patterns to guard

A few patterns come up specifically in Cursor Agent mode sessions.

Composer file writes to unexpected paths. Cursor Composer sometimes writes generated files to the current working directory when a relative path is ambiguous. Adding a guard on writes outside src/ and test/ routes unexpected writes to approval:

rule ask-write-outside-src {
  enabled true
  priority 80
  severity warning
  ASK write
  IF path NOT GLOB "./src/**"
  AND path NOT GLOB "./test/**"
  AND path NOT GLOB "./tests/**"
  AND path NOT GLOB "./docs/**"
  AND path NOT GLOB "./.sigmashake/**"
  AND path NOT ENDS_WITH ".md"
  AND path NOT ENDS_WITH ".json"
  MESSAGE "Write to an unexpected path. Confirm the agent is writing to the right location."
  PROMPT "Allow this write outside the usual source directories?"
}

Package installs without version pinning. Cursor agents often install packages to satisfy imports as they write code. Installing without a pinned version can pull in a different package version than you expected:

rule log-unpinned-install {
  enabled true
  priority 70
  severity info
  LOG execution
  IF command CONTAINS "npm install" AND command NOT REGEX "@[0-9]+\\.[0-9]+"
  OR command CONTAINS "pip install" AND command NOT CONTAINS "=="
  MESSAGE "Unpinned package install logged."
}

The LOG verdict records the install in the audit log without blocking it, so you can review what the agent installed at the end of the session.

What Cursor sees when a rule fires

When an SSG rule blocks a Cursor tool call, Cursor receives a tool error containing the rule's MESSAGE field. Cursor's agent mode reads this message and can course-correct.

For the secret file block:

Error: Secret file read blocked. Pass credentials via environment variables,
not direct file reads.

The agent typically switches to referencing process.env.VARIABLE_NAME in the code it writes, which is the correct pattern anyway.

An illustrative session with SSG and Cursor

Here is illustrative sample output for a typical Cursor Agent session building a Node.js service (not a recorded run):

# illustrative sample output
[ALLOW]  read_file     src/routes/users.ts
[ALLOW]  write_file    src/routes/users.ts
[ALLOW]  bash          npm test -- src/routes/users
[DENY]   read_file     .env.production
         rule: no-secret-read
[ALLOW]  write_file    src/config/database.ts
[ALLOW]  bash          npm test
[LOG]    bash          npm install express
         rule: log-unpinned-install
[ASK]    bash          kubectl apply -f k8s/staging.yaml (pending)
         rule: ask-deploy
         -- approved in the dashboard

Eight tool calls. One block. One log entry. One human approval. The agent worked freely through everything routine and paused exactly once for a deployment that warranted review.

Pricing

SSG is free to download and install. A $5/month subscription unlocks the SSG product and the Desktop agent environment. There is no free tier and no trial of the value.

The playground at playground.sigmashake.com lets you test rule evaluation against any tool call before you commit a rules file to your project.

Get started

# macOS / Linux — free installer
curl -fsSL https://install.sigmashake.com | sh

# Windows (PowerShell)
# iwr -useb https://install.sigmashake.com/install.ps1 | iex

# Initialize for Cursor (and Claude Code if you also use it)
ssg init --client=cursor
ssg init --client=claude-code

# Pull community rulesets
ssg hub pull rules-shell
ssg hub pull rules-secrets
ssg hub pull rules-deployments

# Start the daemon
ssg daemon &

# Open the approval dashboard
ssg serve

Links: Download · Docs · Playground · Hub