When a non-developer at a US trade association used a consumer AI tool to build a working vibe-coded app for their research team, then asked forgiveness afterward, the CIO had a choice: shut down a tool his team relied on or make it safe.
He reached out to our team here at Cloudwell, and we brought the app into the organization’s Azure environment, secured it with Microsoft Entra ID and put guardrails around future AI-assisted changes, all within a day.
The business kept its app, and IT got back control.
A trade association’s vibe-coded research app, discovered on a Friday
The request came to us from the CIO of a national trade association in the US. One of his staff, with no development background, had used an external consumer AI coding tool to build a web app for an annual research project.
Each year, the association’s research team collects, checks and publishes the data behind a series of industry rankings. The app handled manual data entry, scraped government data sources automatically, and kept everything prepped for release.
None of it touched the organization’s Microsoft environment. The app ran on the employee’s personal account with a third-party hosting platform, used a database supplied by that platform, and pushed code changes to a personal GitHub repository.
It was vibe coding in its purest form: describing what you want to an AI tool and letting it write the code. And IT had no view of any of it until the CIO found out on a Friday.
He was candid about his position. The app broke a list of policies. It was also saving the research team a lot of time, and the whole team was using it. The employee had built first and asked permission later.
His ask was simple: can you help?
Our suggestion was to move it into the association’s own Azure infrastructure and internal repositories, put policies around how it gets updated and released, and make it clear who owns it.
Dashboards, charts and live data: what one non-developer built with AI
The app was impressive. It had status tracking, dashboards, monthly and yearly charts, filters and an activity feed, all holding a large volume of live research data.
“A couple of years ago, that would have taken months, or a year, to develop,” says Chris Alechko, co-founder and CTO of Cloudwell.
It was also big. The code ran to thousands of files, far too much for anyone to review line by line. So, our job was to put controls around the code and everything that changed it.
Consumer AI, hardcoded passwords and a personal repo: the risks inside the vibe-coded app.
The root of the risk was where the app was built. Consumer AI tools are designed for individuals, so anything made with them arrives without the identity and security controls your Microsoft environment applies by default. When non-IT staff use them for work, those consumer products end up inside your enterprise, running on your data, without IT ever signing them off.
The risks of bringing a consumer-grade vibe-coded app into your environment are threefold.
- Ownership. The code lived in one employee’s personal repository. “If the guy doesn’t show up to work one day, where’s the code?” says Chris.
- Access. Five people could log in, and their usernames and passwords sat in plain text in the code. Anyone who could see the code could read those details or change them, and there was no real authentication behind them.
- Change control. There was no reliable record of what had changed, when, or who had approved it. Every update went straight from the employee’s laptop to production.
In this case, the app was scraping publicly available data, so the damage an intruder could do was limited. But point the same setup at member records, financial data or anything confidential, and those exposed logins become a far bigger problem. The next vibe-coded app your business builds may not be so harmless.
Moving a vibe-coded app into Azure DevOps, App Service, PostgreSQL and Entra ID
The work took a day. Here’s what we did.
First, we moved the code into the association’s Azure DevOps repository, so every future change would be tracked.
Next, we added branch policies to the main branch. Nobody can now push code to it without a pull request, and whoever submits a change can’t approve it. Someone else always has eyes on it.
We then set up an Azure App Service web app running Node.js, with an Azure Pipeline that deploys automatically from the repository. Deployments need approval before they go live.
For the data, we exported everything from the original database to CSV files, used AI to help write migration scripts, and loaded it into Azure Database for PostgreSQL. The two are similar enough that the app connected cleanly.
Finally, we replaced the hardcoded logins with Microsoft Entra ID, the same sign-in staff use for SharePoint and the rest of Microsoft 365.
The CIO now controls who has access and can add or remove people himself. We also moved the app onto the association’s own domain.
How the employee keeps vibe coding, and why saying no to shadow AI backfires
The research team still has the app, and the employee who built it still updates it by vibe coding. But now every change goes through a pull request, has a second reviewer, leaves a history and needs approval before deployment.
Shutting the app down would have been the simpler option for the CIO. It would also have sent the next project underground. “The alternative is they’re just going to do it and not tell you,” says Chris. “Then they’ll crank out amazing results, and you’ll be wondering how they got them.”
The relationship between the business and IT is changing. People used to raise a ticket and wait for IT to help. Now they arrive with something they built over the weekend and ask for it to go live on Monday, while your team is still tasked with keeping the lights on.
Move it or rebuild it? Deciding what to do with a vibe-coded app
This is the third time this year a client has brought us something a non-IT colleague built with AI, and we’ve also noticed AI-written scripts and workflows in clients tenants doing things they probably shouldn’t.
In August, we wrote about the first two apps (Send us your AI-built prototype. We’ll make it work on Microsoft 365). Both were static HTML files, polished on the surface, with the data frozen underneath. They were useful as briefs, and we rebuilt each one on Microsoft 365 foundations.
This latest example was the first full application, and close enough to keep, so we moved it and wrapped it in controls.
Part of our job is telling you which kind you’ve been handed. So, if you’re short on capacity or unsure what you’re looking at, send it to us.
Vibe coding and shadow AI: what IT leaders are asking us
Is it safe to deploy a vibe-coded app in our Microsoft environment?
Not until someone has reviewed it. A vibe-coded app can look finished in a demo and still have problems you’d only find by reading the code. Before anything goes near your tenant, find out who owns the code, how people sign in, where the data lives and who approves changes. If nobody can answer those questions, the app isn’t ready.
What should IT do when an employee hands over a vibe-coded app?
Work out what you’ve been given first. Some apps, like this one, are solid enough to move into your environment and wrap in controls. Others are static prototypes with frozen data, and those are better treated as a brief and rebuilt. Either way, find out what problem the employee was solving, because that’s usually worth keeping.
How can IT stay in control of vibe coding without shutting it down?
Put the controls around the code and let people keep building. Once an app lives in your repositories with an approval step before release, it matters much less who wrote the code, or what wrote it. For teams without developers to review changes, automated AI code reviews can flag security issues and explain each change in plain English.
How do we deal with shadow AI across the organization?
Give people a visible route in, and a safe tool to use. Banning AI tools tends to push the building out of sight, and you only find out when something breaks or someone asks you to host it. A simple policy works better: build with AI if you like, but use approved tools, tell IT and go through our release process. That brings shadow AI into the open while keeping the productivity gains.
Should we give employees Microsoft 365 Copilot instead of consumer AI tools?
For most day-to-day AI work, it’s the safer place to start. Microsoft 365 Copilot runs inside your tenant, works within each user’s existing permissions and inherits the governance you already have in place. It works on live data in your environment rather than an exported snapshot, and your admins decide which AI models are available, including models from OpenAI and Anthropic. Teams can also build their own agents in Copilot Studio with IT’s oversight. It won’t cover every scenario, and a full custom web app like this one still needs development discipline around it. But giving people an approved AI tool removes one of the biggest reasons they reach for a consumer one. We explain why we’re all in on Copilot in our guide for IT teams (We’re all in on Copilot. And if you run on Microsoft 365, you should be too).
Can someone help us deal with the vibe-coded apps landing on our desk?
Yes, Cloudwell can. We review vibe-coded apps and AI-built prototypes, tell you whether to move them or rebuild them, and make them secure and supportable in your Azure and Microsoft 365 environment. We can also help you set up the policies and guardrails that let your business keep building with AI while IT stays in control, and roll out Microsoft 365 Copilot so your people have an approved AI tool to build with. Contact us and send over what you’ve been handed.
***
Been handed a vibe-coded app to deploy? Contact Cloudwell. We’ll tell you whether to move it or rebuild it, and make it ready for the business to rely on.