AI might have built it, but you still own it.

Vibe coding is awesome, until its not....

Vibe-coding is one of the most seductive productivity narratives in enterprise technology right now, however the downside consequences (and there are plenty, dont believe hte hype!) show up in your security posture, your compliance exposure, and your attack surface, often long after the person who built the thing has moved on.

The tools deliver on the pitch. A business analyst, a product manager, an operations lead with no engineering background... anyone can prompt their way to a “working” application in an afternoon. Internal tool, customer portal, data dashboard, automation workflow. It works, it looks good, it solves the immediate problem, and then it gets deployed, shared, and quietly becomes part of how the business operates. And then another one gets built. And another. By different teams, for overlapping purposes, with zero visibility across the organization.

An AWS manager recently documented exactly this, building a tool to detect AI-created applications inside a single AWS business unit. He found hundreds. Teams didn’t know about each other’s apps. Multiple tools were doing the same thing for different groups. None of them were being maintained. All of them were sitting there, quietly accumulating risk.

That’s the reality of vibe-coded enterprise software at scale, and it’s not an edge case anymore. Vibe-coding massively scales the long-standing problem of shadow IT, empowering non-technical developers to rapidly create and deploy applications completely outside the purview of IT and security teams, creating a vast, unmanaged, and invisible attack surface running live in the enterprise. Security teams are being asked to defend a growing portfolio of production applications they don’t know exist, built by people who don’t understand what’s running under the hood, using AI models that introduce security flaws into nearly half of all generated code despite appearing production-ready, with no significant improvement across newer or larger models. And lets not even talk about OSS license exposure, using seemingly “free” libraries that may come with strict conditions.

Now add MCP servers to that picture. Employees are deploying Model Context Protocol servers on their laptops, connecting them (using their personal credentials) to sensitive internal systems, and plugging those connections into SaaS-based vibe-coding platforms running in someone else’s cloud. The data flowing through that chain is crossing trust boundaries that nobody mapped, nobody approved, and nobody is monitoring. In February 2026, Wiz researchers discovered a breach in which a vibe-coded platform exposed 1.5 million API keys and 35,000 user emails because it was built without basic security protocols, allowing anyone to hijack AI agents and access sensitive third-party services. That was a public platform. The same architecture is being replicated inside enterprises every day, pointed at systems of record, sometimes exposed on the open internet, with access levels that were granted casually and have never been reviewed.

Research across Fortune 50 enterprises found that AI-assisted developers produce commits at three to four times the rate of their peers but introduce security findings at ten times the rate, creating a security debt that accumulates faster than organizations can remediate it. The person who prompted the app into existence is not thinking about any of this. They solved their problem on a Thursday afternoon. The security debt, the maintenance obligation, the compliance exposure, and the unpatched dependencies are yours... indefinitely, for the life of every application that got deployed and then quietly forgotten.

If the creator leaves the company, there is no clear process for handing over responsibility. Without established ownership, zombie apps pile up through natural employee churn. Enterprises already struggle to maintain software built by dedicated teams with full institutional context. The vibe-coded app has none of that... no documentation, no security review, no understanding of what’s actually running, and an owner who never thought of themselves as owning anything in the first place.

Every application, regardless of how it was built, accumulates obligations from the moment it goes live. Security vulnerabilities need patching, dependencies go out of date, authentication mechanisms need reviewing, compliance requirements evolve, and integrations break when upstream APIs change. None of this cares whether the author wrote the code or prompted it into existence over a long weekend. Prompting an application into existence is the start of an obligation, not the end of one. Treating it as a finished deliverable is how enterprises end up with a sprawling inventory of unowned, unpatched, undocumented software that nobody remembers creating and nobody wants to touch.

So what’s the answer? Banning vibe-coding doesn’t work... shadow IT has never responded to blanket prohibition, and a tool this useful and this accessible isn’t going away. The answer is governance, but not the kind that creates a six-week IT approval process that everyone routes around. The kind that makes the responsible path also the easy path.

The starting point is visibility. You cannot govern what you cannot see, and right now most enterprises have no inventory of what’s actually running. The AWS story is the proof point... hundreds of apps, one business unit, nobody knew. Before any policy conversation, that gap needs closing.

The second piece is ownership as a condition of deployment, not an afterthought. If you built it and you want it running inside the enterprise, you register it, you classify the data it touches, and you put your name against it as the ongoing responsible party. Not a bureaucratic exercise... a thirty-second declaration that creates accountability where none currently exists.

The third piece is where most enterprises hit the wall. The vibe-coder solved their problem in an afternoon using a SaaS platform because the alternative... self-hosting, containers, Kubernetes, infrastructure... is way beyond what they signed up for. So the app ends up on someone’s cloud subscription, outside the perimeter, because that was the only path that didn’t require an engineering degree. Closing that gap means giving non-technical builders a deployment target that is genuinely simple, self-hosted, and enterprise-grade... without expecting them to understand what’s running underneath it.

Here at Portainer, we specialize in making hard things easier… that our core these with Portainer as a management layer for Docker and Kubernetes… but even Portainer is too complex for the vibe-coded developer that prefers SaaS/Pass. This is why we created Portainer-Run (github.com/portainer/portainer-run). A Google Cloud Run-style deployment experience, backed by the Portainer API, self-hosted inside your own infrastructure. The vibe-coder gets a simple interface to deploy their AI built, containerized app. IT gets visibility, access control, and a managed environment they actually govern. The app stays inside the perimeter. Nobody needs to learn Kubernetes. And critically, the alternative to SaaS doesn’t require a six-month infrastructure project to stand up.

The vibe-coding wave is not going to slow down. The question for every enterprise is whether the apps your teams are building land somewhere you control, or somewhere you don’t. Right now, for most organizations, the answer is the latter... and the clock on that is already running.