The layers of app governance: Why not all "security" claims are equal

On the surface, it’s hard to tell the difference between most AI-powered app builders. Given the same prompt, they’ll all produce a similar quality of application. And when it comes to security and governance, they all offer very similar features. The gap isn't in what they say—it's in where governance actually lives when the app is running.

Or so they say. AI app builders tend to describe security the same way—enterprise ready, prompt to production, SOC 2, governed—but the realities of the product are structurally different. One tool's “governed” means the workspace is locked down. Another means every app that deploys inherits enforced permissions automatically. Those aren't the same thing.

AI app security isn't a yes-or-no thing. It's a ladder, and most tools sit lower on that ladder than they let on. Most tools would lead you to believe they have higher levels of security—that it’s enforced by the platform on every request—but many rely on whoever creates the app to write it into the app itself. In this piece, we’ll map the layers of application security (or rungs) so you can understand where any tool sits before you trust it with real data.

Why real AI app security is a runtime property, not a feature

Platform compliance and governance aren't the same thing—one describes the vendor's own systems, the other what your app enforces at runtime.

A platform can be compliant with SOC 2 Type II (opens in a new tab), ISO 27001 (opens in a new tab), PCI DSS (opens in a new tab), TISAX (opens in a new tab), even HIPAA, but that doesn't mean the apps it generates are covered by any of it. Once deployed, a generated app can still have no platform-enforced authentication until a developer wires it up—its API routes are open to anyone with the URL. Some of the most compliant vendors in the category produce some of the least governed apps.

One caveat: this framework scores tools on a single dimension—what a deployed app inherits automatically from the platform, without any additional developer effort. An IDE or hosting platform scores low here by design. That's not a knock on those tools—it's what they're built for. The question this piece answers is different: Once your app is running, what security or governance does the platform guarantee?

The gap between what leaders want and what they have is real. In Retool's 2026 State of AI Governance report of 300+ CIOs, CTOs, and CISOs, 55% of these leaders said access controls should sit in a centralized platform, yet only 24% govern at that level today. The other 76% are relying on developers to get it right, every time, in every app.

The six capabilities that define application governance

Each of these first five capabilities describes where a control lives. The progression runs from weakest to strongest: absent entirely, written into the app by whoever built it, offered by the platform as an option, or enforced by the platform on every request.

The sixth dimension, compliance and data residency, works differently. A lower-tier tool can still beat a higher-tier one on certifications or signed compliance agreements. That matters, but it doesn't move the tier.

One rule applies across all six: a tool's tier is set by its weakest critical control. One unauthenticated endpoint undoes a wall of good ones.

1.
Authentication and access control. The bar isn't whether a platform offers auth—most do. It's whether auth is enforced automatically on every deployed app, or written into the app by whoever built it. SSO should be enforceable, local passwords disableable, and RBAC should govern what users can access in the data, not just who can edit in the builder.
2.
Secrets handling. Credentials should live server-side and be injected at request time—never in client-reachable code or browser-exposed variables. If a secret can reach the frontend, it can leak.
3.
Data and resource governance. This is the biggest architectural difference between tiers. Either the app queries your production database directly, making security whatever the developer wrote—or every request passes through a managed layer where credentials, permissions, and query behavior are centrally controlled.
4.
Audit logging. Logging should be on by default and capture reads, not just writes. Retention length matters here, too. 90 days won't cover a 12-month audit period on its own. SIEM streaming or scheduled exports can close that gap.
5.
Deployment controls. Environment separation, source control with mandatory review, and approval gates that stop any change—human-written or AI-generated—from reaching production unseen.
6.
Compliance and data residency. Start with the certs and signed agreements—SOC 2, ISO 27001, a HIPAA BAA. Just know that a BAA is something you need for HIPAA compliance, not compliance itself, and that a vendor being certified doesn't mean the app you build on it is. Then there's where the data lives: their cloud, or your own VPC.

The four layers (or rungs) of AI app security

Put the dimensions together and tools cluster into four tiers.

Level 0: Unguarded. Protects against: nothing meaningful; obscurity is the only control. Key gap: anyone with the URL. Use it for: prototypes, demos, and throwaway tools—never production.
Level 1: Self-secured. Protects against: casual access and common OWASP issues, if built correctly. Key gap: inconsistency and decay—no central answer to "who can see what?" Use it for: disciplined teams with few apps.
Level 2: Platform-assisted. Protects against: unauthorized platform access, sprawl, and invisible changes. Key gap: the seam between platform governance and the app's own data layer. Use it for: lower-sensitivity apps with limited blast radius.
Level 3: Governed by default. Protects against: many Level 0–2 failures, and limits the blast radius of human error. Key gap: misconfiguration and over-granted permissions. Use it for: production, customer, or regulated data.

Level 0: Unguarded

This is what an AI tool hands you the moment it finishes: raw output from a prompt. It runs, it demos beautifully, and authentication is optional or absent—credentials often in client-reachable code, direct database access, no audit trail. That's fine for prototypes and throwaway tools (or the app I vibe-coded for a weekly potluck with my friends where everyone lists what they’re bringing) but going from Level 0 to production would be a huge mistake.

In May 2026, the security firm RedAccess told Axios (opens in a new tab) and WIRED (opens in a new tab) it had found roughly 380,000 publicly accessible apps built with vibe-coding tools. More than 5,000 had virtually no authentication, and roughly 2,000 appeared to be actively exposing sensitive data—medical records, financial information, internal documents—to anyone who typed the right URL. Axios verified several were live. Months earlier, an Escape.tech scan of 5,600 vibe-coded apps turned up more than 2,000 high-impact vulnerabilities and over 400 exposed secrets.

If you're a security leader, that is the real cost of Level 0 at scale. The answer isn't banning these tools—that's how shadow IT starts. The answer is giving teams an approved place to build where governance is built into the platform, so apps land at Level 3 for production use, not Level 0 by default.

The risks of vibe coding: Why AI tools break down in production

By Will Harris

Getting started

Build with AI

Level 1: Self-secured

One rung up, a developer has secured the app by hand: auth from a library, secrets in env vars, some logging. It handles casual access and the obvious Open Worldwide Application Security Project (OWASP) issues if implemented correctly.

What it doesn't handle is inconsistency and decay. Every app is its own one-off, and there's no central answer to "who can see customer data." Offboarding means auditing app by app, and controls are only as current as the last person who touched them. Fine for disciplined teams with few apps, but labor-intensive and far from scalable.

This is also the ceiling for an IDE or a hosting platform on its own. Neither adds governance, so an app that relies on them alone tops out here—or at Level 0, if no one secures it by hand—until it moves onto a platform that does.

Level 2: Platform-assisted

Now the platform provides some governance features, like SSO, RBAC, audit logs, security scanning. The critical limitation: that governance protects the platform and workspace, while the app's own data layer stays your responsibility.

Take Lovable. It enforces role-based access, ships enterprise audit logs, and scans on every publish—but generated apps run on a Supabase backend whose Row Level Security policies you configure.

Replit is similar. It ships built-in auth for generated apps and holds SOC 2 Type II—but who can reach a deployed app's stored secrets still comes down to how the workspace is configured.

In both cases, platform governance is real, it just doesn’t extend to the app’s data. For apps whose data isn't sensitive enough to make that seam dangerous, Level 2 is a sensible fit. For production apps touching customer data, regulated information, or sensitive systems, the seam is exactly where the risk lives.

Level 3: Governed by default

At the top of the ladder, governance stops being something the developer remembers—it's a property of the runtime itself. Auth is enforced before the app renders. Credentials live server-side, RBAC governs the app's data, audit logging is on by default, and risky changes route through approval before they execute.

Even an insecurely written app still can't exceed what the platform permits. The practical result: the blast radius of human error is bounded. A misconfigured policy can still cause harm, but a Level 3 platform limits how much damage any single mistake can do.

This isn’t to say Level 3 is perfect – misconfiguration and over-granted permissions remain real risks. But it’s the safest path to production for any app touching sensitive data, and the only tier where governance holds regardless of who or what wrote the code.

Retool occupies this tier, but we’re not the only ones. Microsoft Power Apps clears the same bar on Dataverse, whose server-side security roles enforce role-, row-, and column-level access independent of the app's code—though non-Dataverse sources fall back on their own controls – a meaningful caveat for organizations with diverse data stacks outside the Microsoft ecosystem.

Power Apps also has an edge in regulated industries: Microsoft signs a HIPAA BAA covering Power Platform, and Retool doesn't. Self-hosted Appsmith meets the Level 3 bar on its Business and Enterprise plans, with granular RBAC over its data connections—though its free Community edition offers only predefined roles, not custom per-datasource permissions – so the tier designation applies to specific plan levels, not the product across the board.

How to evaluate a tool (the checklist)

You don't need to run through this whole framework on a vendor call. A tool's tier reveals itself through a handful of pointed questions—the ones where Level 2 and Level 3 answer differently, and where "secure" marketing goes quiet:

Is authentication enforced by the platform before the app loads, or written into the app?
Does RBAC govern the app's underlying data, or only who can edit in the builder?
Where do credentials live—and can they ever reach the browser?
Does the app connect directly to production databases, or through a managed layer you control centrally?
Is audit logging on by default, does it capture reads, and can it stream to your SIEM?
Can a change reach production without a second person reviewing it?
Which governance features are gated behind the enterprise tier? (Frequently: nearly all of them.)
Cloud-only, or can you self-hose in your own VPC?
Will the vendor sign the compliance paperwork you need?
Which certifications cover the vendor, and which extend to the apps you deploy in their platform?

Answer these with "the platform does that automatically," and you're near the top of the ladder. Answer them with "your developer handles that" and you know which rung you're on—and what you'll own.

How Retool approaches AI app security

The LLM that generates your app shouldn't also be trusted to write its security. At Level 3, the AI layer is fenced in by the platform – not the prompt, thus governance holds regardless of what model produces.

During a build, the agent sees only what the builder is permitted to see—schemas of authorized resources (table and column names, type definitions) plus a limited set of build-time signals like truncated query results—and can't reach outside that boundary, even if asked.
Any code the agent writes is analyzed before it can run, and rejected if it references a resource the builder isn’t authorized to access.
Functions execute server-side under the builder's authenticated session, with the same permission checks Retool applies to any other request from that user.
Reads run automatically. Any insert, update, or delete is surfaced for human approval first. DROP TABLE and DROP DATABASE are blocked outright. New packages require explicit approval, must be at least five days old on npm, and must carry an approved open-source license.

There's a hard line between building and running. Once an app is published, it executes directly against your resources. No runtime data passes through an LLM—your production data stays in your environment, not in a model's context window. That's the Level 3 test in practice—the agent can try to generate the most insecure app in the world, and it still can't do anything the platform doesn't already allow.

Underneath the AI layer is the governance every Level 3 platform needs, enforced by the platform, not the app:

Enforced auth and SSO: SAML and OIDC across major identity providers, with the option to disable password login entirely.
Resource-level RBAC: permissions govern who can query each connected resource. For PostgreSQL resources specifically, Retool adds table-, column-, and row-level access policies (Enterprise plan, currently in public beta), defined centrally and enforced on every query—whether it comes from an app, the query library, raw SQL, or an agent.
Server-side secrets: never exposed to the frontend, with HashiCorp Vault and AWS Secrets Manager for self-hosted deployments and runtime injection so you rotate without redeploying.
A governed data layer: every app reaches data through a centrally managed resource layer—credentials server-side, backend logic out of the browser, no direct database connections from client code.
Audit and deployment controls: automatic logging with one-year cloud retention and Datadog/Splunk streaming on Enterprise; source control across GitHub, GitLab, Bitbucket, and Azure Repos, with branch-based development, separate staging and production environments, and deployment gates.
Audit Logging: on by default, capturing reads and writes, with one-year cloud retention and Datadog/Splunk streaming on Enterprise plans.
Deployment Controls: source control across GitHub, GitLab, Bitbucket, and Azure Repos—with branch-based development, separate staging and production environments, and approval gates before any change reaches production.
Compliance and residency: SOC 2 Type II, ISO/IEC 27001:2022, GDPR and CCPA. Self-hosting in your own VPC for data residency requirements.

You don’t have to build in Retool to run an app in Retool. Bring apps from Claude Code or Cursor over an MCP server, import existing React apps, or build natively. Whatever produced the code, it lands on the same governed foundation.

Choosing an AI app builder you can actually govern

Every tool here will tell you it's secure, and most are telling a partial truth. The vendor is audited, the platform is sound, the workspace is locked down. What that rarely covers is the app you're about to ship—whether its authentication is enforced or optional, whether its permissions live with your data or in code an LLM wrote, whether one bad line can reach production unseen.

That's why governance is a spectrum, not a checkbox. Secure describes a moment—governed describes what holds when the developer moves on, the app changes, and the next thing gets generated by a tool nobody reviewed.

Decide how much of your security you'll leave to whoever—or whatever—wrote the code. Match that to the sensitivity of the data it touches. Then ask the checklist questions until each has a real answer. The tool that keeps answering "the platform handles that" is the one you can actually govern.

That tool exists. On Retool, apps inherit governance by default: prompt one natively, bring it over from Cursor or Claude Code, or write it by hand, and authentication, access, and secrets are enforced by the runtime, not left to whoever wrote the code. See how Retool governs AI-generated apps.

Last assessed September 2026. These tools change monthly; verify current capabilities before relying on any specific claim here.