Introducing The Builder Exchange: Inside Security Stories From the Companies Building Fastest With AI

Why the industry needs The Builder Exchange

Software development traditionally ran through a narrow channel that involved a defined set of engineers, pipelines, and a review process security could have control over. That model worked because building took experience and effort to execute.

Now, AI app generators let anyone in an organization describe an app and ship it to production in an afternoon. The speed at which AI has enabled citizen developers, software builders who don’t have an engineering background, creates structural tension. Now, the population capable of shipping software has expanded, while the security model built to review that software still needs to evolve. The traditional model still assumes a ticket, a pipeline, a person in the loop. None of those exist when someone in sales builds a customer portal over a weekend.

Security leaders aren’t short on frameworks or best practices for AI risk at a high level. In fact, many of them know that it exists. What’s harder to find is the specific, on-the-ground account of how this plays out inside a real organization: how was the app created, was security included in the product stage? And, what processes were implemented to prevent further risk?

The Builder Exchange is Orca’s flagship virtual event featuring original security research and real stories from leaders and practitioners tackling the risks of AI-generated software built by non-engineers and outside traditional security review. Orca is proudly hosting this event to bring together experts and practitioners who face the same challenge in order to push security forward through community building and story sharing.

What challenges does The Builder Exchange Address?

Who is building

Builders at an organization are more than just an engineering team now. Citizen developers stretch across the business and don’t think about securing systems when they are developing, often optimizing for a working app, not a secure one. Without a strong engineering background they have little insight on the importance of authentication, access controls, or data exposure. 

Where the app lives

These apps run on the vendor’s infrastructure, not the company’s. The code repo might be yours, but the data plane, the secrets store, and the runtime environment belong to a platform you don’t control and likely don’t monitor. The number of platforms a security team now has to account for has gone from a handful of cloud providers to 50-plus AI AppGen vendors.

What ships by default

More than 78% of organizations have applications running with critical vulnerabilities. Even years after disclosure, high-impact issues like Log4Shell continue to affect nearly half of production environments, highlighting how traditional AppSec approaches struggle to keep pace with dependency sprawl.

Why standard security responses aren’t enough

The intuitive fix is to add more visibility tooling: another platform to catch what’s slipping through. That assumption is worth challenging directly. CNAPP, AppSec, and SSPM tools, the three categories security teams already rely on for cloud and application visibility, all share the same dependency. Each one needs someone to point at the thing before it can secure it: a cloud account connected, a repo pointed to a scanner, a SaaS app added to an inventory.

CNAPP platforms cover cloud accounts a team has provisioned. AppSec tools scan repos someone has connected. SSPM checks the configuration of platforms already integrated into the stack. Each is a strong answer to a narrower problem: securing what’s already known. None of them solve for discovery, because none of them are built to find what nobody reported.

That dependency exists because these tools were built around a single owner who does the connecting. AI-generated apps break that model at the source. The agent or builder that made the app, the models it uses, the database it stores PII in, the hosting service, and the cloud resources it runs on. No single team owns all of these. Risk concentrates in the handoffs between them, and each handoff looks like somebody else’s job. With no single owner to report the app, it never reaches the tools that require reporting to work. Finding it requires an architecture built to discover this type of risk, rather than start from a list of known, connected assets and works inward.

How The Builder Exchange is closing the gap

The four problems outlined above, who’s building, where the apps live, what ships by default, and who’s accountable, all trace back to the same root cause: software that never touches a system built to see it. That’s an architecture problem, and Orca’s agentless discovery model is built specifically to solve it, extending the same approach that’s covered cloud infrastructure to the AI-generated apps now shipping alongside it.

The Builder Exchange is where that theory meets practice. It’s a chance to hear directly from the security leaders and practitioners navigating this in production environments right now, not just a framework for what should work in principle. If your organization is shipping AI-generated apps faster than security can track them, this is where you’ll hear how other teams are catching up.