Writing Secure Code with Cursor: Scan, Fix, and Verify with StackHawk

Cursor lets you steer its agent with rules. The .mdc files in your project turn “follow our conventions” into behavior the agent pulls in as it works, and security testing fits that model cleanly. That’s how StackHawk plugs into Cursor: as a set of rules that teach the agent to scan, fix, and verify the code it writes.

This guide is about putting those rules to work against your live, running app. By the end, Cursor’s agent will scan your local application, fix the vulnerabilities it finds, and prove the fixes with a clean rescan, all from inside the editor.

What Are StackHawk Agent Skills for Cursor?

An agent skill is a set of instructions that teaches a coding agent a job. From these, the agent learns to run security scans against your app, read the findings, fix the vulnerable code, and verify the fixes. StackHawk’s skills follow a five-step loop: Configure, Scan, Parse, Fix, Verify.

Two skills ride along in a single install. HawkScan owns the scanning half, from configuring and running scans through fixing findings and confirming them. StackHawk API answers questions by pulling posture summaries, findings reports, and scan history from the platform. On Cursor, they arrive as .mdc rules in your global config, so if you’ve written Cursor rules before, the format will feel familiar.

The rules themselves are structured markdown: installing them adds zero runtime dependencies, and nothing runs in the background. That’s the Agentic StackHawk idea, where the agent that wrote the code is also the one that tests it under real requests, so “done” means “done and secure”.

Prerequisites

Here are a few prerequisites to check off before the steps below:

• Cursor installed, with any project open
• A StackHawk account; the agent skills require the Secure, Scale, or Wingman plan
• Java 17 or newer (a full JDK) if you’re on Linux; the macOS and Windows installers ship with Java included
• Make sure your app is running locally with its source code checked out, listening on a port from 1024 to 65535

Set Up Cursor Security Scanning with StackHawk

Step 1: Get a StackHawk API Key

To get an API key, log in to the StackHawk console in the browser and click Settings in the left-side menu, then click API Keys in the menu that appears. On the API Keys screen, click the Create API Key button in the top right corner.

Give your API key a descriptive name like “Cursor Agent” and click Continue.

The API key has now been created. Leave this screen open or temporarily copy the key somewhere secure so it’s ready for the next step. If you exit before copying it, you’ll need to delete the key and create a new one.

Step 2: Install the hawk and hawkop CLIs

On macOS or Linux, Homebrew installs both, and the two init commands sign them in:

brew trust stackhawk/cli && brew tap stackhawk/cli && brew install hawk hawkop
hawk init
hawkop init

The brew trust step matters on current Homebrew releases, which refuse to install from a third-party tap until you trust it; without it the install stops with Refusing to load formula ... from untrusted tap.

hawk init prompts for the API key from Step 1, validates it, and stores it at $HOME/.hawk/hawk.properties.

hawkop init reads that stored key on its own, so the only thing it asks for is your default organization. On Windows, the MSI installers on StackHawk’s downloads page cover both CLIs (the hawk MSI includes Java), and the init commands run the same way in PowerShell.

Why two CLIs? hawk runs scans, while hawkop operates on the results, and the rules lean on both.

Step 3: Install the StackHawk rules in Cursor

Cursor installs differently from the plugin-based agents. Run the script from the Cursor skill docs to drop the StackHawk rules into your global Cursor config:

# Clone the agent-skills repo
git clone https://github.com/stackhawk/agent-skills.git /tmp/stackhawk-skills

# Install Cursor rules to your global config
bash /tmp/stackhawk-skills/scripts/install.sh --platform cursor --target ~

# Clean up
rm -rf /tmp/stackhawk-skills

On Windows, use the PowerShell equivalent:

git clone https://github.com/stackhawk/agent-skills.git $env:TEMP\stackhawk-skills
& "$env:TEMP\stackhawk-skills\scripts\install.ps1" -Platform cursor
Remove-Item -Recurse -Force "$env:TEMP\stackhawk-skills"

Global rules in ~/.cursor/rules/ load automatically in every project you open, so you install once and scan everywhere.

Step 4: Verify the rules are active

Open any project in Cursor and ask the AI:

What StackHawk rules do you have?

The response should describe the HawkScan scanning skill and the API reporting skill. If it does, you’re wired up.

Step 5: Ask Cursor to scan your app

With your app up, give Cursor’s agent the prompt from the docs, changing the port if yours differs:

Scan my app running on localhost:8080 for security vulnerabilities

From here, Cursor takes over. It checks that the app is running and prompts you to start it if it isn’t, then generates a stackhawk.yml, validates it, and runs the scan. The generated config needs just three fields: app.applicationId, app.env, and app.host.

Know where that applicationId comes from before you see it. It’s not derived from your code; it points to a record for your app on the StackHawk platform, and app creation is part of the multi-step workflow the rules carry out.

When the scan finishes, the results print in Cursor’s terminal and also land on the StackHawk platform: a summary of counts by severity, followed by each vulnerability with its risk, confidence, and affected paths and methods.

If parts of your app sit behind a login, describe the auth pattern in plain language, and the agent folds it into the scan config; the authenticated scanning guide covers what HawkScan supports.

Step 6: Let Cursor fix the findings and verify

Findings in hand, send the follow-up:

Fix all of these security findings

The agent reads each vulnerability in its code context and fixes it the way you would: parameterized queries where SQL was concatenated, output encoding where XSS surfaced, and security headers where protections were missing. Then it rescans, and the job isn’t finished until the issues stop reproducing.

That verification rescan is the difference between code that looks fixed and a running app that no longer has the vulnerability.

Reviewing and Triaging Findings in the StackHawk Platform

One of the best parts of using StackHawk skills with a coding agent is that the skill can automatically review and triage findings. The agent decides whether something should be fixed and adds a note, all without intervention.

If you’d rather review scans and triage manually, that’s available in the StackHawk console.

In the console, unprocessed findings are marked New, and the Finding Details page gives each one three triage paths: Assigned, Risk Accepted, or False Positive. Whichever you pick, the platform asks for a comment, which is how a triage decision survives team turnover.

When a finding looks questionable, the Validate action generates a ready-to-run curl command that reproduces the attack with the correct verb, headers, and data. Fire it at your local app and trace exactly what the scanner saw.

You can skip the browser, too. Ask Cursor about your security posture or recent findings, and the StackHawk API skill pulls the answer from the platform. StackHawk’s docs list the hawkop CLI as a prerequisite for the API skill, which you installed in Step 2.

Wrap-Up

Agents need help shipping secure code. Install the rules once, and Cursor security scanning becomes part of how features are finished, rather than a separate review you schedule later. Start a free StackHawk trial and put the loop to work on your own app. The Agentic StackHawk Setup Guide covers the same end-to-end flow whenever you want a docs-native reference.