The vibe coding security checklist: 29 checks in five gates, from prompt to production.
Every check below either stops a flaw that studies of AI-written code keep finding, or limits the damage when one gets through.
Work through it gate by gate. The first two gates shape what the AI is allowed to do; the middle one catches what it got wrong; the last two decide how bad a miss can be. Each check names the failure it prevents.
Updated · 10 sources
What should a vibe coding security checklist include?
A vibe coding security checklist should cover five gates: keep secrets and production credentials away from the AI; approve destructive commands and verify every new package; have a person review each change and run code, dependency and secret scanners; test access rules and lock down the deployment; and keep logs, backups and a tested rollback after launch.
Why each item on the vibe coding security checklist is there.
The checks come from the failures that tests of AI-written code and real incidents report again and again. Three findings explain most of the list.
A scanner that checks the wrong thing. In the 2025 row-level-security case, the app builder’s own security scan checked that an access policy existed, not that it blocked anyone. Gate 4 tests the rule by trying to break it.
Gate 1: keep secrets and production out of the agent’s reach.
The cheapest controls act before any code exists. They decide what the AI can see and what it can break.
- 1 · No production credentialsThe agent works with development keys and sample data only.
- 2 · Secrets outside the codeEnvironment variables or a secrets manager;
.envfiles never committed. - 3 · Least privilege for the agentName the folders, commands and services it may touch, and nothing else.
- 4 · Security in the requestAsk for parameterised queries, validated input and sign-in on every route.
- 5 · An established sign-in providerUse a proven identity service rather than generated login code.
- 6 · Version control from commit oneEvery change becomes a diff you can read, compare and revert.
Build the expense form. Rules:
- read secrets from environment
variables; never write a key
into the code
- parameterised queries for every
database call
- validate and encode all input
- sign-in required on every route
except /login
- generic errors to users;
details to server logs onlyA prompt is a request, and gates 3 and 4 check it. Stating rules lowers the miss rate. It does not remove it: in the SusVibes benchmark, adding vulnerability hints to the request did not make agents’ code secure.
Gate 2: approve destructive commands and verify every package.
Coding agents run commands and install packages on their own. OWASP calls the risk excessive agency: too much functionality, too many permissions, too much autonomy.
- 7 · Approve destructive commandsDeletes, migrations and force-pushes wait for a person — the control OWASP recommends for high-impact actions.
- 8 · Verify every new dependencyIt exists, it is maintained, and it is the package you meant. Invented names are registered by attackers (slopsquatting).
- 9 · Separate development and productionDifferent databases and keys, so an agent’s mistake cannot reach live data.
- 10 · Watch for disabled checksNo commented-out authentication, skipped tests or “validate later” notes left behind.
- 11 · Small commitsA bad change is easy to find and revert when each commit does one thing.
Why check 9 matters. In July 2025 a coding agent reportedly deleted a live production database during a declared code freeze (AI Incident Database #1152). Instructions in a prompt did not stop it; a separate production environment would have.
Gate 3: a person reads it, and scanners and tests check it.
This is the gate pure vibe coding skips. Simon Willison’s rule sets the bar: commit nothing you could not explain to someone else.
- 12 · Human reviewA person reads the diff and can explain what it does.
- 13 · Static analysis (SAST)On every change: injection, cross-site scripting, unsafe deserialisation.
- 14 · Dependency scanning (SCA)Known vulnerabilities and unknown packages, with automatic update alerts.
- 15 · Secret scanningThe code and its history, since a key removed later is still in the log.
- 16 · Unhappy-path testsBad input, no sign-in, and another user’s record ID.
- 17 · Output encodingEvery page that shows user input escapes it. In Veracode’s tests, AI-written code left cross-site scripting open 86% of the time.
- 18 · Clean logsNo raw user input or secrets written to logs. Veracode found log injection left open 88% of the time.
Gate 4: test the access rules and lock down the deployment.
The best-known vibe-coding exposure of 2025 was a configuration gap — database access rules — rather than a code bug. Test each boundary by trying to cross it.
- 19 · Access rules testedCall the database or API with only the public key, then as a second user. Both must be refused.
- 20 · No database calls from the browserThe front end goes through server-side routes that check who is asking.
- 21 · CORS limited to known originsNo wildcard, which lets any site call your API with a user’s session.
- 22 · HTTPS everywhereA valid certificate and TLS 1.2 or later.
- 23 · Errors that reveal nothingGeneric messages to users, details in logs, debug output stripped from the build.
- 24 · Rate limitsOn sign-in, sign-up and expensive endpoints, to blunt abuse and runaway costs.
Gate 5: logs, backups, rollback and a named owner.
A miss will get through eventually. These checks decide whether it is a bad afternoon or a breach notice.
- 25 · Activity logs and alertsWho did what, with alerts on patterns such as mass deletes.
- 26 · Backups, restored onceA backup you have never restored is a hope rather than a control.
- 27 · A rollback for every releaseOne step back to the last good version.
- 28 · Dependencies kept currentUpdate alerts on, and someone who acts on them.
- 29 · A named ownerOne person answers for the app, its access and its incidents.
These map onto established practice: the Cloud Security Alliance’s Secure Vibe Coding Guide for the application controls, OWASP’s guidance on excessive agency for the agent, and NIST’s Secure Software Development Framework (SP 800-218) for the process around both — its four practice groups are prepare the organisation, protect the software, produce well-secured software, and respond to vulnerabilities. Why the checks are needed in the first place: is vibe coding safe?
How Botminds covers the checklist when Piper builds.
When Piper builds from governed platform parts, many of these checks become how the builder works rather than tasks a team must remember.
| Check | With a vibe coding tool | On Botminds with Piper |
|---|---|---|
| 3 · Least privilege | Whatever keys the agent holds | Every tool call runs as you; your role is checked on each one |
| 7 · Destructive actions | A setting, if the tool has one | Builds on your yes; deletes need their own confirmation |
| 12 · Human review | Read the diff yourself | A brief and a numbered plan, approved before anything changes |
| 16 · Testing | Run it and see | Each change read back to confirm it landed; what was built is tested |
| 17 · Output encoding | Escape it yourself | Custom cards: templates cleaned, scripts sandboxed |
| 25 · Who did what | Add logging yourself | Every change recorded as agent work on your behalf |
| 27 · Rollback | Version control, if set up | Snapshots, diff, rollback and packages |
Measured: 53 of 53. In a 150-conversation test bank run as three users with different roles, every request beyond the asker’s role was refused with no change. Read the full design in enterprise vibe coding.
Vibe coding security checklist: common questions.
The technology behind itEnterprise vibe codingGoverned apps, built by conversation→What should a vibe coding security checklist include?
A vibe coding security checklist covers five gates: secrets and agent permissions before prompting; destructive commands and packages while building; human review and scanning before merge; tested access rules and a locked-down deployment; and logs, backups and rollback after launch.
What are the biggest security risks of vibe coding?
Injection and cross-site scripting in generated code, secrets in source or the browser, missing database access rules, invented packages that attackers register, agents with production access, and no way to undo changes.
How do I write a security prompt for vibe coding?
State the rules before the feature: secrets from environment variables, parameterised queries, validated and encoded input, sign-in on every route, generic errors. Then verify with review and scanners — a prompt lowers the miss rate but does not remove it.
Which security tools should run on a vibe-coded app?
Static analysis for code flaws, dependency scanning for vulnerable or unknown packages, secret scanning for keys in the code and its history, and a dynamic test against the running app for access-rule and header problems.
What is slopsquatting?
Registering a package under a name that AI models invent, so that code generated later installs the attacker’s package. Researchers found 205,474 unique invented package names across 576,000 generated samples.
How do I test that my database access rules work?
Try to break them. Query each table with only the public key, then sign in as a second user and request the first user’s records. Both should fail. Checking that a rule exists is not enough.
Does my AI app builder’s security scan make the app safe?
Treat it as one input. In the 2025 row-level-security case, a builder’s scan confirmed policies existed without testing whether they blocked access. Run your own tests at gates 3 and 4.
Do I need this checklist for a prototype?
For a throwaway prototype on sample data, gates 1 and 2 are enough: no real credentials, no production access. Run the full list once the app will hold real data or other people will rely on it.
- Cloud Security Alliance: Secure Vibe Coding Guide (April 2025)cloudsecurityalliance.org
- OWASP Top 10 for LLM Applications: LLM06:2025 Excessive Agencygenai.owasp.org
- OWASP Top 10 web application security risksowasp.org
- NIST SP 800-218: Secure Software Development Frameworkcsrc.nist.gov
- Veracode: 2025 GenAI Code Security Report (July 2025)veracode.com
- Spracklen et al.: We Have a Package for You! Package hallucinations by code-generating LLMsarxiv.org
- Matt Palmer: Statement on CVE-2025-48757mattpalmer.io
- Zhao et al.: Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasksarxiv.org
- AI Incident Database: Incident 1152incidentdatabase.ai
- Simon Willison: Not all AI-assisted programming is vibe coding (March 2025)simonwillison.net
See it on
your own work.
Bring one process and its documents. We’ll show you the agents, the controls and the record, running on your data.