How to Run a Security Review With Cursor (Agent-Driven)

Treat the agent as a fast, fallible delegate. The practitioner who built this workflow works from four tenets:

• Give it real context. Be clear about the work and what good looks like. You no longer need hours of prompt engineering.
• Assume it can be wrong, and build the workflow around any single fact being false.
• Ask for proof when you doubt a claim.
• Ask it anything. An agent can ramp you into an unfamiliar system fast.

The payoff is depth. Agents don't tire, so you can run a deep review on every change instead of a sampled few, and threat-modeling every PR goes from untenable to tenable. The practitioner estimates they became roughly 5x more effective on older models and 7.5 to 10x more effective on the models current at the workshop. Those numbers are self-reported, so read them as one person's estimate.

Ask the agent the questions a security reviewer asks on day one. It returns a digest that would take a long time to assemble by hand, and you can keep asking follow-ups until you understand the system.

1. 1Give the agent the repo pointer. A GitHub URL is enough.
2. 2Ask how old the repo is, and for the top 10 contributors with their contribution counts and tenure.
3. 3Ask for the project's goals, security policy, CI setup and development process.
4. 4Ask for a top-level architecture summary, then for an architecture diagram.
5. 5Read the disclosure policy: what is in scope, what is out of scope, and whether there is a bug bounty.

For most review work, the practitioner's answer is yes. A static rule can't trace context through a codebase the way an agent can, so writing one that follows the full data flow is very hard. In a vulnerability scan, the agent picks the right linter-style checks as it goes. The practitioner's hybrid feeds linter and scanner output to the agent and has it triage.

Agents bring one new failure mode: they make things up. That leaves two problems to manage. A false negative is a vulnerability the agent misses, and a false positive is a non-issue it flags with confidence. They need different countermeasures, because one comes from a vague prompt and the other from the model's drive to be helpful.

Start one agent and have it spawn sub-agents grouped by vulnerability class: infrastructure, AppSec, prompt injection, XSS, and dependencies (SCASoftware Composition Analysis. Scanning third-party dependencies for known vulnerabilities and license problems. Press Enter for the full definition.). Each sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. Press Enter for the full definition. produces a table of findings. For every finding, it then has to show the full attack chain with code snippets and write a simulated proof of concept.

Sub-agents help here for two reasons: each one runs the validation loop on its own findings, and each vulnerability class keeps its own isolated context. Run this way, sub-agents routinely discover that a chunk of their own findings were wrong.

Run a validation loop on anything that looks alarming. When the agent reports a finding, say a P0, copy it back and tell the agent you don't believe it. A prompt like this works: "Explain this in depth including the attack chain and relevant code snippets, tell me in detail how it would be exploited, and prove that the exploit works."

The agent re-investigates and often concludes that the finding isn't a vulnerability at all, for example because it is an intentional feature that users invoke themselves. Keep pushing each finding down to the docs and the code until you and the model reach ground truth.

Hallucination is normal, and it isn't a reason to stop. In one session the agent claimed a doc line was cut off mid-sentence. A quick "check GitHub, here's the actual text" produced "You're right, I was wrong." Assume the model can and will fabricate, and make it show you the docs and the code. You reach ground truth faster that way than by reviewing alone.

Match the mode to the shape of the task. Use Ask when you want a question answered and don't want the agent touching code, and Agent for quick changes. Use Plan for anything net-new or non-trivial. In Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. the agent gathers context aggressively before it writes code, so it finds the injection points ahead of time and stays on track during execution.

Keep Debug modeA mode that diagnoses a failure: it reproduces the issue, adds instrumentation and watches the logs, rather than reviewing a pull request. Press Enter for the full definition. in the rotation too. The practitioner's advice is to try all four.

For models, pick a daily driver instead of switching all the time. You build an intuition for how one model approaches problems and where it gets stuck. At the workshop, the practitioner's daily driver was an Opus 4.x model. Some GPT-5.x models were very strong on hard problems but slower, so those were the pick when depth mattered more than speed.

When you're undecided, let Auto pick a model for each request. These picks are one practitioner's observations, not Cursor's ranking, so try the models yourself and form your own view.

Use Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. whenever you ship infrastructure, so you see the agent's thinking before it acts. In the worked example, the practitioner deployed a third-party AI tool for a coworker. The safe but usable answer was to keep the tool off the public internet and reach it over a Tailscale connector, which the tool's own docs recommended. It stayed locked down and still reachable from a phone.

In Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition., the agent wrote Terraform into an infra/ directory with good defaults from the docs. The plan kept the tool closed to the internet and added reasonable plugins, so it wasn't trivially prompt-injected.

Read the generated plan carefully, because that is the moment to give feedback. Ask the adversarial question inside the plan: "What if somebody sends my boss something that says to ignore previous instructions and fire me?" Then have a security sub-agentA child agent a main agent spawns to work in parallel with its own context window, handing results back so the parent's context stays clean. Press Enter for the full definition. look for risks in the implementation before you open a PR, so you learn about real issues before the PR exists.

Start from the root cause: current models don't separate control from data. Instructions and untrusted content arrive on the same channel, and the model can't tell how far to trust whoever is feeding it information. Security has seen this mistake before, and AI repeats it. That one fact puts prompt injection at the center of every agent system's threat model.

Mitigate with limits on exposure and capability. Keep the tool off the public internet, behind a private network like Tailscale, and add guardrails and plugins so it isn't trivially injected. Then run the adversarial scenario on purpose: "what if an email tells the agent to ignore its instructions and take a harmful action?" Keep changing the design until it has an answer.

Never hand the agent your credentials, even if you are a GitHub and AWS admin. The practitioner uses a helper script instead: you type something like creds prod, and the script sets environment variables in the shell the agent drives. The agent can then run elevated AWS commands without the credentials entering its context, because it sees the terminal's output, not the shell's environment. That holds only while no command prints those variables.

Approve every state-mutating or network command, and let reads run free. Reading files is low risk. Mutations and network access ask for approval every time, because your user can reach more systems than you would trust the agent with. The agent writes a complex aws ... | jq command faster than a CLI expert could, so a second spent reading it costs little. You approved the command, so the outcome is yours.

The practitioner doesn't gate writes outside the workspace, because they work in git workspaces and reset anything the agent changes. Git can only restore files inside the repository, so check what else on your machine the agent could write to before you copy that choice.

Layer the controls across the lifecycle. Cursor hooks and rules work while the agent acts: hooks run validation in flight, and rules pin down facts about your codebase that the model keeps getting wrong. BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. runs at PR time as the last gate before merge. In between, you drive the agent by hand and tell it now and then to find its own bugs.

A rule earns its place when the model repeats a mistake. In one case the model kept assuming port 3000, so a rule stated that the service runs on port 40001.

Merging stays human.

The agent finds, proves and proposes, and you read every line you would ship and own the outcome. Don't accept "the model thinks it's a vulnerability, therefore it is", or the reverse.

For penetration testing, the workflow already finds bugs and writes proofs of concept, so running a PoC as a live exploit is a small step, and the practitioner sees teams chaining the two. Validation against the source of truth, with full visibility of code and config, is often enough without a live exploit. Never vouch for offensive work you haven't done yourself.

The approach has limits. The effectiveness multipliers are self-reported, not measured. Context-window management used to dominate the workflow, but modern compaction is good enough that a session of roughly 9 hours ran without a single reset. When an agent goes off the rails, recovery is still manual: have it summarize, copy that out, start a fresh agent and paste the summary in.

At the workshop, sandbox and PR security features were teased but not yet announced. Cursor has since documented a sandbox that shell commands can run in, depending on your Run Mode, and Security Agents, which include a reviewer that checks pull requests before they merge. Enterprise-wide controls, such as MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. governance and org-level policy, are a separate topic from this single-reviewer workflow.