Shadow Builders: When Employees Ship Production Apps Without Auth

Vibe-coded internal tools are graduating to public URLs, and most identity stacks never see them coming.

ThreatVectr Newsdesk· 3 min read
Shadow Builders: When Employees Ship Production Apps Without Auth
Share

Shadow AI used to be a copy-paste problem. Someone pastes a customer list into a chatbot, Security writes a memo, life goes on.

That era is over.

The new shape of the problem is employees using AI to build entire applications — frontends, backends, database connections — and quietly publishing them to the open internet. The artifact stopped being a prompt. It became a product. And the identity perimeter around it is usually nonexistent.

A recent industry scan flagged roughly 2,000 of these vibe-coded apps exposed publicly, many wired into production systems with credentials hardcoded or fronted by nothing more than a guessable URL. Security and IT were not in the loop on any of them.

That is the part worth dwelling on. Not the volume. The auth posture.

These apps tend to skip the boring parts of IAM entirely. No SSO integration, no OIDC flow, no group-scoped authorization checks. Many ship with an API key embedded in client-side JavaScript, which is roughly equivalent to taping your house key to the front door. Others rely on "unguessable" subdomains as their sole access control — security through obscurity, a model RFC 3552 explicitly warns against in its threat-model guidance.

Would MFA have helped? Honestly, no. You cannot enforce a second factor on an endpoint that never asked for a first one.

The authz story is worse than the auth story. Even when a vibe-coded app does check a password, it almost never distinguishes between users at the row level. Anyone who gets in sees everything the service account can see. The blast radius is the entire downstream system — typically a production database or a SaaS API key with admin scope.

Traditional CASB and SSE tooling miss this category because the apps are not SaaS in the procurement sense. There is no vendor, no contract, no OAuth consent screen to inspect. The app is hosted on a developer platform the employee signed up for with a personal email. From the network's perspective, it looks like outbound traffic to a generic PaaS.

A few practical things that actually move the needle:

  • Egress monitoring for known vibe-coding and AI app-builder platforms, treated as a category rather than a per-vendor allowlist.
  • Mandatory SSO enforcement at the database and API-key layer, so a rogue frontend cannot bypass identity by holding a long-lived credential.

The deeper issue is that the people building these apps are not adversaries. They are employees trying to ship faster than IT can approve a Jira ticket. The fix is not a stern email. It is giving them a sanctioned path with identity baked in by default, and then watching the egress for the ones who go around it anyway.

The perimeter moved. The IAM stack has not caught up.

© 2026 Threat Vectr