Dominic Jainy stands at the intersection of emerging technology and enterprise resilience, bringing a wealth of experience in artificial intelligence and blockchain to the complex world of infrastructure security. With organizations increasingly caught in the crosshairs of automated attacks, Jainy’s perspective on the shift toward unified control planes offers a blueprint for navigating the fragmented multi-cloud landscape. As the industry moves away from reactive monitoring, his insights shed light on how global enterprises are finally bridging the gap between high-level security intent and the granular, native enforcement required to protect modern digital assets.
The following discussion explores the evolution of “security-by-design,” the operational hurdles of managing live production environments across diverse providers like AWS and Azure, and the strategic importance of embedding automated controls directly into the cloud fabric.
Managing security across diverse providers often involves navigating fragmented identity models and service catalogs. How do you translate high-level security intent into specific configurations for platforms like AWS and Azure, and what steps ensure these policies remain consistent as multi-cloud environments evolve?
Translating security intent is fundamentally about abstracting complexity so that a single policy can live across AWS, Azure, Google Cloud, and Oracle Cloud Infrastructure without losing its effectiveness. We start by defining a unified policy layer where the security team sets the “intent”—such as strict identity isolation—and then the platform programmatically maps that to the specific APIs and identity models of each provider. This is critical because a policy that works in an AWS account might look completely different in an Azure subscription, yet the security outcome must be identical. To ensure these stay consistent as environments evolve, the system must continuously monitor the state of the infrastructure and re-apply the intended configuration if drift occurs. By using a centralized control plane, we eliminate the manual toil of logging into four different consoles, which is where most human errors and security gaps are born.
With the window between vulnerability discovery and exploitation shrinking to nearly zero, reactive detection is becoming less effective. Why is the industry shifting toward preventative security-by-design, and how can teams embed controls directly into infrastructure rather than layering them on as separate tools?
The industry is hitting a breaking point because Mandiant research shows the average time-to-exploit reached “minus one day” in 2024, meaning attackers are hitting flaws before a patch is even a glimmer in a defender’s eye. We are shifting to preventative security-by-design because waiting for an alert from a monitoring tool is essentially waiting to be told you’ve already lost. To embed controls directly, teams must move away from third-party agents and instead leverage the cloud provider’s own native enforcement mechanisms, like Security Groups or Service Control Policies. This approach ensures that the security is baked into the “unit of work” itself, making the infrastructure inherently resistant to unauthorized changes. When security is native to the architecture, it doesn’t just watch for a fire; it ensures the building is made of non-combustible material from the start.
Modifying security configurations in live production environments carries significant operational risks, such as breaking business applications. What specific strategies, like pre-deployment simulations or controlled rollout methods, can organizations use to safely update enforcement controls without disrupting critical services or workflows?
The fear of “breaking the business” is the number one reason why many security policies remain unimplemented, leaving companies vulnerable. To mitigate this, we utilize pre-deployment impact simulations that analyze how a change in a network or identity policy will affect existing traffic patterns and application permissions before it goes live. Beyond simulation, we employ controlled rollout methods and integrated approval workflows that allow for a “canary” style deployment of security configurations. This means a change might be applied to a single non-critical project first, monitored for issues, and then graduated to the rest of the Fortune 100-scale estate. By having these safety nets in place, security leaders can confidently enforce strict architectures at speed without the constant threat of a production outage.
Many organizations struggle to balance provider-native tools with third-party security services. How does utilizing a cloud provider’s own internal enforcement mechanisms change the overall security architecture, and what are the primary advantages of this approach compared to traditional third-party monitoring and detection?
Utilizing internal enforcement mechanisms transforms the architecture from a “detect and respond” model to an “enforce and prevent” model. Traditional third-party tools often sit outside the traffic flow, acting as a set of eyes that can only yell for help after a breach has begun. By contrast, using a cloud provider’s native tools—the very ones AWS and Azure spend billions to develop—means the security is part of the cloud fabric, creating a zero-latency barrier. The primary advantage here is reliability; you aren’t relying on a third-party agent that might crash or be bypassed. Furthermore, it simplifies the stack, allowing organizations to raise the security bar while actually moving faster because the “checks” are happening at the infrastructure level rather than through a secondary, external bottleneck.
Building a technical team with deep experience from major cloud providers and security vendors brings a unique perspective to infrastructure. How does that background influence the development of a security control plane, and what metrics should leadership prioritize to measure the success of an automated enforcement strategy?
Our background—having led teams for services like AWS GuardDuty and AWS Security Hub—instilled a deep respect for the scale and volatility of cloud environments. We understand that a security tool is useless if it cannot handle the sheer volume of a global enterprise with dozens of accounts and thousands of microservices. This experience led us to build a platform that focuses on “intent” rather than just another list of findings, because we’ve seen firsthand how “alert fatigue” kills security programs. For leadership, the primary metric of success should be the “time to enforcement”—how long it takes from identifying a required policy to having it active across all clouds. Additionally, tracking the reduction in “misconfiguration drift” provides a tangible sense of how well the automated control plane is maintaining the integrity of the environment.
What is your forecast for the future of multi-cloud security control planes?
I believe we are entering an era where the concept of “finding” a security problem will become obsolete, replaced entirely by automated architectural enforcement. In the next few years, as Native grows its team from 41 to 90 employees by 2026, the focus will shift toward AI-driven intent translation that anticipates threats before they manifest. We will see the “false choice” between speed and security disappear as these control planes become so seamless that developers don’t even realize they are operating within a hardened framework. Ultimately, the successful organizations will be those that stop treating security as an add-on and start treating it as the foundational operating system of their multi-cloud strategy.