Security fix prompts: apply, then recheck

Most security tools stop at telling you what is wrong. That leaves you with a list of problems you did not write and do not know how to fix. The fix prompt is the part that closes that gap. Findings come with a copy-paste instruction written for the exact tool that built your app, so the same AI builder that shipped the bug is the one that fixes it.

One prompt is one pass, not the whole job

A fix prompt carries your 25 heaviest findings. If your scan found more than that, the rest are still in the report, and they are still yours to fix. They just are not in this prompt.

This is on purpose. Handing an AI builder ninety instructions at once is how you get an app that no longer runs. Twenty-five is about as much as a builder will apply carefully in one sitting, and the heaviest ones go first, so the pass you run today is the one that removes the most risk.

The practical shape of it is rounds. Copy the prompt, apply it, push, rescan. The next report is smaller and its prompt covers the next twenty-five. A repo with ninety findings is three or four rounds, not one.

Your report says exactly how many the prompt covers and how many are left, and what your score becomes after this pass. If it says grade D, applying one prompt will not make it an A. It will move you closer, and the number on the next scan will show by how much.

Which AI builders is the fix prompt written for?

The fix prompt is tailored per platform. If you build in Lovable, you get an instruction that speaks Lovable. The same goes for Bolt, Cursor, v0, Replit, Windsurf, Base44, Cline, GitHub Copilot, Claude, Claude Code, ChatGPT, Codex CLI, DeepSeek, Gemini and Gemini CLI, with a universal wording for anything else. It is not a generic "you should add authentication here". It is worded for the tool sitting in front of you, so you can paste it straight in and the builder knows what to do.

Does the same finding always give the same fix?

The fix prompt is deterministic. That means the same finding always produces the same instruction. It does not change wording between runs. If two people have the same open-CORS problem, they get the same fix. You are getting a fix that follows from the finding, not one improvised on the spot, so it is consistent and you can trust it to say the same thing tomorrow.

What does a real one look like?

This is the first item from the prompt on the sample report, a scan of a real public repository. File paths are masked there, so they are masked here too:

## 1. [CRITICAL] command-injection-js
- File: *****/*****/*****.js (lines 32, 33, 34)
- Problem: An attacker who controls req.body.preTax, req.body.afterTax, or
  req.body.roth can inject arbitrary JavaScript code that will execute on the
  server with full application privileges.
- Fix: Replace eval() with parseInt() or parseFloat() (already shown in the
  commented-out fix on lines 38-40). Uncomment lines 38-40 and remove lines
  32-34 to apply the fix that is already documented in the file itself.

That is the shape every item takes: where, what an attacker could do, and the change to make. Leaked keys get an extra block at the top of the prompt with the rotation steps only you can do, because no AI tool can revoke a key for you.

Delivered in small steps

A fix prompt is broken into small baby-steps. The AI builder is told to apply one change at a time instead of rewriting your app in one go. This matters more than it sounds.

When you hand an AI builder a big vague instruction, it tends to touch far more than it should, and you end up with new bugs where you started with one. A step-by-step prompt keeps the tool on a short leash. One step changes one thing. You can see what each step did, and if something looks off you have not blown up the whole app to find out.

How you actually use it

The loop is short:

1. Open a finding in your report and copy its fix prompt.
2. Paste it into the AI builder that made your app.
3. Let the AI builder apply the first step. Look at what changed.
4. Move through the steps until the fix is in.
5. Push the change and scan the repo again.

That last step is the check. You are not trusting that the fix worked, you are looking. A finding that no longer appears in the new scan was not detected this time, which is strong evidence the fix took. It is not proof on its own: if the scan read fewer files or a rule changed, a finding can also drop out for that reason, so check that the new scan covered the same code. How a scan works covers the scan-and-rescan loop, and reading your report explains which findings to fix first.

Secrets: pointed at, never printed

Some findings are leaked secrets, a live key or a token left in the code. The fix prompt for a secret points the AI builder at where the leak is so it can be removed and rotated, but it never prints the secret in full. A report should not become a second copy of the thing that leaked. You get enough to find it and pull it out, and nothing an onlooker could steal.

Why this is the part that matters

For a founder who did not hand-write the code, a list of problems is only half an answer. The fix prompt is the other half. It turns "your app has an open database" into a step you can paste and apply in a minute, without learning what row-level security is first. That is the difference between knowing you have a problem and doing something about it. Security for AI-built apps goes deeper on why apps built this way need it.

It also keeps you in one place. You built the app in a tool you already know, and the fix goes right back into that same tool. You are not opening a code editor you have never used, or pasting error messages into a search box, or asking a stranger on a forum what a config file should say. The problem and the fix live in the same window. That is what makes it usable for someone who builds with AI first and thinks about security second.

Try it

The fix prompt comes with every scan, including the free one. A free scan shows you every finding it hits, your real score and grade, the prompt to repair them, and the same AI false-positive review a paid scan gets. What paid plans buy is more scans a month.

Scan a repo free, one a month, no card: start a scan. Signing in asks only for your email; a private repo needs a separate read-only connection.