The Lovable Experience. Enterprise Governance. Your Infrastructure. We Built It.

Key points:

• AI coding tools (Lovable, Bolt.new, Replit) turned every employee into a developer. The productivity gains are real - and they're not going away
• In enterprise, these tools create a governance vacuum: code on shared vendor infrastructure, production data crossing compliance boundaries, no SSO, no audit trail, no deployment controls
• Banning doesn't work. It never has. 80% of employees already use shadow IT - AI just raised the stakes
• We solved this exact problem for cloud in 2016. The playbook is the same: make the governed path faster than the workaround
• We built the AI Builder Portal to run that playbook - same one-click builder experience, running on your Kubernetes cluster, under your governance

Last month, a CTO I work with told me something I've now heard from dozens of others: "I can't ban Lovable. The business value is too real. But I also can't let my finance team run apps on someone else's infrastructure with production data. So what do I do?"

Here's what he does.

But first, let me explain why the question exists in the first place - because if you haven't heard it yet, you will.

One of his finance analysts built a retention dashboard in twenty minutes. She used Lovable, connected it to the company's analytics database with an API key she found in a shared Notion doc, and shared the link with her team on Slack. It worked. The charts were accurate. Her manager loved it.

Nobody in engineering knew it existed.

The app was running on Lovable's shared infrastructure. The API key had read-write access to a production database. There was no SSO, no audit log, no access review. When he found out, he paused for a long time. Then he said: "I'm sure that's not the only one."

No sophisticated attack. No zero-day. Just an unsanctioned tool, an overpermissioned key, and a workforce that moved faster than governance could follow.

I've Seen This Exact Movie Before

I've been building cloud infrastructure for 15+ years. And I've seen this pattern play out before - almost scene for scene.

In 2014, developers at enterprise companies started spinning up AWS instances with personal credit cards. Why? Because the internal provisioning process took two weeks and three Jira tickets. Engineering needed infrastructure now, not in Q3. So they went around IT. They used their own accounts, their own configurations, their own security posture - which is to say, none.

IT leadership called it shadow IT. Security called it an existential risk. The developers called it getting work done.

The response wasn't to ban AWS. Companies that tried found their best engineers leaving for orgs that didn't. The response was to build internal developer platforms - service catalogs, IAM policies, cost controls, infrastructure guardrails, audit trails. Make the official path so fast and so frictionless that nobody has a reason to go around it.

The cloud didn't get safer because we blocked it. It got safer because we governed it.

Today, the same movie is replaying. But the actors changed. Instead of developers spinning up EC2 instances, it's marketing managers building full-stack apps on Lovable. Instead of ungoverned AWS accounts, it's ungoverned AI workspaces on vendor infrastructure. Instead of a blast radius limited to internal tooling, it's applications connected to production databases, CRMs, and customer data.

The actors changed. The plot didn't.

If you're a CTO, you've lived through the left column. You already know how the right column ends. The question is whether you get ahead of it or clean up after it.

Why AI Shadow IT Is Worse Than Cloud Shadow IT

The 2015 cloud shadow IT crisis was painful. But it had natural limits. Here's why the AI version doesn't.

The blast radius changed

In 2015, shadow cloud was a developer problem. You had maybe 200 engineers who might spin up rogue infrastructure. They understood security basics - most of them, anyway. The blast radius was contained: an unmanaged EC2 instance could leak data or run up a bill, but the person who created it generally knew what they were doing.

AI coding tools changed the population. It's no longer 200 engineers you can train on security practices. It's 2,000 employees across every department. The marketing manager building a dashboard has never heard of OWASP. The sales ops lead connecting a tool to Salesforce doesn't know what an OAuth scope is. The finance analyst pulling production data into a third-party platform doesn't understand data residency requirements.

The math is simple and brutal: more builders x less security awareness x direct access to production data = exponentially larger attack surface. And every single one of these apps is running on a vendor's shared infrastructure, outside your perimeter, outside your compliance boundary.

The tools are too good to ban

I want to be clear - banning AI coding tools is not the answer. The productivity gains are too real to ignore.

Last month, I built a full-stack app with Claude Code in about twenty minutes. That's not hype - that's a repeatable experience anyone can have today. A finance team that used to file a Jira ticket for a retention dashboard and wait six weeks for engineering to build it can now have a working version in an afternoon. A sales ops lead who maintained a pipeline report manually in spreadsheets can automate it in a few hours.

These aren't toy apps. They solve real business problems. And the people building them are not going back to filing tickets and waiting.

The numbers back this up. 80% of employees already use shadow IT. 41% have acquired, modified, or created technology without IT's knowledge. Banning has never worked when the workaround is faster than the official path. You don't win by making the fast path illegal. You win by making the safe path fast.

Here's the CTO's dilemma in three sentences. You can't say yes - compliance won't allow it. You can't say no - the business value is too real. And you can't pretend it's not happening - it already is.

What's missing from Lovable and Bolt.new for enterprise

Let me walk through what's actually missing when your team uses Lovable, Bolt.new, or Replit to build business applications. Not as a competitive teardown - as an honest inventory of what any enterprise CTO needs that these tools were never designed to provide. Call it the Enterprise AI Builder Checklist - every item below is table stakes, and none of them exist today.

No SSO or RBAC. Anyone with a login can access anything. There's no way to scope permissions per team, per project, or per data source. There's no SCIM provisioning. When someone leaves the company, their access doesn't get revoked automatically because it was never connected to your identity provider in the first place.

No audit trail. No record of who built what, when, connected to which data source, or who has access. Try answering those questions during a SOC 2 audit or a GDPR data subject access request. You can't. The data doesn't exist.

No data residency control. This is the one that kills deals in regulated industries. Code and data live on the vendor's shared infrastructure - typically in the US. For European companies subject to GDPR, for healthcare companies under HIPAA, for financial services under DORA - this is not a preference. It's a legal requirement you cannot satisfy. Your data must stay within defined jurisdictions, on infrastructure you control. Lovable and Bolt.new cannot give you that.

No deployment governance. A user can push an app to production with zero review. No staging environment. No approval workflow. No security scan. No way for an admin to even know it happened. In an enterprise where change management exists for good reasons, this is a non-starter.

No cost visibility. No way to allocate compute costs per team, set spending limits, or even inventory what's running. Finance can't forecast it. Procurement can't manage it. You're flying blind. We've seen per-engineer costs hitting $500 to $2,000 per month with zero accountability.

No IP ownership clarity. When employees build applications on third-party platforms, the code lives on those platforms. Terms of service vary, and in an enterprise context, the question of who owns what is a legal problem your general counsel will not enjoy discovering.

These aren't feature requests. These are table stakes for any tool that touches production data in an enterprise. None of the current AI builders were designed to provide them. They were designed for individual makers building side projects - not for organizations building on production data.

The Answer Is Not Less AI. It's Governed AI Coding Tools.

The cloud didn't get safer when companies blocked AWS. It got safer when internal platforms made the secure path the easy path. Same principle applies here.

Here's the insight most people miss: non-technical builders don't care where their apps run. They care about the experience - one-click setup, no configuration, instant preview, easy publish. They don't care whether it runs on Lovable's servers or yours. So give them the exact same experience, on infrastructure you control. Make the governed path feel indistinguishable from the ungoverned one.

Don't ban the builders. Give them a platform they actually want to use.

What We Built: An AI Builder Platform for Enterprise

This is why we built the AI Builder Portal - a self-service platform where platform engineers define governed blueprint environments and anyone in the organization, technical or not, spins up a one-click AI workspace on the company's own Kubernetes cluster. One-click workspaces with built-in AI coding tools - the builder experience of Lovable, running on your infrastructure, under your governance. (full documentation)

01. One-click workspaces from blueprints

Platform engineers define blueprint environments tailored to each team. Finance gets a blueprint with access to the analytics database. Sales gets one with CRM credentials pre-configured. Marketing gets the content management API. A builder picks a blueprint, clicks Create, and gets a fully configured workspace in under four minutes. No Docker. No CLI. No Kubernetes knowledge required.

02. Built-in AI coding tools

Every workspace ships with Claude Code in the terminal and an OpenCode chat panel. The builder describes what they want, the AI writes and iterates the code. Same experience as Lovable or Bolt. But the AI conversation never leaves your infrastructure.

03. Live preview with viewport switching

Builders see their running application in the browser as they work - desktop, tablet, mobile. Instant feedback loop. No deployment step needed during development.

04. Publish with approval workflows

When a builder is ready to go live, they submit a publish request with a subdomain. An admin reviews and approves before anything goes to production. No more apps going live without anyone knowing.

05. Blueprint access control

Restrict which blueprints are available to which users - by email, domain, or role. Marketing sees the content management blueprint. Finance sees the analytics blueprint. Nobody gets access to production databases unless you explicitly grant it.

06. Your infrastructure, your compliance posture

Workspaces run as containers on your Kubernetes cluster. Source code, AI conversations, application data - none of it ever leaves your perimeter. No inbound ports on your cluster. Terminal sessions and previews are streamed in real-time through a cluster-initiated outbound tunnel. When the session ends, nothing is recorded on our side.

Your workspaces inherit whatever compliance posture your cluster already has - SOC 2, HIPAA, GDPR, DORA.

Your code never leaves. Your AI conversations never leave. Your data never leaves. The only thing that crosses the boundary is the pixels on the screen.

07. Agent governance - monitor, enforce, kill

This is where it gets serious. Every AI agent request inside a workspace flows through a governance proxy that classifies it in real-time - API calls, bash commands, file writes, git pushes, HTTP requests to external domains. You set the policy per classification: auto-approve safe actions, require admin approval for destructive ones, auto-deny anything that touches a blocked domain. Three modes: off (no interception), monitor (log everything, block nothing), enforce (active policy enforcement). Built-in content filters catch leaked API keys, private certificates, and exfiltration attempts. And if something goes wrong - a kill switch that immediately blocks all agent traffic, org-wide or per-blueprint. Admins see everything in real-time via a live monitoring feed.

08. Fully customizable portal and workspaces

The portal is white-labeled to your brand - custom logo (light and dark mode), primary color, portal name. Your team sees your identity, not ours. Workspaces are equally configurable: define custom tab layouts per blueprint (terminal tabs, AI chat tabs, custom commands), lock the layout for non-technical users who don't need a raw terminal, configure which preview ports are available, and set default AI models per blueprint. You can even restrict code-server access entirely for blueprints designed for pure AI-assisted building. Every blueprint can feel like a purpose-built tool for its audience.

09. Resource policies and cost control

Set guardrails at the org level and override per blueprint. Max concurrent running workspaces per user (default: 2). Auto-stop after inactivity (configurable hours). Max lifetime so no workspace runs forever. Auto-cleanup of stopped workspaces after a configurable number of days. Built-in LLM token usage tracking via RTK shows you exactly how many tokens each workspace, blueprint, and user are consuming - with savings analytics so you can see what prompt caching is actually saving you. No more flying blind on AI compute costs.

10. Centralized admin dashboard

One screen to see everything. An infrastructure topology graph shows the full hierarchy: clusters, blueprints, workspaces, owners, states. An activity timeline shows who created, started, stopped, or deleted workspaces - with running and active session segments. A security dashboard surfaces active connections, firewall blocks, and which blueprints have public access enabled. Member management with invite, remove, and per-project access grants. IP firewall with CIDR-based allowlisting and blocked access logging. You don't need to ask what's happening in your org. You see it.

Every gap from the Enterprise AI Builder Checklist - SSO, audit trail, data residency, deployment governance, cost visibility, agent governance - is addressed. Not because we added checkboxes. Because the architecture was designed around governance from the start.

Lovable vs AI Builder Portal: the enterprise comparison

For the full technical breakdown of the security model, read Don't Ban the Builders - Govern Them. For a complete overview of capabilities, see the Remote Dev Environments solution page.