What 2,000 Exposed Vibe‑Coded Apps Reveal About the Limits of Most Security Stacks
#Regulation

What 2,000 Exposed Vibe‑Coded Apps Reveal About the Limits of Most Security Stacks

Security Reporter
4 min read

A new Red Access report shows more than 2,000 AI‑generated web apps exposing corporate data on public URLs. The findings expose blind spots in traditional EDR, DLP, CASB and firewall layers, and outline a session‑layer approach to discover and govern “shadow builders” before they become a breach vector.

What 2,000 Exposed Vibe‑Coded Apps Reveal About the Limits of Most Security Stacks

Featured image

Published by The Hacker News – May 29 2026

The alarm bell

Red Access’ Shadow Builders report uncovered 380 000 publicly reachable assets on leading “vibe‑coding” platforms, and 2 000+ of those hosted sensitive corporate, operational, or personal data. In many cases the URLs granted admin‑level access to anyone who discovered them. The apps spanned six continents, touched every industry, and passed internal audits while exposing data to the open internet.

“These aren’t rogue actors; they’re employees solving real problems faster than IT can provision tools,” says Dr. Maya Patel, senior research analyst at the Center for Applied Cybersecurity. “What we’re seeing is a governance gap, not a technology failure.”

The phenomenon is a step beyond classic Shadow IT. Instead of a SaaS subscription that lives inside a vendor’s perimeter, a vibe‑coded app is a custom‑built web service that talks directly to production systems (CRMs, ERPs, BI tools) and is often published on a public sub‑domain with little or no access control.


Why existing stacks miss the problem

Control What it sees What it misses
EDR Browser process, user interaction The build‑and‑publish workflow that happens entirely inside a browser tab, even on personal devices
DLP Clipboard, file uploads, known AI chat endpoints Programmatic API calls from a vibe‑coded app to a corporate BI system
CASB SaaS vendor identities Thousands of distinct custom apps that all resolve to the same vendor domain
Firewall / SSE Traffic to the platform’s domain The application‑as‑business‑object context – i.e., which corporate system is being called, what data is flowing

All of these tools are operating adjacent to the real attack surface. The session layer—the browser tab where the user describes the app, authorizes OAuth grants, and clicks Publish—is where the entire risk chain lives. Because the session can originate on any device (corporate laptop, contractor’s personal machine, BYOD), traditional endpoint‑centric controls simply never see the full picture.

“Think of the session as a single, auditable transaction,” notes Liam O’Connor, product lead for Red Access’ session‑layer platform. “If you only watch the edges, you’ll miss the payload moving right through the middle.”


Practical steps you can take this week

1. Start with a human‑centric discovery

  • Send a company‑wide prompt asking anyone who has built a tool on an AI‑development platform to register it. Frame the request as an inventory, not an audit, to encourage honest participation.
  • Use a lightweight form that captures:
    • Platform name (e.g., Bubble, Retool, Power Apps AI)
    • Public URL (if any)
    • Connected corporate systems (OAuth, API key, manual upload)
    • Data categories handled (PII, financial, operational)

2. Map the exposure surface

  • For each reported app, verify:
    • Whether the URL is publicly reachable (simple curl -I test or URL‑scanner tool)
    • The authentication mechanism used to connect to internal systems
    • The least‑privilege scope of any OAuth token
  • Prioritize remediation on any app that:
    • Exposes admin or write privileges
    • Connects to high‑value systems (ERP, CRM, BI)
    • Is reachable without authentication

3. Define a sanctioned pathway

  • Publish an internal policy that approves specific vibe‑coding platforms and sets minimum security defaults (e.g., mandatory authentication, no anonymous public URLs, token‑scoping).
  • Provide a “fast‑track” request process so builders can get official approval without lengthy gatekeeping. Lower friction reduces the incentive to go rogue.

4. Deploy session‑layer visibility

  • Implement a solution that inspects browser‑session events regardless of device ownership. Red Access offers an agentless, SSE‑grade platform that captures:
    • The moment a user authorizes an OAuth grant
    • The publish click that creates the public endpoint
    • The data flow between the custom app and corporate APIs
  • Because it works at the network‑edge and the browser level, it sees activity from personal laptops, contractor devices, and even unmanaged mobile browsers.

“Continuous discovery at the session layer is the only way to keep up with the velocity of AI‑assisted development,” says Patel. “You can’t rely on quarterly scans when a new app can be built in minutes.”


Longer‑term outlook

  • Platform vendors are beginning to tighten defaults (e.g., auto‑generated passwords, mandatory auth for public URLs). Keep an eye on release notes for Bubble, Retool, and Microsoft Power Apps AI.
  • Zero‑trust architectures will need to extend trust decisions to application instances rather than just domains or users.
  • Policy automation – integrating session‑layer telemetry with IAM and SOAR platforms can automatically quarantine a newly published app that violates the public‑URL rule.

Until those capabilities become mainstream, the most effective defense is a human‑first inventory combined with session‑layer monitoring. The risk is real, but it is also manageable with the right blend of awareness, policy, and visibility.


Red Access’ session‑layer platform is available for a free audit. Request it here.

Comments

Loading comments...