The 'Claudish' Code Base: Governing the Apps Your Employees Build

The short answer

Managing employee-built AI apps means treating them like real software assets, not rogue side projects. That starts with finding them, classifying them by the data they touch, applying baseline security controls automatically, and assigning a named owner to every app before it touches production data. You do not need to ban the tools. You need to catch up to what employees are already doing with them.

The problem is not the AI, it is the invisibility

A year and a half ago, "vibe coding" was a tweet. OpenAI co-founder Andrej Karpathy coined the term in February 2025 to describe writing software by describing intent in plain language and letting the model handle the code.¹ It caught on fast enough that Collins Dictionary named it word of the year within months.¹ Even Karpathy now says the code these tools produce can be "bloaty," full of "awkward abstractions that are brittle," and still needs a human checking the aesthetics and the judgment calls underneath it.

That brittleness is not a rumor. Veracode tested over 100 large language models across 80 programming tasks and found that 45% of AI-generated code samples failed security tests, introducing OWASP Top 10 vulnerabilities.² Cross-site scripting failures ran especially high, and newer, more capable models did not meaningfully improve the pass rate.² That is the software your employees are shipping without ever calling it software.

Meanwhile, employees are not waiting for permission. Microsoft and LinkedIn's 2024 Work Trend Index, based on a survey of 31,000 people across 31 countries, found 78% of AI users bring their own AI tools to work, a practice they call BYOAI, and it climbs to 80% at small and midsize companies.³ Most of this activity is invisible to the people responsible for securing it. IBM's 2025 Cost of a Data Breach Report found that organizations with high shadow AI usage paid an average of $670,000 more per breach than those with low or no shadow AI, and 97% of AI-related breaches involved organizations that lacked proper AI access controls.⁴

Why these apps break differently than old shadow IT

Classic shadow IT was a rogue spreadsheet or an unsanctioned SaaS trial. Employee-built AI apps are a different category of risk because the employee who built the app usually cannot read the code inside it, and the underlying model can change out from under them without warning.

A researcher scan of production vibe-coded applications found that zero out of 5,600 apps surveyed had CSRF protection, security headers, or properly scoped access policies.⁵ Common failure patterns repeat across studies: hardcoded API keys sitting in plain source, databases and admin dashboards left public by default, and no audit trail of who touched what.⁶ None of the major AI security frameworks currently in use, including NIST AI RMF, OWASP's LLM Top 10, or the Cloud Security Alliance's own frameworks, provide dedicated guidance for the citizen developer who builds and deploys these apps without any security background.⁵

Then there is the ownership problem. When the employee who built the app changes roles or leaves, the app has no maintainer. Unlike SaaS, where a vendor is contractually on the hook for patches and uptime, a vibe-coded internal tool just sits there, quietly accumulating technical debt, until it breaks something the business depends on.⁷ Add in unmanaged hosting on platforms IT never vetted, and you have software running in production that nobody signed off on and nobody is watching.

What actually works: a four-part governance model

Security teams that have gotten ahead of this are not running a ban-and-block program. They are running an inventory-and-tier program, and the sequence matters.

1. Discover before you write policy. You cannot govern what you cannot see. Run discovery across the major building platforms, Lovable, Replit, Bolt, Cursor, and Netlify are common ones, and add their domains to your data loss prevention monitoring so sensitive data leaving the perimeter gets logged, even if you are not blocking it yet.⁸

2. Classify by what the app touches, not who built it. A dashboard pulling public marketing numbers needs a lighter touch than a tool that processes customer PII or connects to a production database. Tier the review requirement to the data and the infrastructure, not to whether the builder has "developer" in their title.⁷

3. Assign a named owner to every app, permanently. Track who built it and when it was last touched. Build a trigger so that when that person changes roles or leaves, someone is forced to inherit the app or formally retire it, rather than letting it drift into orphaned status.⁷

4. Automate the parts a non-developer will never run themselves. Secret scanning, dependency checks, and scoped access tokens instead of broad API keys need to be built into the platforms people already use to build these apps. Nobody should be expected to run a security scanner manually before publishing an internal tool. That control needs to be invisible and automatic, or it will not happen at all.⁷

One encouraging data point: when organizations actually provision sanctioned, well-governed AI tools for employees to use, unauthorized shadow use of unsanctioned alternatives drops by 89%. The highest-leverage move is not detection and blocking. It is giving people a good, approved way to build the thing they were going to build anyway.

Governance snapshot

A few numbers worth keeping on the wall when you're making the case for a governance program internally.

When the app graduates from prototype to real software

The honest line to draw is this: once an employee-built app is load-bearing for a business process, touches customer data, or gets used by more than the person who built it, it stops being a personal experiment and becomes an asset the company owns and is accountable for, whether IT signed off on it or not. That is the same logic that applies to any internally built tool worth keeping around long-term, which is why more teams are starting to treat their AI-assisted internal apps the way they'd treat any owned system rather than a rented one, an approach platforms like Remy are built around: giving internal software a real home with ownership, versioning, and access control attached, instead of letting it live as an orphaned link in a Slack channel.

The goal is not to slow employees down. It is to make sure the fast thing they built on Tuesday is still safe to run in six months, with someone's name on it.