Your developers are already using AI to generate production code, and your approval process has no idea what to do with it.
Vibe coding — the practice of describing intent to an AI and accepting the generated output with minimal review — is not a future risk to plan for. It is happening in your environment now, probably in three to five teams you could name, and the security implications are fundamentally different from anything your existing SDLC controls were designed to catch. The threat model is different. The controls are different. The approval framework has to be different.
This guide works through each of those three layers in the register you will actually use when you bring this to your risk committee.
The Vibe Coding Threat Model
The canonical SDLC threat model assumes a human wrote the code and understood what they wrote. Vibe coding breaks both assumptions simultaneously. A developer who prompts an AI to “build an API endpoint that pulls user data based on the request parameter” may ship a working feature with a textbook IDOR vulnerability — not because they are incompetent, but because they never read the code carefully enough to see it.
The primary threat surface areas break into four categories:
- Supply chain contamination via training data: LLMs trained on public repositories inherit the insecure patterns in those repositories. Deprecated cryptography, hardcoded credential patterns, SQL concatenation — these appear in AI-generated code because they appeared frequently in training data. Your SAST tool will catch some of it. It will not catch logic that is syntactically valid but semantically wrong.
- Prompt injection into the development pipeline: If developers are feeding external data into prompts — pasting error messages, API responses, or user-supplied content into their AI coding sessions — attackers who control that data can influence the generated code. This is not theoretical; it is a known attack class with documented proof-of-concepts.
- Opacity of AI-generated code at review: Code review works because reviewers can build a mental model of what code does. AI-generated code, particularly for complex logic, is often syntactically dense in ways that defeat fast review. Reviewers approve it because it looks complete and correct, not because they verified it is.
- Data exfiltration through the AI coding tool itself: Every developer pasting proprietary code, internal API schemas, or customer data samples into an external AI service is creating a data egress event. Most organizations have no visibility into what is being sent or to whom it is being sent.
Vibe coding security cannot be addressed by telling developers to stop. It has to be addressed by controlling the environment in which AI-assisted development happens.
Controls That Match the Threat
The controls for vibe coding security are not a checklist you staple to your existing AppSec program. They are architectural changes that have to happen at the infrastructure and process layer.
On the data exfiltration threat: the only effective control is running the AI model inside your perimeter. An acceptable-use policy that says “don’t paste sensitive code into ChatGPT” is not a control — it is a hope. Organizations using Peridot deploy AI coding capabilities inside their own infrastructure, which means code never leaves the environment and prompt history stays within your data boundary. That is a control. A policy is documentation of a risk you accepted.
On the code quality and hidden vulnerability threat: you need AI-specific SAST augmentation, not just standard ruleset scanning. Standard SAST catches known patterns. AI-generated code can produce novel insecure patterns that no ruleset covers because no human would have written them that way before. The complementary control is mandatory human review of all AI-generated code above a complexity threshold — measured in cyclomatic complexity, not lines of code — with reviewers who are explicitly told the code was AI-generated and must treat it as untrusted by default.
On prompt injection: any development workflow that allows external content to be incorporated into AI prompts requires the same input validation controls you would apply to a production web application. That means sanitization, context separation, and logging of prompt content for audit purposes.
On review opacity: require AI-generated code to be annotated before review. The developer submitting the code must be able to explain, in plain language, what each section does and why. If they cannot, the code does not pass review. This sounds simple. It directly addresses the failure mode where a developer ships code they do not understand because the AI generated it confidently.
An Approval Framework for Vibe-Coded Applications
Standard application approval processes evaluate what an application does. Vibe coding security requires evaluating how the application was built and whether the builders understood it.
The approval gate should operate on three tiers based on data sensitivity and deployment scope.
Tier 1 — Internal tooling, non-sensitive data: Standard SAST and DAST pass, developer attestation that AI-generated components have been reviewed and understood, documentation of which components were AI-generated. No additional gate required. Turnaround: standard release cycle.
Tier 2 — Customer-facing applications or internal applications touching PII, financial data, or regulated data classes: Everything in Tier 1, plus mandatory AppSec team review of AI-generated components flagged by the developer, penetration test of the AI-generated logic specifically, and architecture review confirming that AI-generated code does not have elevated privilege access without explicit justification. Turnaround: add two weeks minimum.
Tier 3 — Applications in scope for SOC 2, HIPAA, PCI, or equivalent: Everything in Tier 2, plus external code audit of AI-generated components, formal documentation of AI tools used and their data handling practices, and board or risk committee notification that AI-generated code is present in the compliance scope. Peridot’s architecture — where model access, audit logs, and data handling are controlled infrastructure rather than third-party SaaS — substantially reduces the documentation burden at this tier because the controls already exist and are auditable.
The framework works only if developers are required to declare AI-generated code at submission. That declaration requirement has to be enforced through process, not honor system — meaning your CI/CD pipeline should include an AI-generation disclosure step that is not optional.
The organizations that treat vibe coding security as a policy problem will spend the next two years writing incident reports. The organizations that treat it as an infrastructure and controls problem will have a defensible posture before those incidents happen — and a much shorter conversation with their auditors when AI-generated code shows up in a compliance scope, because it will.