The End of the App Catalog: Why Legacy CASB Can't Survive the Vibe Code Era

There's a question that every CISO should be asking their CASB vendor right now, and it's a simple one: What happens when your employees start uploading sensitive data to an application that didn't exist five minutes ago?

If the answer involves waiting for a signature update, a database refresh, or an API integration — that's not a security strategy. That's a hope strategy.

And hope doesn't stop data loss.

The world your CASB was built for no longer exists

The Cloud Access Security Broker was one of the most important security innovations of the last decade. It gave enterprises visibility and control over cloud application usage at a time when employees were rapidly adopting SaaS tools without IT approval. The CASB model worked because it rested on a reasonable assumption: the universe of cloud applications was large but finite, and a vendor could build and maintain a catalog of known applications, map their APIs, assess their risk, and give security teams the controls they needed.

That assumption is no longer valid.

The rise of vibe coding — where non-developers use generative AI tools like Cursor, Replit, Bolt, and Lovable to build fully functional web applications through natural language prompts — has shattered the foundation that legacy CASB was built on. An employee, a contractor, or anyone with a browser can now describe what they want and have a working cloud application with file upload capability, form inputs, data sharing features, and user authentication deployed to a public URL.

Not months. Not weeks. Minutes.

And every single one of these applications is a potential vector for sensitive data to leave the enterprise.

The math doesn't work anymore

Consider what the legacy CASB model requires. A vendor must discover a new application, add it to their catalog, categorize its risk, and potentially build an API integration to provide granular control. Even the most aggressive CASB vendors measure this cycle in days or weeks. The best-known CASB catalogs top out around 50,000–60,000 applications, maintained through a combination of automated crawling and manual analyst review.

Now consider the other side of the equation. Replit alone reports millions of applications created on its platform. Vercel, Netlify, and similar deployment platforms host applications that are being spun up continuously. New AI coding tools are launching monthly, each lowering the barrier to application creation further. GitHub reports that AI-assisted development has gone from experimental to mainstream in under two years.

The result is a rate-of-creation problem that no catalog-based approach can solve. It's not that the catalogs are too small — it's that the concept of a catalog is architecturally incompatible with a world where applications are disposable, ephemeral, and created faster than they can be counted.

And this isn't a future problem. It's happening right now, in every enterprise, whether security teams can see it or not.

The API security gap

The problem gets worse when you look at how modern CASB solutions actually enforce policy. Many of the most granular controls — tenant restrictions, in-app activity monitoring, detailed file sharing policies — depend on API integrations with known cloud platforms. The vendor works with Microsoft, Google, Salesforce, Box, and other major SaaS providers to build API connectors that enable deep visibility and control.

This model works well for the top 50 or 100 enterprise SaaS platforms. It fails completely for vibe-coded applications.

When an employee builds a file-sharing tool using AI and deploys it in ten minutes, there is no API to connect to. There is no vendor to partner with. There is no documentation to review. The application exists, it accepts file uploads, and if an employee decides to use it to transfer a sensitive document, a CASB that depends on API integrations has zero visibility and zero control.

The question isn't whether your CASB vendor has a big enough database. The question is whether your security architecture can protect against an application that has no database entry and no API — because that's the application your data is going to leak through.

Shadow IT just became shadow everything

For years, security teams have managed shadow IT as a containable problem. Employees adopt Dropbox, or start using an unsanctioned project management tool, or sign up for a new AI chat service. The CASB detects it through traffic analysis, categorizes the risk, and security teams decide whether to block, allow, or monitor.

That workflow assumed a discoverable, categorizable set of applications. Vibe-coded applications break this model in three ways.

First, the volume is unmanageable. When any employee can create a new application on demand, the number of unknown destinations for corporate data isn't growing linearly — it's growing exponentially.

Second, the velocity defeats signature-based detection. By the time a legacy CASB vendor adds a vibe-coded application to their catalog, the data may already be gone — or the application itself may no longer exist, replaced by a newer version that was vibe-coded from scratch.

Third, the variety is unprecedented. Vibe-coded applications don't follow predictable patterns. They can be built with any framework, hosted on any platform, and designed with any interface. Traditional heuristics for identifying application types based on known patterns break down when every application is a unique creation.

Embedded AI is the threat you can't see

There's another dimension to this challenge that gets less attention but may be even more dangerous: AI capabilities are being embedded into existing applications without explicit disclosure or visibility.

When a productivity tool adds an AI assistant, or a note-taking application integrates with a language model, or a code editor starts sending prompts to a cloud AI service — these create data pathways that traditional CASB monitoring cannot see. The employee isn't visiting a new application. They're using the same tool they've always used. But now that tool is quietly sending data to AI models through embedded API calls that bypass the security controls designed for the application's original functionality.

This means the threat surface isn't just new applications — it's also familiar applications that have changed what they do with your data.

The architectural question

The legacy CASB model — built on application catalogs, signature databases, and API integrations — was a brilliant solution to the cloud security challenge of 2015. It is not equipped for the challenge of 2026.

The enterprises that will successfully navigate the vibe code era are the ones asking the right architectural questions:

• Can our security controls protect against an application we've never seen before? Not block it — control it. Can we disable file uploads, restrict form submissions, prevent data sharing, and enforce DLP on an application that doesn't exist in any catalog?

• Does our security architecture depend on API integrations with known platforms? If so, what percentage of our data loss risk is flowing through applications that have no API to connect to?

• Can we detect AI capabilities embedded in existing tools? Not just standalone AI platforms like ChatGPT and Copilot — but AI functionality hidden inside the business applications our employees already use?

• Is our CASB signatureless? Can it identify and assess risk for any application through behavioral analysis, or does it require a known signature to function?

• Are our security signals unified? Can a single AI engine correlate signals from inline traffic, API analysis, and endpoint telemetry to provide complete risk assessment — or are we running fragmented tools that each see a partial picture?

The answers to these questions will determine which organizations can adopt AI confidently and which will spend the next three years chasing data loss incidents they never saw coming.

What comes next

The CASB isn't dead — but the CASB as we've known it is fundamentally insufficient for what's coming. The next generation of cloud application security needs to operate without prior knowledge of the application, without API dependencies, and without signature databases. It needs to protect from the network to the app — reading, understanding, and controlling application behavior in real time, regardless of when or how the application was created.

At RSA Conference 2026, iboss is addressing this challenge head on. We believe the industry needs a fundamentally different approach — one where AI isn't just a feature bolted onto legacy architecture but the foundation of how cloud application security works.

The era of the app catalog is over. The question is what replaces it.

iboss will be at RSA Conference 2026, March 23–26 at Moscone Center in San Francisco. Learn more about iboss at RSAC 2026 →

For more on iboss AI-Powered SASE, visit iboss.com/casb