Retool Blog | How to govern AI-generated apps in the enterprise

2025 was the year of vibe coding. Almost overnight, workers who’d never written a line of code were shipping sophisticated prototypes that felt like magic.

That gap—between what AI can generate and what an enterprise can actually deploy—is the most important unsolved problem in software right now.

The answer is architectural. Governance needs to live at the resource layer, not the app layer. This post explains why app-level security breaks down when anyone can generate an app in five minutes, and what IT and security teams need to put in place instead.

At the heart of this disconnect is that a functional app a business user ships with AI is fundamentally not the same as a production-ready internal tool that can scale securely across a business. What they see looks like an app, but the hard part starts when the app they generated needs to connect to a real database, touch customer data, or run inside an environment with compliance requirements.

Who decides what data this app can access? Who reviews the security model? Who’s responsible when an LLM-generated app with overly permissive IAM roles quietly starts leaking data?

The answer at most organizations today is nobody. Because most AI-generated apps never go through the process that answers those questions. They either sit in a sandbox forever, get rebuilt from scratch by an engineer, or they increasingly get pushed to production without any governance review at all.

When anyone can generate an app, the accountability chain that enterprise security depends on disappears.

Enterprise software has always had a simple trust model: a known developer writes code, that code gets reviewed, and the reviewed code gets deployed with explicit permissions.

AI-generated code inverts every part of that model.

Now, the builder might not be a developer. The code might not get reviewed, because the happy path works, teams can’t possibly review code faster than it is being generated. And the permissions? It’s easier to test that it works than it is to verify it is secure.

David Mytton, CEO of developer security provider Arcjet, predicts that the steady buildout of vibe-coded apps into production will lead to “big explosions”. He argues that AI should implement validated security patterns, not invent security from scratch. But that’s exactly what happens when every generated app ships with its own bespoke security logic.

The traditional approach to securing internal tools is app-level governance. Each app defines its own permissions: who can see what, who can edit what, what data it can access. The app is the security boundary.

This model worked when a company had dozens of internal apps, each built by an engineering team over weeks or months. There was time to get the permissions right. There were human experts accountable for each decision.

It doesn’t work when anyone in the organization can generate an app in five minutes.

If you secure at the app level, then whoever generates the app is also generating the security rules. When the builder is an LLM acting on a natural-language prompt, the security rules are whatever the LLM decides they should be. As Samsung SmartThings executive Nikhil Jain wrote in Forbes: “AI can generate code. It does not automatically generate governance.”

Think about what this means at scale. An enterprise with 500 business users, each capable of generating apps with AI, is an enterprise with 500 potential sources of ungoverned data access. Each app has its own security logic. Each one is a potential misconfiguration. And there’s no central place to see what’s been built, what data it touches, or whether any of it is safe.

Governance doesn’t fail because organizations lack the right process. It fails because process is the wrong solution. However, the instinct in most organizations is to respond to this increased risk with processes: review boards, approval workflows, security checklists. And those are fine, but only for the apps that go through the process. The problem is that AI-generated apps are multiplying faster than any review board can absorb. A procedural response to an architectural problem is a losing game.

The alternative is to move governance underneath the app layer. Instead of each app defining its own permissions, permissions live with the data. The app doesn’t decide what it can access, the platform does. A generated app can be as insecure as the LLM wants to make it, and it still can’t touch data it shouldn’t, because the security boundary is in the infrastructure the app runs on, no longer relying purely on application code.

When governance lives at the resource level—meaning the governance is enforced by the platform, not by the individual app—it doesn’t matter who built the app, what tool generated it, or whether anyone reviewed the code. The security model is independent of the app layer.

Moving from app-level to resource-level governance changes several things:

The real risk of AI-generated apps isn’t that they’re insecure in isolation. It’s that they’re invisible. When generation is easy and deployment is ungoverned, apps proliferate outside IT’s awareness. Resource-level governance, by definition, makes all data access visible because there’s only one path to the data.

Right now, every AI coding tool and app builder is focused on making generation faster. A ton of companies are already solving the code creation problem. None of them are solving the governance problem.

That’s the architectural problem Retool is building to solve. We’re building for a future where governance doesn’t degrade as AI gets better. In Retool, governance is automatic and resource-level, so any app running on the platform—whether built by an engineer or generated by a prompt—operates within the same security boundary.