Vibe Coding Enterprise Risk: The Problem Is Not That AI Writes Code

TL;DR: The enterprise risk in vibe coding is not that AI writes code. It is that AI-assisted code reaches production without anyone being able to say what was allowed: which data went into prompts, which models and tools were used, which checks ran, and who approved the merge. The fix is a governed path for AI-assisted coding, tested with a failure drill, with a person still making the merge decision.

“Vibe coding” started as a description of a personal style: describe what you want, accept what the model gives you, keep going (Karpathy, February 2025). For a weekend project that is fine. Inside an enterprise, the same habit spreads quietly across hundreds of developers, many tools and every repository they can reach.

This post names the specific risks, explains why bans tend not to help, and sets out a governed alternative that teams can adopt early, before an incident forces the question.

Key takeaways

• The four risks are unreviewed AI code, secrets in prompts, ungoverned tool access and missing provenance.
• All four share one root cause: no single place where AI-assisted coding is allowed, checked and recorded.
• Banning AI coding removes the record without removing the activity.
• Govern the request, the pull request and the merge, then drill the failures you fear.

Risk 1: AI code merged without real review

AI models produce plausible code quickly. A reviewer facing a queue of plausible pull requests reads less carefully, and the volume of change can exceed what a team can meaningfully check. The specific failure modes are familiar: hard-coded credentials, unsafe input handling, outdated or vulnerable dependencies, and occasionally a dependency that does not exist at all, because the model invented a package name.

Review is necessary but not sufficient. It needs automated checks underneath it so that a person is judging the hard cases, not hunting for the obvious ones.

Risk 2: Secrets and customer data in prompts

The risk that gets less attention is what goes out, not what comes back. Developers paste config files, stack traces and sample records into prompts to get better answers. Those can carry cloud keys, API tokens, passwords and customer identifiers.

Repository secret scanning catches credentials that land in code (about secret scanning). It does not see a key that was pasted into a chat with a model and never committed. That has to be handled on the request path.

Risk 3: Ungoverned tool and model access

Coding assistants increasingly act: they run shell commands, install packages, call tool servers and open pull requests. In an unmanaged rollout, each team picks its own models and tools, and agents often run on a developer’s personal token with broad access. The result is a reach nobody designed and nobody can list.

This is an identity problem as much as a coding one. Our post on AI agent identity and permissions covers why each agent needs its own scoped credential rather than borrowing a person’s.

Risk 4: No provenance

Six months after a change, can you answer these?

• Was this code AI-assisted?
• What policy was in force when it was written?
• Was anything blocked or redacted from the prompt?
• Which checks ran on the pull request, and what did they find?
• Who approved the merge?

In most organizations the honest answer is no. That is the real enterprise risk: not a single bad line of code, but the inability to say what was allowed when a regulator, auditor or incident review asks.

Why a ban does not fix it

Banning AI-assisted coding is the obvious response, and it tends to fail in a predictable way. The productivity pull is strong, so usage continues on personal accounts and unmanaged tools. You keep the risk and lose the record.

A better position is to make the governed path the easiest path: one route for AI-assisted coding that applies policy, runs checks and keeps a record, without asking developers to change how they work day to day.

The governed alternative

Moring’s AI-DLC governed delivery is built around three checkpoints.

At the request

One command per laptop routes the coding assistant through an AI gateway; developers keep their own subscriptions. AI policy runs on every request:

• Blocked, nothing sent: private keys, US social security numbers, payment card numbers, classification labels and customer IDs.
• Redacted, the rest goes through: cloud keys, GitHub, Slack and model API keys, and password values.
• Only approved models and AI tools are accepted.

Rules start in monitor mode so you can see what would be caught before you enforce. The last ten policy versions are kept, which answers “what was the rule that day?” Security admins can read sessions for 30 days, with sensitive values masked.

At the pull request

Security Check runs seven checks on every pull request to a protected repository: secrets, risky code, AI code smells, fake packages, dependency CVEs, infrastructure and an AI review. It blocks only a new high or critical finding on a line the change wrote; everything else warns. It fails closed if a check cannot run. In the AI review, one model proposes flaws and a separate verifier tries to disprove each; only confirmed findings block, and uncertain ones go to a person.

The target is unsafe code, not AI-written code. That distinction matters, because a check that punishes AI use pushes developers to hide it.

At the merge

A person merges, under the same branch rules that apply to everyone. The checks make that decision informed; they do not replace it. The human still decides.

Run a failure drill

Policies on paper are claims. A failure drill turns them into evidence. In a test environment, with test values, try each of these and confirm it is caught and recorded:

Keep the results. A drill log is one of the most persuasive documents you can bring to a security review, because it shows the controls working rather than describing them.

Why moving early matters

AI-assisted coding is already inside most engineering organizations, whether or not it is sanctioned. Every month without a governed path adds code with no provenance. Teams that set up the path early get two things: a clean record from that point forward, and a baseline of what their developers actually send and receive, which makes later policy decisions grounded rather than guessed.

The first step is small. Route coding assistant traffic through a gateway in monitor mode, look at what the policy would have caught, and decide which rules to enforce. Then protect your most sensitive repositories with pull request checks, and run the drill. The gateway, the policy and the evidence are the same three layers described in where an AI control plane fits in enterprise architecture, applied to source code rather than to a business workflow.

The question to be able to answer is simple: for any AI-assisted change in production, what was allowed, what was checked, and who decided? When you can answer it from records, vibe coding stops being an enterprise risk and becomes an ordinary, governed way of working.

Frequently asked questions

Sources

About the author

Arya SharanProduct Marketing & GTM, Moring AIChennai

Owns product marketing and go-to-market at Moring AI across positioning, demand and enablement. Works with regulated buyers on how governed AI agents are scoped, evaluated and bought. Writes about the operating questions that decide whether an agent reaches production.

LinkedIn profile →