Shannon McWilliams, Head of Global Distribution at Orca Security – Interview Series

Shannon McWilliams is Head of Global Distribution at Orca Security, where his work spans the company’s partner ecosystem and the tools that support it. Having previously founded a software development company, he brings experience translating business needs into applications. More recently, he used AI development tools to build an early version of Orca’s Partner Success Platform, working with the security team to take the project from a weekend prototype toward a production-ready system.

Orca Security provides a cloud security platform that helps organizations discover assets, identify and prioritize risks, and protect cloud environments. Its capabilities cover areas including vulnerabilities, misconfigurations, identities and permissions, sensitive data, and AI security. In this interview, McWilliams discusses how AI is enabling business users to build software, why working applications still need independent security scrutiny, and how continuous discovery, least privilege, and human oversight can help enterprises manage this new development model.

You joined Orca Security as Head of Global Distribution and, within a matter of months, ended up building a new partner platform yourself using AI. What problem were you initially trying to solve, and when did the project evolve from an experiment into something Orca could actually put into production?

When I joined Orca, one of the things I was asked to look at was the overall partner experience. We were using a third-party platform, but I saw an opportunity to create something more modern and streamlined for our partners. I had some application development experience, but not as a developer myself. I had worked on consumer applications earlier that summer on a third party app gen platform provider, so I decided to experiment with what I could build myself using AI.

Over the course of a weekend, I was able to create a basic first version of what became our Partner Success Platform, with functionality that went beyond what I was seeing in traditional partner portals, including AI-driven capabilities like ideal customer matching and deal coaching. We added many more applications within the platform, like certification tracking, AI generated quizzes and gamified the entire certification process for our partners, then began to sync data with our Salesforce platform. The turning point came when our CEO saw the initial version and recognized its potential. That’s also when we moved from experimentation toward asking what it would actually take to make something like this secure and production-ready. Our security team became involved, and I started working closely with Dudi Peretz to secure the environment before ultimately having that work independently verified by an outside firm.

You previously founded a software development company, so you have experience with how applications were traditionally built. How did building software through natural-language AI compare with managing developers, and where did your own domain expertise still matter most?

The biggest difference was speed. With traditional software development, there are typically multiple steps between having an idea, translating it into technical requirements, having developers build it and then iterating on the result. With AI, I could describe what I wanted, see it take shape and continue refining it almost immediately. The iteration process takes minutes instead of days of meetings with developers, defining the desired UI and all the database mapping to create the functionality. With AI development, that takes a 2 sentence prompt, not 2 days of meetings.

But that doesn’t eliminate the need for expertise. It changes where that expertise matters. AI can dramatically lower the technical barrier to building an application, but the person directing it still needs to understand the problem they are trying to solve, what a useful experience looks like and what the application ultimately needs to accomplish for the business. What surprised me most was how quickly you could go from an idea to something functional. Tasks like analyzing data that once could have taken weeks can now potentially be accomplished in a day.

Orca has described the first working version of the partner platform as something you built over a single weekend. What could AI accelerate dramatically, and what parts of building a production-ready application remained more difficult than they initially appeared?

AI dramatically compressed the distance between an idea and a working application. I could build functionality over a weekend that traditionally would have required a much longer development process, and I could continue adding and changing features extremely quickly. That speed is both amazing and a little terrifying.

What AI did not eliminate was everything required to make an application safe for production. Once we decided this could become something real, our security team needed to assess the environment, address security issues and make sure the application was appropriately secured. We ultimately brought in an outside firm as another layer of validation. So AI made building incredibly fast, but “it works” and “it is ready to safely operate in an enterprise” are still two very different thresholds.

The AI development platform’s own security tooling indicated that the application was secure, yet Orca’s subsequent review uncovered issues involving permissions and data access. What did that experience teach you about how much trust business users should place in the security assurances provided by AI development platforms?

That was probably one of my biggest lessons from the experience. The platform had its own security scanning capabilities, which provided a helpful baseline as I was building. But going through the review process with our security team showed me the value of adding another layer of scrutiny, particularly around areas like permissions and data access. It reinforced that built-in security tooling is an important part of the development process, but it works best alongside the deeper context and expertise a dedicated security team can bring.

That’s especially important because many of the people who can now build applications with AI aren’t security experts. They may not know what questions to ask, what permissions are too broad or what configurations could expose data. The development platform telling you an application is secure can’t be the end of the process. Before an application is published or connected to sensitive enterprise systems, it still needs a comprehensive security review that looks beyond whether the application simply passes the platform’s own checks.

When the security team identified vulnerabilities, you were often able to feed those findings back into the AI development environment and generate fixes within minutes. Could AI fundamentally change security remediation from a lengthy development cycle into a continuous conversation between builders and security teams?

This is one of the most exciting possibilities. When Dudi and the security team identified issues, I could take that feedback, put it directly into the AI development environment and have fixes generated extremely quickly. That creates the potential for a much tighter feedback loop between the person building an application and the team responsible for securing it.

Historically, software might be built and released over a much longer period of time. Now, someone can make and publish changes every day. Security has to operate at that same speed. The opportunity is to make continuous security assessment part of the development process, so you can identify an issue, communicate it back to the builder, remediate it and reassess the application much more quickly.

But speed of remediation doesn’t mean we can lower the bar for validation. AI can generate a fix quickly; security teams still need a way to verify that the fix actually addressed the risk and didn’t introduce another one.

The resulting Partner Success Platform incorporates AI assistants, pipeline intelligence, campaign generation, and deal coaching. How did you determine which activities AI should handle directly and which decisions should remain with the human partner or salesperson?

For me, the goal wasn’t to remove the human from the partner or sales process. It was to use AI to help people move faster and make better use of the information already available to them. Deal coaching is a good example: AI can help identify ways to progress an opportunity that has been sitting in the pipeline and give someone additional context or a recommended next step.

Where I think the distinction becomes important is between AI having the ability to quickly pull information from disparate systems, analyze its relevance and then put it in a form that the user can then take action on. The platform should make the partner or salesperson more effective, while the human remains accountable for the decisions that require business judgment. The goal is to compress the time from deal discovery to closed/won through platform engagement.

AI is making it possible for employees in sales, marketing, finance, and other departments to build their own applications without going through engineering. What minimum security and governance controls should be in place before those applications are allowed to connect to customer data, internal systems, or cloud infrastructure?

The first requirement is visibility. While the organization policies should encourage this type of exploration and innovation, it can’t secure an application it doesn’t know exists – so encouraging innovation is more likely to see employees bring their projects forward, rather than stay in the shadows. From there, organizations need to understand what identities and permissions the application has, what data it can access, what third-party systems it communicates with and whether those privileges are actually necessary. Pave the way for innovation to sprout, but have a process that supports the innovators and meets the security requirements.

Least privilege becomes particularly important. One of the risks we see is applications receiving broader access than they actually need. And security can’t be a one-time check before launch. When applications can change continuously, organizations need the ability to reassess them continuously as well.

Traditional software governance was designed around engineering teams, pull requests, release cycles, and relatively controlled deployment pipelines. If business users can now modify and deploy applications continuously, how does the enterprise software development lifecycle need to change?

The fundamental challenge is that the cadence has changed. Traditionally, software was built and released over time through relatively established processes. With AI development tools, someone can potentially make and publish something new every day. Security and governance processes built around periodic checkpoints aren’t going to be enough in that environment.

We need to move toward security that operates continuously and can keep pace with that development cycle. That means discovering what’s being built, understanding how it is configured and connected, scanning it as it changes and giving builders actionable feedback they can incorporate quickly. The answer can’t be stopping employees from using these tools; the productivity opportunity is too significant. The challenge is creating guardrails that allow that innovation to happen safely.

You have compared the rise of AI-built applications to an even more difficult version of “shadow IT.” What makes this generation of shadow software potentially more challenging, and how can organizations discover applications that security or IT teams may not even know exist?

Traditional shadow IT was often about employees adopting a SaaS application that IT hadn’t approved. What’s different now is that employees can create the application themselves, and they can do it incredibly quickly. Someone can build an application through a personal account, integrate it with third-party systems and potentially connect it to enterprise data before security even knows it exists.

That’s what makes this particularly challenging: building has become so easy that the number of applications and the speed at which they change can quickly outpace traditional governance. CISOs are confronting the same basic question: how do you secure something when you may not even know what has been built or how it is configured?

Discovery therefore has to become a core part of the security strategy. Supporting the innovators, encouraging them to explore, but register their projects is a great way to accomplish discovery. Organizations need visibility not only into code, but into the applications running across their environment, the identities and permissions associated with them, the data they’re accessing and the external systems they’re communicating with.

Looking several years ahead, do you expect most knowledge workers to become some form of software builder through AI? If so, how does that change the roles of professional developers, security teams, and business leaders inside the enterprise?

We’re moving toward a world where the definition of a “software builder” becomes much broader. AI is making it possible for people who understand a business problem but aren’t traditional developers to turn an idea into a working application incredibly quickly. I experienced that firsthand.

I don’t think that makes professional developers or security teams less important. It changes where their expertise is needed. Business users can increasingly build solutions themselves, while developers can focus on more complex technical problems and security teams have to create the visibility and guardrails that allow this new generation of builders to innovate safely. Application support and maintenance also takes on a new perspective. “Builders” are not always the best “Maintainers”. They bring the vision and the business need, but supporting an application long term is still a task best suited to IT and Application organizations. For business leaders, it creates tremendous opportunity, but also new responsibility. If your teams can create software, you need to think about software risk as part of the business—not simply something that belongs to engineering.

Thank you for the great interview, readers who wish to learn more about cloud security, AI-built applications, and securing enterprise environments should visit Orca Security.