Ten reasons CIOs and CISOs block vibe-coded apps, answered
We reviewed the public commentary from CIOs, CISOs and industry analysts, along with published research from Red Access, Veracode and Gartner, on why IT leaders default to saying "no" when the business wants to use vibe-coded apps. Below are the ten objections that came up most often, and how Portainer-Run was built specifically to help you say "yes", in a safe and governed manner.
Do vibe-coded apps expose sensitive company data to the internet?
The objection: "Business builders build and publish apps with sensitive data to the open internet, often with no authentication."
They can when they are published on a vibe-coding platform's public hosting, and the fix is to deploy them inside your own network instead. In May 2026, Red Access researchers reported finding about 5,000 apps built with Lovable, Base44, Replit and Netlify that contained sensitive corporate data and were publicly accessible.
Under Portainer-Run, the apps your business builders create are deployed inside your internal network, so they have no exposure to the public internet. Every app deploys onto your own Kubernetes environment, inside a sandbox made of namespaces and quotas, network security policies, pod security, and optionally an authenticating ingress. An app is reachable only by users on your trusted network, and has near-zero network reach beyond what you explicitly grant.
Portainer-Run removes the need for a business builder to deploy their apps on public SaaS platforms, which circumvent your security controls and policies; they only go there today because it is the easy path.
How do you stop hardcoded secrets in AI-generated code?
The objection: "Hardcoded secrets end up in code and in public GitHub repos."
Keep secrets out of source code entirely, and route every app through a private repository where secret scanning runs before anything is deployed. Gartner analyst Pete Shoard described hardcoded secrets uploaded to GitHub as the top risk vibe-coded apps create today.
Portainer-Run commits every app to a sanctioned repository defined by your IT team, not a public one, and your own secret detection and code scanning can run against the committed code at that point, before anything starts.
Portainer-Run also automatically detects any environment variables that look like secrets (names containing TOKEN, PASSWORD, API_KEY, DSN, and similar); when found, they go directly into a Kubernetes Secret and are never committed to the Git repository. The deployment files committed to Git contain only a reference to the secret.
How can IT find and inventory vibe-coded apps?
The objection: "We can't see these apps. They aren't in any inventory."
You can only inventory apps that deploy through a path you control, so the answer is to give business builders a sanctioned deployment path they would rather use. Today, TechTarget's guidance for CIOs on finding these apps includes reviewing credit card statements for platform subscriptions and searching hosting platforms for corporate accounts, which shows how far outside IT's view they currently sit.
You cannot see apps that run outside your scope of control, that is certain. Giving your people a way to deploy their apps inside your network, in a way that suits their needs, removes their reason to deploy externally.
Portainer-Run is a UI built for the business builder, and it gives you, the IT executive, the visibility, control and governance you need. Every app carries a "managed-by" label and records who deployed it and when. For apps already running on Lovable, Bolt, or Replit, the offramp brings the existing source inside, under the same inventory and governance; a self-contained app needs no rebuild.
Do vibe-coded apps bypass governance, security review and change management?
The objection: "These apps skip governance, architecture review, security review, and change management."
They do when they are deployed outside IT, and the fix is to build those gates into the deployment path itself, so every app passes them automatically.
Portainer-Run doesn't skip those gates, it encodes them. Git is the source of truth, so every deployment is a commit before it runs, and the running state always tracks the repository. There is no push path from the builder to the cluster; Portainer Business reconciles only from the repo, and your cluster's admission controllers reject anything that fails policy. You get change history, approval points through branch protection, and a full audit trail by default, without routing every app through a manual review queue.
Can business users handle application authentication, access control and data classification?
The objection: "Business builders don't understand application-level authentication, access control, or data classification, so the apps they build get these wrong."
Most can't, and they shouldn't have to; authentication and data access should be enforced by the platform the app runs on, not written into each app.
With Portainer-Run, the most dangerous of these decisions are taken out of the app's code and enforced by the platform around it.
Authentication. When the authenticating ingress is enabled, every app sits behind it, backed by your centralized corporate user directory, and a user must authenticate before a request ever reaches the app. The builder doesn't write a login screen, handle passwords, or manage sessions, so there is no homegrown authentication to get wrong, and an app with no login of its own is still not anonymous. This covers authentication into the application, not per-user access control within the application itself.
Access control. Because authentication happens at the ingress, the question of who can reach the app at all is answered by your directory, not by the builder's code.
Data classification. An app's data exposure is limited by what it can connect to, and each app runs with near-zero network reach beyond what you explicitly grant. That turns data classification from a coding decision the builder has to get right into an infrastructure decision IT makes; you decide which namespaces can reach which data sources, and an app deployed there can reach only those. Connection credentials for those sources are held as Kubernetes Secrets, not in the code or the repository.
Is AI-generated code secure?
The objection: "AI-generated code is insecure by default."
Often it isn't. Veracode's 2025 GenAI Code Security Report, which tested more than 100 large language models, found that generated code introduced OWASP Top 10 vulnerabilities in 45% of cases.
Portainer-Run doesn't claim to make the code secure. The counter is to limit the damage and put the checks in your hands. Every app passes your repo scanning before it runs. Apps run under the baseline pod security profile, with dangerous capabilities dropped, privilege escalation disallowed, seccomp pinned, and no service account token, so no app has a path to the Kubernetes API. Explicit resource limits apply to every app. A flawed app stays a flawed app, but it is authenticated, isolated, and visible, not exposed on the internet.
Who supports and maintains vibe-coded apps when the builder leaves?
The objection: "Who supports and maintains these apps? When they break, it lands on IT, and the builder may have left."
Whoever the organization makes responsible, which is only workable when the app is standard, readable code in a repository the organization owns. As CIO.com has pointed out, the maintenance and support of vibe-coded apps falls on the organization that deploys them.
The app doesn't depend on the person who built it. It is standard source in your Git repository, running as a standard Kubernetes deployment on stock public runtime images, so any business peer can take it over, put the code back into their AI tool and request updates. When an app proves itself and becomes something the business relies on, it can graduate to a professional development team, which sees every technical decision Portainer-Run made and can take it into a standard DevOps process. Our sister product to Portainer-Run, Portainer-IDP, handles the graduation of an application into IT once it has proved its value.
Will vibe-coded apps create sprawl and technical debt?
The objection: "This creates sprawl and a new wave of technical debt."
They will if every app is built, hosted and wired differently, and a consistent deployment structure is what keeps them manageable. Gartner's Shoard made the same point: apps with no common base can't be fixed with a single patch.
Most sprawl comes from inconsistency: every app built, hosted, and wired differently. Portainer-Run gives every app the same structure; same repo layout, same manifest pattern, same GitOps path, same runtime images, same security baseline. A platform administrator changes shared settings, such as resource limits, in Git like any other GitOps change.
Of course, the more apps you bring into your business, the more apps you eventually have to support. Vibe-coded apps are a reality, and they are greatly beneficial for business efficiency, but most of them are an idea worked out in code and then set aside, and only a minority go on to become something the business depends on. Investing time, money and effort into fully productionizing an application before it proves its worth doesn't make sense, so Portainer-Run supports safe ideation, and lets the apps that matter self-select.
Can vibe-coded apps meet SOX, SOC 2 and audit requirements?
The objection: "We can't meet SOX, SOC 2, or regulatory audit obligations with these apps."
They can, provided each deployment produces the record auditors look for: who deployed what, when, with what access, and what changed.
Portainer-Run produces that as a byproduct. Every change is a commit in your repo with full history, and every app records who deployed it. Access runs through your existing Portainer identity and RBAC, with no new identity store to audit. Apps run on infrastructure you own, including on-premises and air-gapped environments, which covers data residency and regulated-infrastructure requirements.
Are vibe-coding platforms a third-party risk?
The objection: "The vibe-coding platforms are a third-party risk. They host the app, own the auth and the database, and our data and IP sit on their cloud."
Yes, because the platform hosts the app, owns its authentication and database, and sets its security defaults; running the apps on your own infrastructure removes that dependency.
This is the core difference. Portainer-Run isn't a vibe-coding development tool or a hosting platform. Apps are created using whatever AI tooling your people prefer (or are authorized to use) and run natively on your own Kubernetes environments, not a vendor's cloud, with standard Git and standard manifests, so there is no lock-in to the AI app provider. Deployment happens inside your perimeter.
Should IT just block vibe-coded apps?
The objection: "OK, but still, why not just block it?"
No. A block doesn't hold; it moves the activity onto personal accounts and outside clouds you can't see, which is the opposite of control. The approach that holds is to give these apps a sanctioned, secured place to run inside your environment, so the work comes to a surface you govern.