Dominic Jainy is a seasoned IT professional whose career has been defined by his ability to bridge the gap between complex emerging technologies and practical enterprise application. With a specialized focus on artificial intelligence and cloud infrastructure, he has spent years helping organizations navigate the shift from manual scripting to autonomous operations. In this interview, Jainy offers a deep dive into the current state of infrastructure governance, exploring how the latest advancements in cloud management platforms are enabling a new era of AI-driven automation without sacrificing security or control.
The following discussion explores the critical role of standardized protocols in managing AI agents and the necessity of refining role-based access to empower junior staff while offloading senior engineers. Jainy also examines the often-overlooked challenges of “day-two” operations—such as resizing and decommissioning resources—and provides a strategic perspective on maintaining unified governance as enterprises migrate toward a more diverse array of virtualization and “neocloud” alternatives.
Integrating the Model Context Protocol allows AI agents to act as conversational interfaces for infrastructure. How does this protocol ensure that an AI-driven request follows existing policy checks, and what specific steps should teams take to audit these autonomous actions to maintain accountability?
The brilliance of integrating the Model Context Protocol (MCP) lies in its ability to separate the conversational intelligence of an AI from the actual execution of infrastructure changes. Instead of giving an AI agent unrestricted access to your cloud environment, the protocol allows it to interact with a management platform that serves as a strictly governed execution layer. When an AI assistant requests to provision a new cluster or run a post-deployment task, the platform treats that request exactly like a human-triggered action, subjecting it to the same role-based permissions and policy checks. To maintain true accountability, teams must ensure that every AI-driven interaction is tied back to a clear identity and recorded in a centralized audit trail. This means that if an agent asks to see which actions are available for a specific user role, the platform doesn’t just provide a generic list; it provides a contextual response based on the actual guardrails in place, ensuring that the AI can never overstep the bounds of the user it is assisting.
Senior engineers often handle routine tickets because granting task-specific access historically required broad administrative rights. How can organizations safely decouple these operational tasks from platform administration, and what metrics indicate that a self-service model is successfully reducing the burden on senior staff?
For too long, we have been trapped in a binary world where you were either a regular user with no power or a “super-admin” with the keys to the kingdom. By moving toward a model where we can expose specific, narrowly defined actions to certain users without extending wider administrative rights, we fundamentally change the operational dynamic of the team. For example, a lower-tier operator can be given the right to restart a specific service or resize a storage volume without ever seeing the back-end configuration of the entire management platform. A successful transition to this self-service model is usually measured by a sharp decline in routine ticket volume for senior staff and a reduction in the “mean time to resolution” for simple operational requests. When your highly paid architects are no longer spending 30% of their day clicking “approve” on basic resource requests, you know the decoupling strategy is working and that your internal platform team is maturing.
Infrastructure management often stalls after initial provisioning when resizing, updating, or decommissioning resources. What are the primary hurdles in automating these day-two operations, and how do structured workflows and custom forms prevent configuration drift during the later stages of a resource’s lifecycle?
The primary hurdle in day-two operations is that the lifecycle of a resource is messy and unpredictable compared to the clean slate of initial provisioning. While spinning up a VM is a standard task, knowing exactly when to resize it, how to apply a critical update without downtime, or when it is safe to decommission it requires a deep understanding of the ongoing workload. Structured workflows and custom forms bridge this gap by turning these specialist procedures into repeatable, governed processes that can be presented to different user groups. By forcing these changes through a structured interface, you prevent “configuration drift,” where manual, undocumented tweaks lead to a fragmented and unmanageable environment. Using these tools to handle tasks like remediating policy violations or restarting services ensures that every change follows a pre-approved template, keeping the state of the infrastructure consistent from the first day to the last.
Recent market shifts have prompted many enterprises to integrate alternatives like OpenShift Virtualization, Hyper-V, or neoclouds. How can teams maintain unified governance across such a fragmented estate, and what practical steps ensure that seeking provider “optionality” does not lead to unmanageable operational complexity?
The shift away from a single-provider model, particularly following major market events like the Broadcom acquisition of VMware, has made optionality a top priority for CIOs. To maintain unified governance, organizations must adopt a management platform that acts as a universal resource handler, capable of orchestrating across everything from Azure Local and Oracle Linux Virtualization Manager to emerging “neoclouds” like CoreWeave, Nebius, and Vultr. The practical step to avoid complexity is to ensure that the governance layer is abstracted from the underlying infrastructure; the policy for “who can deploy a database” should be the same whether it’s going onto a SUSE Virtualization cluster or an OpenShift environment. By focusing on a heterogeneous orchestration model, teams can test and adopt new platforms without having to rewrite their entire operational handbook or retrain their staff on ten different management consoles.
When connecting AI assistants to an execution layer for infrastructure provisioning, what are the most common security “blind spots” teams encounter? How can organizations balance the need for speed with the necessity of manual approval gates for high-risk post-deployment tasks?
One of the biggest blind spots is the assumption that the AI “understands” the sensitivity of a request, when in reality, it is simply processing data. Organizations often fail to realize that an AI might inadvertently bypass a subtle security control if that control isn’t hard-coded into the execution layer itself. To balance speed with security, teams should implement a tiered approval system where low-risk, day-two tasks—like restarting a non-production service—are fully automated, while high-risk actions—like decommissioning a production database or changing firewall rules—require a mandatory manual approval gate. This “human-in-the-loop” approach ensures that while the AI can handle the heavy lifting and preparation, the final decision for high-impact changes remains with a responsible engineer. It’s about using AI to accelerate the workflow, not to replace the critical judgment required for enterprise-grade security.
What is your forecast for AI-driven cloud management?
I foresee a shift where the “management console” as we know it begins to fade into the background, replaced by a sophisticated orchestration layer that communicates primarily through conversational and programmatic interfaces. Within the next few years, I expect AI agents will not just be making requests, but proactively suggesting optimizations—such as identifying underutilized resources on XCP-ng or recommending a move to a neocloud provider like Vultr for specific GPU workloads—all while operating within strict, pre-defined governance boundaries. We will move away from “automation scripts” toward “intent-based infrastructure,” where a team simply states a business requirement, and the management platform determines the most compliant and cost-effective way to execute that intent across a diverse, multi-provider estate. Ultimately, the successful organizations will be those that have built a solid foundation of role-based access and policy enforcement today, as these will be the non-negotiable guardrails for the autonomous agents of tomorrow.