Vibe coding, building software by describing what you want to an AI assistant and accepting what it writes, can produce working software quickly. It is not safe to ship by default, because speed removes the review that normally catches flaws. Add the checks you would require of any code: review, tests, dependency checks and least privilege.
What do people want from vibe coding?
Mostly speed and reach. A designer wants a working prototype without a developer. A developer wants to skip boilerplate. A small team wants an internal tool by Friday. These are legitimate goals. This post does not rely on surveys. It starts from those goals and asks what has to be true for the result to be safe enough for its purpose.
Why does security need its own attention?
NIST's Secure Software Development Framework describes a core set of high level secure development practices that can be integrated into any software development life cycle. It says following them should help producers reduce the number of vulnerabilities in released software, mitigate the impact of those not addressed, and address root causes to prevent recurrence. The framework is not about who writes the code, so it applies whether a person or a model typed it.
CISA's Secure by Design material makes a related point in plain terms: software manufacturers should take ownership of customer security outcomes. Code you ship carries your responsibility regardless of how it was produced.
Which risks are specific to AI generated code?
The OWASP Gen AI Security Project lists LLM application risks. Two are directly relevant. LLM supply chain vulnerabilities cover the models, data and components a system depends on. Excessive agency covers LLM systems that can call functions and tools and take actions, and OWASP names excessive functionality, excessive permissions and excessive autonomy as typical root causes. When an assistant can run commands, install packages and write files on your machine, those apply to your development environment too.
There is also a plain software risk. A model can suggest a dependency you did not know you were adding, an outdated pattern, or a secret placed in the code. These are ordinary flaws that arrive faster.
A constructed example
A founder builds a customer portal over a weekend using an assistant. It works. A review before launch finds three things: an API route that returns any customer's record when you change the ID in the URL, a key for a payments service written directly in a source file, and four packages the founder did not choose, one of which has a known vulnerability. None of this is exotic. A short checklist fixes all three in an afternoon: add an authorization check per record, move the key into a secret store and rotate it, and update or replace the vulnerable package.
How to check or apply this
- Decide the risk level first. A throwaway script for you needs less than a portal holding customer data.
- Read the code that handles authentication, authorization, payments and personal data. Do not ship those parts unread.
- Write tests for access control: try to read another user's data and expect failure.
- List every dependency the assistant added, and check each for known vulnerabilities and for whether you need it.
- Search for secrets in the code and history, and move them to a secret manager.
- Limit what the assistant can do on your machine and in your cloud account: least privilege, no production credentials, review before commands that change systems.
- Run static analysis and a dependency scan in CI on every change.
- Keep a human approver for production changes.
- Record in the repository which parts were generated, so reviewers know where to look.
Safeguard's SBOM and dependency scanning, reachability analysis and policies and gates are built for the dependency and review steps, and its MCP Guardrail addresses what agents may call.
Quick check
Is AI generated code less secure than human code?
This post does not claim that. The point is that generated code needs the same review and testing, and it arrives faster, so unreviewed flaws arrive faster too.
What is the single most useful check?
Test access control by trying to read or change another user's data. It finds a common and serious class of flaw quickly.
Sources
- NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1
- CISA: Secure by Design
- OWASP Gen AI Security Project: Top 10 for LLM Applications
- OWASP Gen AI Security Project: LLM06:2025 Excessive Agency
Last reviewed: 18 October 2026.
