Scale · pm · 10 min read

Bans Don't Work. What to Do Before Your Company Tries One on Vibe Coding

Gartner says 40% of enterprise software will be vibe coded by 2028. Security teams are already reacting. A PM's playbook for paving a road instead.

Published September 19, 2026 ·

governance security enterprise shadow-ai product-management

Almost everything on this site is written for someone building alone. This one isn’t. This one is for the PM who works at a company, whose ops lead just shipped a dashboard on Lovable over a weekend, and whose security team is about six weeks from finding out.

The collision is arriving on a schedule you can read off published research. Gartner predicts that by 2028, 40% of new enterprise production software will be built with vibe coding techniques and tools. Meanwhile a 2026 scan of more than 1,400 live vibe-coded applications found 65% already carrying a security issue and 58% shipping with at least one critical vulnerability.

Those two facts do not coexist quietly. Somebody in your company is going to try to ban this. If you want that not to happen, you need to show up with something better than enthusiasm.

First, stop treating it as one problem

The single most useful thing you can do in this conversation is refuse the word “vibe coding” as a single category. It hides two problems that have different owners and different fixes, and programs stall when people argue about them as one thing.

The builder-platform problem

Someone builds on Lovable, Base44, Replit, or v0. The app lives in the vendor’s cloud. The vendor owns authentication, the database, and the deployment defaults — so every tenant inherits the vendor’s security posture whether they know it or not.

This is a discovery problem. To your endpoint tooling, a person building on a hosted builder looks like ordinary browser activity. Nothing registers on an asset inventory.

In May 2026, Israeli security firm RedAccess scanned 380,000 publicly accessible assets built on these platforms. Roughly 5,000 of them, about 1.3%, held sensitive corporate information: medical records, financial data, strategy documents, customer-service transcripts. Axios and Wired verified exposed apps independently.

1.3% sounds survivable until you notice the denominator was found by a single company running a scan.

The coding-agent problem

Someone uses Claude Code, Cursor, or Codex on a managed laptop. Same mistakes in the generated app — but now the agent is also running with a real employee’s credentials, on your network, inside your SSO session. The first problem leaks data. This one can also delete it.

Different owner, too. The first is AppSec and IT. The second is AppSec and whoever watches runtime activity on your machines. Deciding which half a given tool belongs to is most of the governance work, and it is work a PM can do without any security background at all.

Why the ban is coming, and why it will fail

The ban is coming because the people responsible are outnumbered. AppSec teams commonly run at something like one security engineer per hundred software engineers, which makes manual review of a flood of homegrown apps arithmetically impossible. When you cannot review, you prohibit.

It will fail for a reason that is well documented and slightly uncomfortable: people ignore it. In a Software AG survey, 46% of employees said they would refuse to give up personal AI tools even under an outright organizational ban. A CISO panel this year put it more bluntly — the employee trying to finish their job is the most persistent adversary you have, and they will route around you, including by moving data to a personal account.

A ban does not reduce vibe coding. It moves it somewhere you cannot see, which is strictly worse than the status quo.

The part nobody wants to say out loud

Your colleagues building these tools are not careless. They are missing one specific thing: the attacker’s mental model that makes “should this table be readable by anyone with the URL?” an obvious question.

A Stanford study found that participants with an AI assistant wrote less secure code than those without — and were more confident it was secure. That study predates the current generation of tools, so treat the size of the effect as dated. The direction has not been contradicted since.

And the tools have not closed the gap on their own. Veracode’s 2026 GenAI Code Security Report puts the average security pass rate for AI-generated code at 56% — essentially flat year over year, despite models getting substantially more capable at everything else. Coding-specialized models scored no better than general-purpose ones. Capability improved. Security did not come along for the ride.

That is the argument you need, and it cuts both ways honestly: the tools are not going to save you, and neither is a policy document.

What a paved road looks like

The reference model is Netflix’s paved road: a supported path that wins because it is genuinely the easiest option, not because it is mandatory. Security teams have compressed this to “guardrails, not gates.” Here is the PM translation.

Pick the sanctioned tools and make them free at the point of use. Not “approved” — provisioned. If the blessed path requires an expense report and the unblessed path requires a personal credit card, you have built a gate and called it a road.

Keep a registry with named owners. For each AI-built internal tool: what it does, who owns it, what data it touches. This is a spreadsheet, not a platform. It is also the single highest-value artifact in the whole program, because it converts “we have no idea what exists” into a list.

Classify the data before anyone builds. Decide what counts as sensitive first. Every downstream control depends on that answer, and without it you are arguing about vibes.

Require a review before anything goes live, and keep it short. A fifteen-minute check that actually happens beats a formal review that people avoid.

Never let the default be public. The most expensive incidents in the RedAccess data were not clever attacks. They were defaults nobody changed.

What to do this week

1. Ask around and write down every AI-built internal tool you can find. Do not judge anything. Just list it. You will be surprised twice — by how many there are, and by how load-bearing one of them turns out to be.
2. Sort each one into builder-platform or coding-agent. Two columns.
3. For anything touching customer, employee, or financial data, check one thing: can it be reached without logging in?
4. Take the list to security before they come to you. Arriving with an inventory and a proposal makes you the person solving the problem. Arriving after the incident makes you part of it.

The honest limitation

None of this makes vibe-coded software safe. It makes it visible, which is a lesser goal and the only one available to you right now. Scanners are not reliable enough to lean on, review capacity is not going to triple, and the models are not improving on security.

What you are actually buying is the difference between an incident you can trace to an owner in an afternoon and one that takes three weeks to even locate. That gap is worth more than it sounds, and it is almost entirely won before anything goes wrong.

If you are building solo rather than inside a company, the individual-scale version of this is in our vibe coding security guide, and the agent-specific risks are covered in every file your agent reads is executable.