Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Note: The core architecture for this pattern was introduced by Isaac Hawley from Tigera. If you are building an AI agent that relies on tool calling, complex routing, or the Model Context Protocol (MCP), you’re not just building a chatbot anymore. You are building an autonomous system with access to your internal APIs. With that power comes a massive security and governance headache, and AI agent security testing is where most teams hit a wall.

Agentic AI workloads are shipping to production on Kubernetes faster than the standards to secure them. Many teams deploying autonomous, tool-calling agents as containerized microservices do so without a shared baseline for securing or monitoring those containers. The CNCF AI Technical Community Group recently published a comprehensive article on cloud-native agentic standards, marking the first attempt to define best practices for such deployments.

You enable GKE Sandbox on a dedicated node pool, bind Workload Identity Federation to your AI agent pods, wrap your data services in a VPC Service Controls perimeter, and deploy your agents with the Agent Sandbox CRD using warm pools for sub-second startup. Your security posture dashboard shows every control configured and active. And then an attacker uses prompt injection to trick an agent into exfiltrating sensitive data through API calls that every single one of those layers explicitly allows.

Managing modern IT infrastructure often feels like balancing completely different ecosystems. For years, organizations have run separate, hand-built, Kubernetes stacks on top of legacy virtualization platforms. Due to security concerns, it just made sense to build a separate, tailored container environment that they could automate and schedule their exact needs. This fragmented approach leads to inconsistent security policies, fragile integrations between clusters, and operational silos.

You’re in a Slack thread at 9 AM on a Tuesday. A developer is asking why their LangChain agent can’t reach an external API anymore. You wrote the NetworkPolicy that blocked it. But you also can’t explain why you wrote that specific rule—because you wrote it based on what you guessed the agent would do, not what it actually does. You don’t have behavioral data. You don’t have an observation period.

You just connected your Kubernetes clusters to a CSPM tool. Within a few hours, the dashboard lights up: 500+ findings across your environment. Overly permissive RBAC roles, exposed services, unencrypted secrets, misconfigured network policies. Sorted by severity, color-coded, and completely overwhelming. So you do what any security engineer does. You start triaging. But twenty minutes in, a pattern emerges that the severity scores aren’t helping with.

Kubernetes backup sounds straightforward until you look closely at what a real application includes. A production workload usually spans Kubernetes resources, cluster configuration, persistent volumes, secrets, service accounts, network policies, and external dependencies such as cloud databases or object storage. Protecting one of those layers helps. Protecting all of them in a coordinated way is what makes recovery practical.

DevOps engineers running OpenShift know the platform well. They know how to build on it, scale on it, and operate it under pressure. What they often hit unexpectedly is the question of backup and recovery, especially once OpenShift Virtualization enters the picture. Most of the tooling that exists today wasn’t built with Kubernetes in mind. It was built for something else and extended toward it.

Why does traditional Kubernetes security fall short? Static scanners flag thousands of CVEs but can’t tell you which ones are actually loaded into memory and exploitable—only about 15% are loaded at runtime. Traditional tools also create siloed visibility, with CSPM, vulnerability scanners, and EDR each seeing only one slice of your environment. This makes it impossible to spot lateral movement or connect events across cloud, cluster, container, and application layers.