Vibe coding has moved software creation outside engineering. Marketers, analysts, and operators now describe an outcome in natural language, accept whatever the AI produces, and ship it without reading the code. The result is a growing pool of applications with no documented owner, no traceable dependencies, and no one who can explain how they handle credentials or data.
For business leaders, this is an accountability problem, not just a code-quality one. Wiped databases, exposed customer records, and regulated data processed without audit trails all trace back to code no one reviewed. Bans push the behavior into shadow tools. Inaction leaves leadership blind to what has already shipped.
This article catalogs the specific coding risks that arise when non-engineers ship AI-generated code, and points to the pre-merge and runtime controls that mitigate them.
What vibe coding risk looks like inside a business
When non-engineers ship AI-generated code without reading it, the same failure modes recur. The risks fall into ten patterns that recur across the incident record, each with a specific business consequence:
The risks fall into ten patterns that recur across the incident record, each with a specific business consequence:
Broken authorization and exposed data: Vibe-coded applications have shipped with open storage buckets, unauthenticated APIs, and bypassed row-level security, leaving customer data reachable from the open internet and often discovered by outside researchers before internal monitoring catches it.
Leaked secrets in commits: GitGuardian's 2026 report found AI-assisted commits leak secrets at 3.2%, roughly double the 1.5% baseline, so API keys, database passwords, and cloud credentials end up in shared repositories faster than rotation can keep up.
Hallucinated dependencies: Models invent package names that don't exist, attackers register those names with malicious payloads, and the AI recommendation becomes a supply-chain entry point running with the application's privileges.
Prompt injection and excessive agency: Prompt injection tops OWASP's LLM risk list (LLM01), and excessive agency (LLM06) covers agents granted more capability than the task requires. Together they turn a helpful application into an insider.
No provenance or ownership: Commit history shows hundreds of generated lines with no context on the business logic, and when the person who prompted them leaves, the logic leaves too.
Mixed environments: Development, test, and production share credentials or run against the same database, so a prompt that "just wanted to test something" writes to production because the boundary never existed.
Shadow AI use: Gartner's cybersecurity survey of 302 cybersecurity leaders found 69% of organizations suspect or have evidence that employees use prohibited public generative AI, and Samsung ran the full arc, banning generative AI after engineers pasted proprietary source code into ChatGPT before reversing course and deploying ChatGPT Enterprise and Codex.
Compliance exposure: Citizen-built applications process regulated data and route approvals without validation, access controls, or audit trails, while the EU Cyber Resilience Act and the revised Product Liability Directive subject business-built software to strict disclosure and liability obligations.
Machine identity sprawl: Machine identities, including service accounts, API keys, and agents, already far outnumber humans in most enterprises and mostly sit outside any governance program. Every unmanaged agent is a persistent credential the business can neither audit nor revoke.
Most documented incidents cluster into the first two: broken authorization and destructive agent actions. Governance aimed at those modes covers most of what has actually gone wrong in the wild, though the others compound quietly until an incident forces attention.
Tines 3B runs AI-generated agents, apps, and automations in a code-first environment with built-in credential protection and monitoring, so IT maintains visibility as the number of builders grows, rather than pushing them into shadow tools.
Governance gates every code change must clear before shipping
NIST's Secure Software Development Framework (SP 800-218) applies the same baseline to a staff engineer, an autonomous agent, and a marketer prompting Lovable. NIST SP 800-218A adds practices specific to AI model development. Seven gates cover most of what SP 800-218 requires, plus a pre-merge secrets gate and an approved-tool list tuned for AI-generated code.
Provenance and traceability: The release record shows who or what wrote the code, which model generated it, and the parameters used.
Least-privilege access: Version control ties every change to an individual account and requires commit signing. Code-owner review is required. Agents raise deploy requests rather than holding production credentials.
Secrets scanning as a pre-merge gate: Every commit is scanned before merge, and anything exposed is rotated rather than quietly deleted.
Human review where stakes are highest: Every pull request that touches authentication, data handling, or user input goes through security testing and code review. The principle is straightforward: no blind usage of AI-generated code.
Verified dependencies: Teams verify every AI-recommended package before it enters the build and keep the software bill of materials up to date.
Separated environments: Development stays isolated from test and production, and credentials don't cross any boundary.
Approved tools and data classes: Policy permits only approved business or enterprise tiers. Credentials and encryption keys never enter any AI tool.
These gates establish accountability before merge. After deployment, runtime controls govern execution: OWASP's AI agent security guidance separates decision-making from execution, so an agent proposes an action and an independent policy layer validates scope, privilege, and approvals before it runs. CISA treats human-in-the-loop controls as mandatory gates for irreversible actions. Credentials shift from long-lived service accounts to task-scoped tokens granted at task start and revoked at completion.
Running this across a real stack requires orchestration. Deterministic automations, agentic steps, and human approvals need a single governance layer with a consistent audit trail. In practice, a leaked token triggers an automated revoke-and-rotate flow; an agent reads a pull-request diff and posts a draft risk classification for a reviewer; and an access request is routed to the resource owner for approval before provisioning—every step landing in the same log.
How the risks land differently for security, IT, and the business
Each function inherits a distinct slice of the vibe coding problem, and the split matters because the controls that mitigate one slice rarely cover the others. Security absorbs the attack surface: AI writes application code, database schemas, API gateway configurations, and infrastructure-as-code templates that work but were never checked for safety, while firewall rules and identity policies are a red zone that requires expert review before AI output ships there.
Prompt injection tops OWASP's LLM risk list, and hallucinated dependencies can turn generated code into a supply chain entry point. IT absorbs identities and maintenance: agents already far outnumber humans in most enterprises and mostly sit outside any governance program, and AI-generated code compounds the maintenance burden because commit history offers no context for the business logic, and refactoring has fallen as generated volume has risen.
Business functions absorb compliance. Citizen-built applications process regulated data, route approvals without validation, and create records without audit trails. For anyone operating in the EU, the Cyber Resilience Act and revised Product Liability Directive make governing business-built software a legal requirement, not a preference. Runtime policy gates and the logs they produce become the audit evidence regulators ask to see.
The table below summarizes how each function's exposure maps to the control that closes the gap, so leaders can see at a glance where their current program covers the risk and where it doesn't.
Making accountability the standard for AI-generated code
For any piece of running software, the leaders handling this well can identify who built it, what it can touch, and who approved its last high-risk action. The organization that ships AI-generated code carries production risk, while operational accountability sits across service owners and committers, supported by reviewers and defined review processes. Vendor disclaimers push verification back onto the buyer, and courts have not resolved how tool makers and deployers share responsibility.
The fastest way to test the model is with a workflow that already worries you: an access request, an offboarding, or an agent action that currently runs on trust. Apply the pre-merge gates and runtime controls above to that single workflow, and use what you learn to shape governance for the rest.
The fastest way to test the model is with a workflow that already worries you: an access request, an offboarding, or an agent action that currently runs on trust. Apply the pre-merge gates and runtime controls above to that single workflow, and use what you learn to shape governance for the rest. Teams tackling wild code at scale are consolidating agents, apps, and automations into a single code-first environment where credential protection, monitoring, and audit trails are built in rather than bolted on the pattern behind Tines 3B. Sign up today for a demo.
Frequently asked questions
What does it take to run vibe-coded software safely in production?
Production use requires review gates. Vibe-coded applications can contain authorization failures, exposed secrets, and denial-of-service flaws. According to Sonar, AI now writes or assists with a substantial share of code, while many developers commit AI-generated code without reviewing it. Require human-led validation of any AI-generated code touching authentication, data handling, or user input before it ships.
What's the difference between vibe coding and AI-assisted development?
Engagement with the output. Karpathy defined vibe coding as trusting the tool and disengaging from the code. The practical distinction is that AI-assisted development keeps review and testing in the loop and preserves provenance; the generation step is the same in both.
How do the EU Cyber Resilience Act and Product Liability Directive change vibe coding risk?
They move business-built software into scope for the same obligations that apply to commercial products. The Cyber Resilience Act requires organizations to report actively exploited vulnerabilities to ENISA, and the revised Product Liability Directive brings software, including AI systems, under strict liability. For teams operating in the EU, the citizen-built application a marketer prompted into existence carries the same disclosure and liability exposure as a shipped product.
Who is liable when AI-written code fails?
The organization that deploys it. Air Canada was held responsible for its chatbot's output because the system was treated as part of the company rather than a separate entity. That remains the clearest precedent for AI-generated behavior running in production.
How does governance for AI agents differ from governance for coding assistants?
An assistant generates code that review gates can catch before merge. An agent acts, so it needs its own identity, task-scoped credentials that expire, approval gates for irreversible actions, and audit trails that trace every action back to the human who delegated it.