Between the duration it took to write a first draft of this blog post and complete it, I have already lost count of how many new major vulnerabilities were discovered. In the past few weeks alone, we have seen: CopyFail, Dirty Frag, and the Mini Sha-Hulud supply chain campaign hitting hundreds of npm packages – to mention a few. Barely a week goes by without a new vulnerability hitting the headlines. This is the new reality the entire software industry has to grapple with, especially in the wake of highly capable models such as Mythos. If you have been paying attention, two interesting trends have been happening simultaneously. AI workloads have introduced an entirely new class of vulnerabilities. At the same time, adversaries now use AI to attack faster. These trends indicate that the pace of AI adoption is outrunning the security scrutiny applied to it, and attackers are taking full advantage of this gap. Many AI and security professionals had a growing suspicion that the sudden rise in the number and sophistication of attacks wasn’t just a coincidence as it correlated too closely with the recent availability of AI tooling. A report from Google Threat Intelligence Group (GTIG) recently confirmed this. GTIG has documented a shift to large-scale use of AI in adversarial workflows. For the first time, a threat actor was identified using a zero-day exploit believed to have been developed with AI, with plans to deploy it in a mass exploitation event. However, there is good news! the same runtime security foundation addresses both challenges. The cloud native security community has spent the past decade building deep kernel-level runtime observability and enforcement. This foundation is precisely what enables teams to enforce boundaries beneath agentic workloads and respond at the speed AI-assisted attacks demand. The building block for addressing AI security already exists. What needs to evolve is the mental models. On the workload side, the assumption that a deterministic, predictable workload is what we’re securing no longer holds true, as agentic AI workloads can reason, improvise, and cross trust boundaries in ways we did not anticipate. On the attacker side, the emergence of AI-assisted attacks nullifies the assumptions about speed, knowledge, and sophistication of the adversary. In this blog post, we’ll explore how AI-assisted attacks are changing the assumptions we make about the adversary, the new attack surface AI workloads introduce, and the infrastructure, identity, and runtime controls they require, and finally, how teams can address this new threat landscape with Isovalent Runtime Security. AI Workloads as the Target “AI workloads” is a broad category, and it's worth being precise before going any further, as the threat landscape varies by workload type. On one end of the spectrum are inference servers, training pipelines, vector databases, embedding services, and so on. These are largely deterministic workloads. They do a specific set of things, against a predictable set of dependencies, talk to clearly defined network destinations, and from a runtime security point of view, behave very much like any other workload. The security primitives and mental model for addressing their threats are already familiar. On the other end of the spectrum are agentic workloads. An agentic workload is typically reasoning and taking actions dynamically based on inputs that can come from anywhere, from user prompts, tool call responses, external data sources, or other agents. This changes the attack surface. You’re now faced with securing a somewhat unpredictable decision-making system whose behavior can be potentially influenced by whoever is able to get data into it and whose action at runtime may differ from what was observed during prior sessions. For most of the past decade, when security teams thought about securing cloud native workloads, the questions were fairly straightforward. Is the provenance of the source code secure? What ports are open in the environment? What CVEs are exposed? And so on. The workload itself was essentially a known quantity – a service that did a specific set of things, against a predictable set of dependencies. Agentic workloads break this model at its very foundation. The OWASP Top 10 for Agentic Application clearly highlights one of the core security challenges of agentic workloads: “agents cannot reliably distinguish between legitimate instructions and attacker-controlled content”. This architectural design of how language models process input gives way to a new class of vulnerabilities. Prompt injection, supply chain attacks on MCP tool servers, model exfiltration, and tool misuse all fall into this category. These do not look like anything like what traditional security tooling was built to address. A principle worth internalizing here is how zero trust carries over to agentic workloads. In traditional environments, zero trust means every action should be verified, every access is scoped to the minimum required, and nothing is implicitly trusted. The same logic carries over to agents. OWASP formalizes this through the principle of Least Agency: avoid granting agents more autonomy than their tasks actually require. In practice, Least Agency means extending the zero-trust question: what is the minimum this workload needs to do its job? These boundaries can be enforced at the kernel level with Tetragon Tracing policies, which is how zero-trust principles translate into concrete runtime controls for agentic systems. Agents need infrastructure-level isolation; the right approach varies by organization. Some organizations opt for containers, Kubernetes pods, microVMs, full VMs, or a combination of both. The Kubernetes community has been moving in this direction. The Kubernetes agent sandbox project is purpose-built to manage isolated, stateful singleton workloads, specifically for AI agent runtimes and scenarios that demand long-running containers with a stable identity. This reflects a growing recognition in the community that agents are a distinct class of workloads requiring distinct infrastructure primitives. What all these threats have in common is that they produce kernel activity, including network connections, file access, process executions, every signal eBPF was built to observe, and where Tetragon sits. The next section of this blog post discusses the runtime controls agentic workloads require, and how teams can address this new threat landscape with Isovalent Runtime Security. Isovalent Runtime Security for Agentic, Non-Deterministic Workloads One of the biggest challenges of runtime security for agentic workloads is that they are non-deterministic. How do we write security policies for workloads with an unpredictable profile? This stochastic behavior of agentic workloads is mostly valid at the application layer. At the kernel layer, the behavioral profile of agentic workloads becomes far more stable. An agent behaving legitimately will spawn known processes, make expected network connections, access expected file paths, and so on. A compromised agent will deviate from this pattern. Isovalent Runtime Security offers capabilities specifically suited for this use case: The Isovalent Runtime Enterprise Application Model provides full observability over which processes were started/exited, and which corresponding network connections were initiated/terminated by these processes, all aggregated directly within eBPF and exportable to any SIEM. Beyond periodic snapshots, the Application Model Telemetry events provide a real-time stream of incremental changes. For agentic workloads, this is invaluable precisely because of their stochastic behavior, since defining a static policy can be challenging. The Isovalent Enterprise Application Model enables building a baseline picture of a workload's runtime behavior over time. Sandbox Policies offer simplified, high-level auditing and enforcement of system calls. Think of them as an improved, Kubernetes Identity-Aware Seccomp that is dynamic and supports flexible in-kernel selectors. For agentic workloads, a good approach is to start with a default-deny posture and work up, permitting only the specific syscalls the agent actually needs. Since agentic workloads are stochastic, anticipating every unexpected behavior can be impractical. Sandbox Policies enable us to flip this model: define exactly what's allowed and block everything else. Note that Sandbox Policies are a limited feature suited for specific production scenarios; consult with an Isovalent contact before deploying them in your environment. Isovalent Runtime Security and the broader Isovalent platform offer a range of features that can provide the right security for agentic workloads. Beyond process-level visibility, understanding what an agent is actually doing requires full network context. Correlating Raw Socket visibility, TCP Visibility, HTTP Visibility, TLS Visibility, and DNS Visibility gives security teams a complete picture of network behavior, not just that a connection was made, but what was requested, over which protocol, and to which destination. Combined with Tetragon's file integrity monitoring capabilities, this covers the full spectrum of observable agent activity from the kernel up to the application layer. For cases where deeper introspection workload-specific introspection is needed, Tetragon supports hooking directly into userspace functions. Security teams can instrument specific functions within an agent runtime or its dependencies, observing arguments and return values at the application layer without modifying the applications(agent) itself. Every environment is different; the right combination of visibility and enforcement capabilities depends on your specific workloads, infrastructure, and risk profile. Talk to an Isovalent contact to evaluate your environment and find out how Isovalent Enterprise can secure your AI workloads. AI-Assisted Attacks Securing AI workloads is only half of the challenge. The other half is that adversaries now have their own AI capabilities, and they're using them to move faster than defenders can respond. AI-enabled attackers are targeting everything from traditional infrastructure and cloud workloads to supply chains. Every organization is now susceptible to these AI-enabled attacks, whether or not it runs AI workloads. The traditional mental model for the progression of an attack assumes there are human(s) on the other end manually conducting reconnaissance, identifying vulnerabilities, writing exploits, and executing them in stages, with a meaningful time gap between each stage in the attack chain. This time gap between each step is typically the window that defenders rely on to stop attacks. With the emergence of AI-assisted attacks, this window is getting shorter. AI is enabling attackers to compress the attack lifecycle. Reconnaissance that typically takes days can now be automated. Vulnerability analysis that requires deep expertise can now be augmented by models that have ingested CVE data and exploit research than any individual could possibly do. Exploit generation, which has traditionally been the highest still bottleneck in the kill chain, is now something threat actors are experimenting with. This ultimately results in the window between initial access and impact collapsing. An attacker who gains a foothold in an environment may not need days to move laterally, escalate privileges, and achieve their goals. The Mean Time to Contain (MTTC) was already a challenge for many organizations, and the emergence of AI-enabled attacks further exacerbates this problem. The Real-time enforcement that Isovalent runtime security provides empowers teams to operate at the speed required to address this new threat landscape. Anomalies are immediately visible, and security policies for patching CVEs, preventing, and remediating attacks can be deployed on the fly. Conclusion The current landscape in AI security feels a lot like the early days of cloud native security. The tooling is maturing, and the broader community is still figuring out what “good” security looks like for AI workloads. The shift from traditional to cloud native workloads took over a decade; in comparison, the shift to AI workloads is happening exponentially faster. As the broader community catches up, the teams that will stay ahead are those that invest in the right observability and enforcement foundations rather than wait for the threat landscape to fully mature. The patterns for AI security are clear enough. Agentic workloads need isolation at the infrastructure layer, non-human identities with scoped and ephemeral credentials, runtime enforcement that can keep up with the highly dynamic threat landscape, and deep introspection across the kernel, network, and application layers Combining kernel-level enforcement, L7 visibility, and application-layer introspection gives teams the most robust security observability stack currently available for AI workloads. The Isovalent platform is built to address this challenge across the full range of environments where AI workloads are deployed – Kubernetes, VMs, MicroVMs, multi-cloud, and hybrid environments. The underlying primitives have been proven at scale over the past decade. Applying them to AI workloads is extending the existing proven foundation. You can learn more at: Explore the securing AI/ML Workloads with Isovalent Enterprise lab OpenAI and Isovalent: A Common Networking Foundation For AI Infrastructure Deconstructing Voidlink: Why New AI and Cloud-Native Threats Require a New Class of Defense Explore the Securing OpenClaw with Tetragon lab