Dominic Jainy is a seasoned IT professional whose work sits at the intersection of machine learning, blockchain, and robust infrastructure security. With years of experience navigating the complexities of artificial intelligence deployments, he has become a leading voice on how organizations can leverage transformative technology without compromising their foundational security. In this discussion, we explore the critical shift from experimental AI to production-ready agentic systems, focusing on the “layered control model” necessary to contain the inherent risks of autonomous code execution. Our conversation covers the strategic implementation of hardware-level isolation, the necessity of restrictive network policies, and the evolution of identity management in an era where prompt injection can turn a helpful tool into a high-privileged vulnerability.
Agents often require broad credentials and network access to be useful, but this creates a massive attack surface. How do you determine where to draw the line for a production agent, and what specific metrics or indicators suggest that an agent’s permissions have become a liability?
The fundamental realization every team must reach is that capability without control is a liability, not an asset. When I look at a production agent, I draw the line at the very first moment it transitions from a “read-only” observer to an “active” participant with long-running, stateful capabilities. You know permissions have become a liability when the agent possesses service accounts or long-lived API keys that could lead to repository compromise or database access if a single prompt injection occurs. We look for indicators like an agent having the ability to perform unsolicited inbound connections or accessing internal configuration data that it doesn’t strictly need for its current task. By starting with a baseline of zero inbound access and no implicit tool permissions, you create a environment where every added capability is a conscious, logged decision rather than a dangerous default.
While containers provide isolation, kernel-sharing vulnerabilities like runc escapes continue to expose host systems. Why should organizations prioritize hardware-level boundaries like microVMs for arbitrary code execution, and what are the step-by-step performance trade-offs involved in moving away from standard containers?
Containers are excellent for many things, but they share a host kernel, and history has shown us—through vulnerabilities like CVE-2019-5736 and the more recent CVE-2024-21626—that this boundary is far from impenetrable. When an agent is tasked with executing arbitrary or unvetted code, the risk of a runc-based escape becomes a visceral threat that can overwrite the host binary itself. Moving to microVMs introduces a hardware-level boundary that significantly reduces the blast radius, even if it means accepting a slightly different performance profile. The trade-off begins with a small increase in cold-start latency and memory overhead, as you are essentially booting a more complete, albeit stripped-down, environment for every agent. However, in a production setting, these milliseconds are a small price to pay to prevent a catastrophic breakout that could compromise the entire underlying infrastructure.
Unrestricted network egress provides a clear path for data exfiltration if an agent is compromised via prompt injection. How do you implement restrictive allowlists without breaking the agent’s ability to browse the web or update dependencies, and what anecdotes illustrate the success of this containment?
The secret to effective containment is treating network policy as a dynamic shield rather than a static wall. We implement restrictive allowlists that permit only explicitly approved domains required for documentation lookups or specific API interactions, ensuring the agent isn’t just a wide-open gateway to the internet. I’ve seen cases where a model was tricked into reading a sensitive .env file via a clever injection, but because the egress policy was locked down, the attacker had no way to ship those secrets to an external domain. It’s an incredibly satisfying moment for a security team to see an attack “succeed” in the prompt phase but fail completely at the network layer. By logging all outbound traffic, we establish a behavioral baseline that makes any attempt to reach an atypical domain stand out like a flare in the night.
Embedding credentials directly in system prompts or runtimes often leads to leaks during adversarial interactions. What are the practical steps for migrating to a centralized gateway with short-lived tokens, and how does this architecture change the way agents interact with external APIs?
Migrating away from the “secrets in prompts” anti-pattern is a critical step in maturing an agent’s security posture. You start by implementing a centralized gateway that acts as the sole intermediary for all large language model interactions, stripping raw provider credentials away from the individual agent runtimes. This architecture allows you to enforce rate ceilings, log every response, and most importantly, issue short-lived, scoped tokens that expire before they can be meaningfully abused. Instead of the agent “knowing” a secret, it simply requests an action through the gateway, which then validates the request against existing RBAC or ABAC policies. This creates a much cleaner separation of concerns where the model handles the logic, but the gateway handles the trust, making the entire system far more resilient to the “unexpected output” risks inherent in probabilistic systems.
High-risk actions, such as modifying production code or accessing secrets, can cause catastrophic failures if fully automated. What specific workflows create “deliberate friction” for these sensitive tools, and how do you balance the need for human oversight with the agent’s operational speed?
In our world, speed is often the enemy of safety, so we introduce “deliberate friction” through policy checks and mandatory approval workflows for any high-risk boundary. For instance, an agent might be allowed to draft code or suggest a database migration, but the actual execution or “commit” action requires an out-of-band confirmation from a human operator. We also use authenticated tunnels that are opened only when debugging or collaborative inspection is required, ensuring that ingress is a temporary operational event rather than a permanent vulnerability. This balance is maintained by automating the mundane, low-risk tasks—like gathering data or summarizing logs—while keeping the “kill switch” and final verification in human hands. It feels less like a bottleneck and more like a safety harness, allowing the agent to move quickly through the preparation stages while ensuring the final deployment remains secure.
Agentic systems often fail at integration boundaries where untrusted external content overrides internal system instructions. How should teams approach red-teaming and adversarial prompt fuzzing to surface these risks, and what specific behavioral baselines are necessary to detect anomalies in real-time?
Red-teaming shouldn’t be a one-off audit; it must be a continuous process of adversarial prompt fuzzing that specifically targets the points where external documents are ingested. We look for “jailbreak” attempts where hidden instructions in a web page or a PDF try to redirect the agent’s behavior or induce data disclosure. To detect these in real-time, we monitor for deviations from established behavioral baselines, such as an agent suddenly attempting to read files it has never accessed before or invoking tools in an atypical sequence. When an agent that usually only calls a search API suddenly starts trying to access the local file system or a secret manager, the system should automatically trigger an alert or a sandbox shutdown. Confronting these weaknesses under controlled conditions through red-teaming is the only way to ensure your defenses are actually capable of withstanding a live, evolving threat.
What is your forecast for the future of AI agent security?
I believe we are moving toward a future where security is not an afterthought but a first-class citizen of the agent’s actual runtime. We will see the rise of “immutable agents” that operate within strictly defined, ephemeral micro-environments where every single action is verified against a real-time policy engine. The industry will likely move away from the current model of broad, multi-purpose agents toward a swarm of specialized, “least-privileged” agents that only exist for the duration of a single task. This shift will make it significantly harder for attackers to gain a foothold, as there will be no long-lived state or broad credentials to steal. Ultimately, the organizations that thrive will be those that treat infrastructure as code and isolation as a non-negotiable design decision, turning their security posture into a competitive advantage.