Nine Prompts That Change What Your AI Builder Writes

A security prompt changes what your AI builder writes next. Nothing about that proves what the running app now allows. Nine prompts below, one per trust boundary, each published with the observation, or the pair of observations, that settles whether the change landed.

Search for a vibe coding security prompt and what comes back is instructions to paste into Lovable, Base44, Bolt, Replit, v0, Cursor, or Claude Code. Paste one, and the tool edits files and reports back that it is done. What those pages leave out is the thing to look at afterwards: the one observation in your own running app that separates a change that held from a change the tool believes it made.

That pairing is the whole asset here. Nine prompts, one per boundary of the risk map an AI-built app actually has, and next to each one the check that settles it. Some checks are a browser tab and a logged-out session. A few need the terminal you already use to run your app. None of them asks the tool that made the change whether the change was good. Run every check against a preview or staging deployment with a test account and disposable data, keep the payment provider in test mode, and know how you roll the deploy back before you start, because several of the checks below deliberately make the app misbehave.

Sources for this page were read on 17 August 2026. Where a vendor page carries no date of its own, this page says so.

What a security prompt changes, and what it cannot prove

One public test isolates the variable cleanly, and it is a small one. Writing on Deriv’s engineering blog on 24 March 2026, Tan Weng Onn, Senior Security Researcher at Deriv, built the same to-do application twice with Claude Sonnet 4.5 in Claude Code, same feature list, same prompts, file upload and download included. The only difference between the two runs was a security-focused system prompt. Reviewing the results, he found three issues in the version built without it: no real session-based authentication, missing authorization checks, and a stored cross-site scripting hole through an uploaded filename. The version built with the security prompt came back with none.

He also fenced the finding himself, in the same paragraph: “This was a small controlled test, not a universal verdict on AI coding tools.” He goes on to note that it was a simple greenfield app, that the unprompted version got SQL parameterization and password hashing right without being asked, and that the prompted version still needed code review.

Take that at exactly the weight it carries. It says a standing instruction changes what a model generates, measurably, on a small app one researcher built and reviewed. It says nothing about whether the endpoint in your app that charges cards checks the session, because nobody has looked at your app.

That gap is where founders lose money and time. A security prompt for an AI builder operates on the code the model can see and the intent it infers. The question you actually have is whether a second person, signed in to their own account, can pull up your first customer’s order. Those are answered by different things: one by generation, the other by an observation somebody makes in the deployed app. A tool can be excellent at the first and still leave the second entirely unexamined, and nothing in its reply will flag the difference.

So every prompt below ships with the observation that settles it, and the observation is yours to make. Asking the tool to confirm its own work adds a sentence to the reply and nothing to the evidence.

Why a vibe coding security prompt needs its own check

Four sources supply most of what people find when they search for a vibe coding security prompt or for secure vibe coding prompts. Forum threads rank alongside them: on 17 August 2026 the same Reddit thread sat fourth on both results pages, above most of the published guides. Those are conversations rather than documents, so this page names them and stops there. The four below all ship real, usable instructions, and all four stop at the same place. Read the same day:

Three of those are linked above and one is not. Replit’s checklist is a platform documenting its own Agent, and benavlabs/vibe-check is an MIT-licensed repository that sells nothing. The Cloud Security Alliance guide is an industry reference. Sherlock Forensics sells reviews of vibe coded apps directly, so this site credits it by name and stops there.

All four sources share one shape, and the reason is practical. Vibe coding prompts for security are easy to publish and easy to read. A verification step has to name a specific thing in an app the author has never seen, which is harder to write and much harder to write generically. benavlabs/vibe-check gets closest, and then hands the verifying back to the model that wrote the fix.

There is a second family of prompts nearby, aimed at developers rather than founders. Search for an ai code security review prompt and the results turn technical fast: GitHub repositories, security tooling vendors, engineers writing up their own experiments. Those are written for somebody who will read the diff. This page assumes you will not.

The read-only version of this job already exists and is worth running first if you have not: the free ten-item self-check prompt asks a model to answer PASS, FAIL or CANNOT TELL against your code and show its working, without changing a line. That prompt finds; the nine below change. Keep the two jobs apart, because a prompt that finds and fixes in one turn leaves you no before state to compare against.

A prompt is finished when a tool reports back. A change is finished when something you observed in the running app came out differently than it did before.

The nine boundaries, and the order to run them

Nine boundaries cover the ways an AI-built app gets into trouble, and the vibe coding risk map these prompts are organised by runs to nine because it counts the direct controls and, alongside them, the operational conditions surrounding a failure. This page adds one prompt to each row. Running them one at a time is the point of a vibe code security check prompt set rather than a single wall of instructions, because a tool given nine jobs at once will do the three it understands best and summarize the rest.

The order in that table is the order of the risk map, so run the boundary your app actually exposes first rather than working down the list. An app with accounts starts at authorization, because one customer reaching another customer’s row is the failure with no recovery story. An app with a public AI feature and no accounts starts at authentication and the spend caps. For an internal tool with five known users, no payment path and no route reachable without signing in, most of the first half can wait; start at reliability and backups, and come back to authorization the day a sixth person or an outside integration gets access.

One finding is worth carrying into that choice. In a fixed cohort of AI-built apps audited across June and July 2026 and scored pillar by pillar and grouped here into these same nine boundaries, reliability ranked worst and secrets ranked best, the reverse of the order most founders work in. The method and the scoring live in the 26-app study behind the pillar ranking, and the short version is that the boundary nobody thinks to prompt for is the one that scored lowest.

Nine prompts, one per boundary

Each prompt below is written to be pasted whole, pointed at one part of your app rather than the entire repository. Every technical claim inside them was checked against the vendor or standards documentation named alongside it. The last line of each one asks the tool to declare what it could not verify, which is where the reply starts being useful.

1. Authorization: make the failing test come first

A logged-in customer reaching a record they do not own is the failure that survives every demo, because a demo has one account in it. Asking a tool to add ownership checks gets you checks. Asking it to write the proof first gets you something you can watch fail and then watch pass.

Write a failing test first: sign in as a second account and try to read, then
edit, a record owned by the first account. Do not touch any endpoint until
that test runs and fails for the right reason. Then fix the endpoint until the
test passes, changing nothing else. Finish by listing every route you could
not cover with a test and why.

Point it at one resource at a time, starting with whichever table holds customer data.

What proves it landed: the test output, twice. Failing on the first run, passing on the last, with nothing else in the diff. A tool that hands back only a passing test has usually written one that never exercised the boundary, and the way to catch that is to revert the fix on a branch and confirm the test goes red again.

If your app runs on Supabase, the same rule also has a database-side form, written as a row level security policy, where using decides which rows an operation may touch and with check constrains the new row data. That syntax belongs with the Supabase pages rather than this one, so the prompt above stays deliberately builder-agnostic.

2. Authentication: reject before the work, not after

A route can check the session and still do the expensive part first. That shows up as a bill rather than a breach, and it is invisible in every demo.

For every route that reads or writes data, sends mail, or spends money, first
say who is meant to call it: a signed-in user, a signed provider webhook, a
server credential, or the public. For every route meant for a signed-in user,
validate a current server-side session before any other work happens, and
return the refusal before any side effect, not after it. For public routes and
webhooks, name the check that stands in for the session, such as a verified
signature or a rate limit. Then list every route that is still reachable with
no credential at all, and mark the ones you could not trace.

What proves it landed: log out completely, including any stored token, then call your most expensive route directly with the browser address bar or whatever request tool you already have. The refusal should arrive with nothing behind it: no row written, no mail sent, no model call in your provider dashboard. Check the dashboard, not just the response code. The interesting failures are the ones that return 401 after doing the work.

3. Secrets: move the call, then rotate the key

A variable named for the browser ends up in the browser, and it stays there. Next.js documents that a NEXT_PUBLIC_ value is inlined into the JavaScript bundle at build time and that the built app stops responding to later changes in it, so whatever shipped is what leaked until you rotate. Vite rules the same class of variable out for API keys, because a VITE_ value lands in client source code after bundling.

Find every secret this app references from client code, including anything
read through a NEXT_PUBLIC_ or VITE_ variable. Move each of those calls to a
server route that holds the key, and leave the client holding none. Then list
which keys must be rotated because the old value already shipped inside a
build, and which references you could not trace.

What proves it landed: search the built bundle, not the source folder. Open your live site, open DevTools, go to Sources and search across all files for the key’s first eight characters. A clean source tree with a dirty bundle is the normal outcome of a half-finished move. Then rotate: the check on the rotation is that the old key stops working when you try it, not that a new one appears in your dashboard.

4. Input and abuse: parameterize, then validate on the server

Client-side validation is a user experience feature. Anything that decides what the database accepts has to live where the browser cannot reach it.

Replace every query built by string concatenation with a parameterized query.
Add server-side validation of type, length, range and allowed values for every
field the browser sends, and keep it enforced when the request arrives without
going through the form. List the inputs you changed and any field whose
server-side entry point you could not find.

What proves it landed: send the request without the form. Copy the request from your browser’s network tab, change one field to something the form would never allow, a negative quantity or a role name, and send it again from a test account, keeping the same method and headers. The server should refuse it. If it accepts it, the validation the tool added is sitting in the browser where it protects nobody.

5. AI and model risk: two caps and a logged 429

An unmetered model endpoint is a bill somebody else can run up. OWASP calls this risk Unbounded Consumption, and the name is the durable part: its LLM Top 10 landing page still served the 2025 edition on 17 August 2026, listing it as LLM10:2025, while a 2026 edition went out on 3 August 2026 as a downloadable document that renumbers the list. Cite the name, not the number.

Before every model call, enforce two limits on the server: a per-user cap and
a global cap for the whole app. Return 429 when either one is hit, and log
which cap fired and for which user. Do not use anything the browser sends to
identify the caller. List every model call you changed and every one you could
not find.

What proves it landed: two observations, and both are quick. Logged out, the endpoint refuses before the model runs, which you confirm in your AI provider’s usage dashboard showing no request. Then test the two caps separately: signed in as a test account with a low per-user quota, click the feature until it stops and read the log line naming the per-user cap; then, on the staging copy with the global cap set low, repeat from a second account until the log names the global cap. A cap with no log line behind it is a cap you cannot debug at 2am.

6. Dependencies: trace reachability before upgrading anything

An advisory list is a starting point. What settles whether any single entry matters to you is a path: some line you actually ship that ends up calling the broken code, in the state the advisory needs.

For each advisory in the production dependency tree, name the file and line in
this codebase that reaches the vulnerable function under the conditions the
advisory describes, or mark it unreachable and say why. Upgrade only the
reachable ones, running the tests after each upgrade. Then confirm every
package in the lockfile exists on its registry under the publisher it claims,
and list anything you could not confirm.

Run it against the production tree first. Build-only packages do not ship to your users, but they run on your machine and in your pipeline at install time, so give them a separate pass rather than treating them as safe.

What proves it landed: the trace itself, one line per advisory naming a file or naming a reason it cannot be reached, plus a passing test run after each upgrade. Read two or three of the “unreachable” verdicts and check that the file it names actually exists and that the line it names really calls the package. The publisher check catches a separate problem: a package the model invented and somebody else then registered under that name.

7. Deployment: re-enable one check at a time

Every disabled check was disabled for a reason, usually because it was failing and something had to ship. The reasons are rarely written down.

List every check that runs between a push and production, and every check that
is currently disabled, skipped, or set to continue on failure. Re-enable them
one at a time, run the pipeline after each, and report exactly what breaks.
Change no application code to make a check pass. Tell me which checks you
could not find a configuration for.

What proves it landed: push a knowingly broken change to a branch, something as small as a type error, and watch the pipeline refuse it. A pipeline that goes green on a change you know is broken is decoration. This is the one prompt where the tool’s instinct works against you: told that a check fails, most tools will fix the code rather than report the failure, which is why the fourth line is there.

8. Reliability: make failure report failure

This is the boundary nobody prompts for, and the one the audit cohort scored worst. A write that fails and returns 200 costs you a customer months later, when they ask where their data went.

Find every place this app swallows an error or returns success after a failed
write. Make each one fail honestly: return an error the caller can see, and
record the failure somewhere outside the process that failed. Do not add a
retry that hides the original error. List what you changed and any failure
path you could not trace.

What proves it landed: force one failure and see whether it reaches you. On the staging copy, point the app at a wrong database password, or a storage bucket that does not exist, then use the feature and put the right value back afterwards. You want an error in the interface and a record of it somewhere you check without being told to look. If the app carried on cheerfully, the swallow is still there and the prompt reported on the ones it happened to find.

9. Data integrity: confirmation, a filter, and a restore you have run

Destructive operations are written by tools that have no idea which of your tables you cannot rebuild.

List every operation that deletes or overwrites data, including cascading
deletes and bulk updates. For each one, require an explicit confirmation and a
bounded filter so it cannot run unbounded. Then state where backups live, how
old the newest one can be, and what they do not cover. Flag anything you could
not determine from the code.

What proves it landed: a restore you have actually run in a test environment, timed, which proves the backup half. The confirmation and the bounded filter need their own check: on the staging copy, run one delete without the confirmation and one with a filter that would match every row, and confirm both are refused. A backup setting that reads enabled proves storage exists, and the tool’s summary of your backup policy proves that it read a config file. The other half of this boundary is the delete graph, because a foreign key with a cascade can destroy rows no application code ever mentions: the one query that shows every delete that can reach your data is worth running alongside this prompt rather than asking a model to describe your schema back to you.

Read the last line of every reply first. Each prompt ends by asking what the tool could not verify, and that list is where the useful information sits. An empty version of that list, across all nine boundaries, is a statement about the tool’s confidence, and it leaves your app exactly as unexamined as it was before.

What your builder already runs on its own

Some of this is already happening without you asking, and it is worth knowing exactly how far it goes before you pay for anything else.

Replit ships copy-paste prompts inside its own security checklist documentation, phrased for its Agent: Help me implement rate limiting for my application is one of eleven. They are reasonable prompts. The page carries no verification step beyond a pointer to an external header scanner, and none of the eleven is paired with anything you observe in your own app afterwards. Read on 17 August 2026 it carried no date either, so nothing on it tells you how long that list has stood.

Claude Code has a /security-review command, and Anthropic publishes the analysis behind it as an open-source GitHub Action under an MIT licence. The part worth reading is the exclusion list, because a vendor stating what its own security review deliberately skips is rarer than a vendor stating what it catches. It filters out denial of service, rate limiting concerns, memory and CPU exhaustion, generic input validation without proven impact, and open redirects. Two of the nine prompts above land partly inside that excluded set: prompt 5 is spend caps, which is rate limiting under another name, and prompt 4 is half excluded, its server-side validation falling under generic input validation while its SQL parameterization does not. Two more, deployment gates and reliability, are not vulnerability classes a diff reviewer looks for at all. None of that is a fault in the tool. The filter exists to cut false positives in a diff review, and the repository says so plainly. There is a separate page in this series on what Claude Code’s own security review does and does not cover.

Lovable runs two scans of its own. Its security page times the Basic scan at roughly 10 to 15 seconds, running automatically at publish, and documents it as checking database configuration, RLS rules, cloud project settings and known misconfiguration patterns. The Deep scan is on demand, around 3 minutes, and is documented as analysing the full codebase. Both are useful. Read on 17 August 2026, neither is documented as signing in as a second customer and trying the operation. That gap, and what the publish-time scan can and cannot catch, sits in the Lovable-specific version of these checks.

Base44, Bolt, v0 and Cursor each ship some version of this too, and the shape of the answer holds across all of them: the built-in review reads what was written, and the observation column of the table above stays yours.

Where these prompts stop

Four things stay out of reach of anything you can paste into a builder, and being clear about them is what keeps the nine prompts honest.

A prompt cannot be a second person. It cannot register an account, sign in, and try to open your first customer’s invoice, which is the exact operation that settles the authorization boundary. Prompt 1 gets you a test that stands in for that, which is closer than nothing and is still a test written by the party being tested.

A prompt reads source, and your users meet a build. Which middleware actually ran, which route the edge configuration in front of your app rewrote, which environment variable the deploy actually had: none of that is answerable from the files on disk. This is why the check column keeps sending you to the built bundle, the provider dashboard, and the deployed URL.

The money path only answers to a full pass through it: whether a refund revokes the thing that was bought, whether a webhook that arrives twice charges twice, whether a metered route holds against a caller ignoring your interface. Each of those needs a full transaction, start to finish, in the provider’s test mode with a test card.

The fourth is the quiet one, and it is why this page is shaped the way it is: the tool grading the work usually wrote the work. That matters most at repair time, so how to repair a boundary once a prompt has shown you where it fails is worth treating as its own job, with the repair and the proof kept in different hands.

Start with the boundary your app actually exposes

Nine prompts is not a morning’s work, and running them in order is the wrong instinct anyway. Pick the boundary where a failure would be worst for your specific app and start there. Multi-user app with customer data: prompt 1, and do not move on until the test has gone red and then green. Public AI feature: prompts 5 and 2, in that order, with your provider’s usage dashboard open. Anything holding data you cannot recreate: prompt 9, and book the restore drill this week rather than reading about it.

One thing no prompt in any of the published sets does: telling you which of your boundaries matters most. A tool does not know what your customers would forgive. That judgment stays with you, and it is the cheapest part of the whole exercise.

Common questions about builder security prompts

Does a security prompt actually make AI-generated code safer?

On the evidence available, yes, in generation. In a public controlled test, Tan Weng Onn built the same to-do app twice with Claude Sonnet 4.5, and review found three issues in the run without a security system prompt and none in the run with it.

He calls it a small controlled test rather than a universal verdict, and it was a simple greenfield app. What that does not tell you is anything about your app, which is why every prompt on this page carries an observation you make yourself.

Which of the nine should I run first?

Whichever boundary your app exposes hardest. Multi-user apps start with authorization, because one customer reading another customer’s row has no clean recovery. Apps with a public AI feature start with authentication and spend caps. Internal tools with a handful of known users and no payment path start with reliability and backups, which is also where the audit cohort scored worst.

Can I paste all nine at once?

You can, and the result is worse. A tool given nine jobs in one turn tends to do the two or three it recognizes well, produce a summary for the rest, and report the whole thing as complete.

One prompt per turn, each pointed at one route or one table, gives you a diff small enough to check and a single observation to make before moving on.

Does my builder’s own security scan already cover this?

Partly, and each one tells you where it stops if you read the documentation. Anthropic publishes the exclusion list for the analysis behind Claude Code’s /security-review: denial of service, rate limiting, memory and CPU exhaustion, generic input validation without proven impact, and open redirects are all filtered out by design.

Lovable documents its Basic scan as checking database configuration, RLS rules, cloud project settings and known misconfiguration patterns, and its Deep scan as analysing the full codebase; on a 17 August 2026 read, neither is documented as signing in as a second account. A scan and a change prompt answer different halves of the question.

What is a vibe coding security check, and is it the same as running these prompts?

A vibe coding security check is the read-only half: a defined list of things to confirm about your app, each with the test that confirms it, run without changing any code. These nine prompts are the write half, changing what the builder wrote and then proving the change held.

Run the check first, because it tells you which of the nine boundaries you actually need, and the twelve checks and the test each one names cover that read-only side in the order the risk arrives.

Will the tool that wrote the code tell me the truth about it?

It will tell you what it believes. A model reviewing its own output grades against the intent it had while writing, so the failure it missed the first time is the one it is least likely to catch the second.

This is the reason the popular repositories that pair an audit prompt with a fix loop still leave a gap: the same model implements the fix and then verifies it. The check column on this page exists to put one observation between the tool’s claim and your belief in it.

Do these work in Base44 and Bolt as well as Cursor and Claude Code?

Yes. Nothing in the nine prompts names a framework, a file layout, or a vendor feature, so they paste unchanged into Lovable, Base44, Bolt, Replit, v0, Cursor and Claude Code.

What changes across tools is how much of the change you can watch happen: an agent in a terminal will show you the diff and the test run, while a chat-first builder will summarize. The observation in each check is written for the deployed app precisely so it works the same either way.