An Orca Security Executive Built a Partner Platform in a Weekend With AI

Shannon McWilliams built the first working version of Orca Security's Partner Success Platform over a single weekend — without being a developer. McWilliams, Head of Global Distribution at Orca Security, used AI development tools to produce a prototype that eventually moved into production after a security review and independent outside verification.

Orca Security sells a cloud security platform that helps organizations discover assets, prioritize risks, and protect cloud environments, covering vulnerabilities, misconfigurations, identities and permissions, sensitive data, and AI security. McWilliams joined the company to look at the overall partner experience. Orca was using a third-party partner portal at the time.

"I had some application development experience, but not as a developer myself," McWilliams said in an interview with Unite.AI. He had founded a software development company earlier in his career and had spent the prior summer working on consumer applications on a third-party app-generation platform.

What did the weekend prototype actually do?

The first version went beyond what traditional partner portals offered. It included AI-driven capabilities such as ideal customer matching and deal coaching. Over time the team added more applications: certification tracking, AI-generated quizzes, and a gamified certification process for partners, plus data synchronization with Orca's Salesforce platform.

The turning point came when Orca's CEO saw the initial version and recognized its potential. Work then shifted from experimentation to making the platform secure and production-ready. McWilliams worked closely with Dudi Peretz and the security team to secure the environment before an outside firm independently verified the work.

How fast is AI-assisted development?

Speed was the biggest difference from traditional development. McWilliams describes the old process: an idea, technical requirements, developers, iteration. With AI, he could describe what he wanted and refine it almost immediately.

"With AI development, that takes a 2 sentence prompt, not 2 days of meetings," he said. Tasks like data analysis that once took weeks can now potentially be finished in a day.

But speed did not remove the need for expertise. It changed where that expertise matters. The person directing the AI still needs to understand the business problem, what a useful experience looks like, and what the application must accomplish.

"That speed is both amazing and a little terrifying," McWilliams said.

What did the security review uncover?

The AI development platform's own security tooling indicated the application was secure. Orca's subsequent review found issues involving permissions and data access anyway.

"That was probably one of my biggest lessons from the experience," McWilliams said. The platform's built-in scanning gave a helpful baseline, but the deeper review showed the value of added scrutiny around permissions and data access. He concluded that built-in security tooling works best alongside a dedicated security team's context and expertise.

The stakes are high because many people who can now build applications with AI are not security experts. They may not know what questions to ask, which permissions are too broad, or which configurations could expose data. The platform declaring an application secure cannot be the end of the process, he argued; a comprehensive review is still needed before an application connects to sensitive enterprise systems.

Can remediation become a continuous loop?

When Peretz and the security team flagged issues, McWilliams fed the findings back into the AI development environment and generated fixes within minutes. That creates a tighter feedback loop between builder and security team.

But he drew a firm line on validation. AI can generate a fix quickly; security teams still need a way to verify that the fix addressed the risk and did not introduce a new one.

Where do humans stay in charge?

The Partner Success Platform now includes AI assistants, pipeline intelligence, campaign generation, and deal coaching. McWilliams said the goal was not to remove humans from the partner or sales process. AI pulls information from disparate systems, analyzes relevance, and presents it in a form the user can act on. The human remains accountable for decisions requiring business judgment. The stated aim: compress the time from deal discovery to closed/won through platform engagement.

What governance does citizen development need?

McWilliams laid out minimum controls before AI-built applications touch customer data or internal systems:

• Visibility first — an organization cannot secure an application it does not know exists.
• Encouraging innovation makes employees bring projects forward rather than stay in the shadows.
• Review the application's identities, permissions, data access, and third-party connections, and confirm those privileges are necessary.
• Apply least privilege — applications often receive broader access than they need.
• Reassess continuously, since applications that change constantly cannot be checked once before launch.

Traditional governance built around pull requests, release cycles, and controlled pipelines will not suffice when someone can publish changes every day, he said. Security must discover what is being built, understand its configuration, scan it as it changes, and give builders actionable feedback.

Is this shadow IT, but worse?

McWilliams compared AI-built applications to a harder version of shadow IT. Traditional shadow IT meant employees adopting an unapproved SaaS tool. Now employees can create the application themselves, through a personal account, integrated with third-party systems and potentially connected to enterprise data before security knows it exists.

Discovery therefore has to become a core part of security strategy. Registering projects, he suggested, is a practical way to accomplish it. Organizations need visibility into applications running across the environment, their identities and permissions, the data they access, and the external systems they communicate with.

Looking ahead, McWilliams expects the definition of "software builder" to broaden. Professional developers will not disappear; they will focus on more complex technical problems. Security teams will build the visibility and guardrails that let new builders innovate safely. Builders, he noted, are not always the best maintainers — long-term support still belongs to IT and application organizations. Business leaders, in turn, must treat software risk as part of the business, not something owned solely by engineering.