Apps business teams build with AI without going through engineering

At one client I saw business teams build their own applications with AI, and then governance and security problems followed.

What business teams build with an agent is software, even if nobody calls it that, and it is governed like software: with controls inside the platform where it is built, a review that depends on the data it touches and an owner who stays put when its author changes roles. Setting that up is engineering's job, and the sooner the better.

How much is already built outside engineering

This way of working is called vibe coding: describing what you want in natural language, letting an agent write the code and keeping what works without reading it. It started among developers in a hurry, and people who have never programmed use it now.

Retool, which sells a platform for building internal tools, surveyed 817 people who build software at their companies in late 2025. 60% had built something outside IT oversight in the past year, and 25% do it frequently. Only 36% identified as engineers or developers; the rest came from operations, product, data, marketing, finance and other areas. And 51% already had something in production that their team uses.

The exact percentage matters less than the direction: in many companies, product and operations already build, with permission or without it, and what they build stays in use.

We have ended up using these solutions in two ways: as spikes, prototypes that engineering later refactors, or by providing cross-cutting tools that give these solutions their harness (the context the AI works in).

What changes compared with the old shadow AI

In July we wrote about shadow AI: people using AI tools without IT knowing. The main risk was data leaving the company through a conversation. With vibe coding something else appears: an application that runs, connects to company data and keeps working when its author has moved on to something else.

The Cloud Security Alliance describes it in a research note from June 2026. An application built from prompts may exist only as a deployed service, with no source code that can be retrieved, no dependency inventory (the third-party libraries it uses) and no record of which model or which prompt generated it. When a flaw turns up, the fix means prompting the AI again, because the team's own code to patch is missing.

Escape.tech, a security company, analysed more than 5,600 public applications built with vibe coding platforms in 2025. It found more than 2,000 vulnerabilities, more than 400 exposed secrets (access keys and credentials that should be hidden) and 175 instances of personal data in plain view. The scan was passive, from the outside and without breaking anything, and the authors present their figures as a lower bound.

The applications already exist. The useful question for a CTO is what their team puts underneath them so that the next one is born with controls and the one already running has an owner.

The four barriers, in this order

Lenny Zeltser, a security specialist, wrote in March 2026 that pre-approval gates fail when the people building don't go through engineering's workflows. His proposal and the CSA note agree on the basics: controls inside the tools people already use, and visibility to catch what slips through. Ordered by what is needed first, they look like this:

The inventory, before any policy

Without an inventory, every other barrier arrives late. Zeltser suggests it should capture what data each tool uses, where it runs, what permissions it has and who owns it, and that discovery should be automatic: waiting for each person to register their app leaves out precisely the ones that worry you most. The CSA adds a lightweight, non-punitive registration, meant to find out what exists before deciding anything.

The first inventory can come from the platforms the company already pays for: the note suggests starting with their governance dashboards, which list applications, authors and data connections. What you usually can't see from there are the integrations someone connects on their own, the same problem that MCP servers cause inside development teams.

The review, by data tier

The second barrier avoids the most common mistake: reviewing everything built outside engineering in the same way, which ends in a long queue that people learn to skip. The CSA note proposes three tiers. What we suggest for each is an example to adapt to each company:

• Internal tools with non-sensitive data: an entry in the inventory and automated checks, with no manual review.
• Applications with personal or regulated data: on top of that, a security review before opening them to more people.
• Applications that call AI services or act on their own, such as an agent that sends emails or changes records: an engineering review and permissions cut to the essentials.

The tier is set by the application's data and permissions. A spreadsheet that someone in finance turns into an app may be harmless or may read the payroll, and knowing who built it doesn't help tell the two apart.

The checks, inside the platform

Zeltser puts it in one practical sentence: people who aren't developers won't run security tools on their own, so those tools need to run without them. For an engineering team this is familiar ground. Secret scanning, dependency analysis and least-privilege permissions already live in its pipeline, the automated chain that checks every change before it is merged. What is new is putting them in the platform where business teams build and, where the platform doesn't allow it, requiring them from the vendor by contract, as the CSA recommends.

An example from the market: JPMorganChase has opened Claude Code to non-engineering teams, according to Anthropic on 9 November 2026. It does so in controlled environments on its own infrastructure, with thousands of automated tests and approval gates that check every change, and with an explicit rule: «Claude can't sign off on its own work». New models go through its internal approval process first. It is a bank with a bank's resources, but the order works at any size: first the environment and the checks, then access for more people.

Orphaned applications

Zeltser also points to the problem that takes longest to show: when the person who built the app changes roles or leaves, the app loses its owner. His proposal is simple. Record who built it and when it was last updated, so that someone can inherit it or retire it.

This is the barrier people forget most, because at first every application has an author. The problem shows up a year later, with the first reorganisation. An application that hasn't changed in months and whose author is now in another team is the first candidate for review: it keeps reading data and nobody looks at it.

What falls to the engineering team

I think the way forward is to build a corporate harness and context and to help business do it well. We are at the first moment in history when aligning business and IT is very simple.

Looking at the list, the four barriers ask for something engineering already knows how to do: build a platform with written rules and automated checks, and maintain it. It is the same thing the team needs when it works with coding agents itself, with the permissions and the context set up properly. What changes is who uses it.

That is why the CTO shouldn't hand it off as another area's compliance matter. People who build outside engineering need the same as a developer with an agent: a context with the company's rules and controls that stop what shouldn't get in. If engineering offers that and it is faster than setting it up alone, people use it.

With development teams, this is how we work: we deliver with method and improve with data, on top of the context your team builds with us: its rules, its product knowledge and automated checks.

Frequently asked questions

What is vibe coding?

It is building software by describing what you want in natural language and letting an AI agent write the code, often without reading it. Developers use it and, more and more, so do people in product, operations or finance who have never programmed.

How many people build applications outside IT oversight?

In a Retool survey of 817 people who build software at their companies, run in late 2025, 60% had built something outside IT oversight in the past year and 25% do it frequently. Retool sells a platform for building internal tools.

What risks do vibe-coded applications carry?

Escape.tech analysed more than 5,600 public applications built with these platforms and found more than 2,000 vulnerabilities, more than 400 exposed secrets and 175 instances of personal data in plain view. The Cloud Security Alliance adds that many have no retrievable source code and no record of the model that generated them.

How do you govern vibe coding in a company?

With four barriers, in this order: an automatic inventory of which applications exist and who owns them, a tiered review based on the data each application touches, automated checks for secrets, dependencies and permissions inside the platform, and a plan for applications left without an owner.

What is an orphaned application?

It is an application still in use after the person who built it has changed roles or left. It keeps reading data and nobody maintains it, so someone has to inherit it or retire it.

What role does the engineering team play?

Building and maintaining the platform the rest of the company builds on: written rules, automated checks and narrow permissions. They are the same elements the team needs when it works with coding agents itself.

Sources

• Kelsey McKeon (Retool), “The build vs. buy shift: how vibe coding and shadow IT have reshaped enterprise software”, 17 February 2026.
• Cloud Security Alliance (AI Safety Initiative), “The Vibe Coding Governance Gap”, research note, 2 June 2026.
• Nohé Hinniger-Foray, Gwendal Mognier and Alexandra Charikova (Escape.tech), “Methodology: How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platforms”, 29 October 2025.
• Lenny Zeltser, “Security Governance at the Speed of Vibe Coding”, 30 March 2026.
• Anthropic, “JPMorganChase expands Claude Code to more employees across the firm”, 9 November 2026 (case published by the vendor).