Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

Your team deployed Tetragon six months ago. TracingPolicies are humming along—you’re catching unauthorized binary executions, blocking suspicious network connections, and generating seccomp profiles from observed behavior. Runtime security for your traditional workloads is solid. Then engineering ships their first autonomous AI agent into production. A LangChain agent connected to internal databases, external APIs through MCP tool runtimes, and a vector database for RAG.

Last Tuesday, your security architect opened a pull request to add network policies to the payments namespace. The PR sat for six days. Three engineers commented with variations of “how do we know this won’t break checkout?” Nobody could answer. The PR got marked “needs discussion” and moved to a backlog column where it joined the fourteen other security hardening tickets nobody will touch.

The adoption of personal AI assistants is on the rise. everywhere. Developers, power users, and in a few cases, entire teams self-host them to connect messaging apps, automate tasks, and interact with AI models across their infrastructure. But when these self-hosted gateways become compromised, the blast radius can extend far beyond a single user’s chat history.

Your SOC gets a Defender for Cloud alert: “Suspicious API call from AI workload pod.” You click through and find a LIST secrets call against the Kubernetes API server from a pod running your invoice-processing agent on AKS. The pod’s Workload Identity has Contributor access to your key vault. By the time your analyst opens the AKS Security Dashboard, the pod has been rescheduled.

You’ve enabled GuardDuty EKS Runtime Monitoring across your clusters. You’ve configured IRSA for your Bedrock-calling agents. CloudTrail is logging every bedrock:InvokeModel event. And last Tuesday, one of your AI agents exfiltrated 12,000 customer records through a sequence of API calls that every one of those tools recorded as completely normal—because at the control plane level, they were.

We just published a deep breakdown of the Trivy supply chain attacks yesterday. Twenty-four hours later, we’re writing about the next one. Same threat actor. Different target. Worse implications. This time it’s LiteLLM, the Python library that acts as a universal API gateway for over 100 LLM providers. If you’re building anything with AI agents, MCP servers, or LLM orchestration, there’s a good chance LiteLLM is somewhere in your dependency tree.

We’ve been going back and forth on whether to publish this post. As the maintainers of Kubescape, a fellow CNCF open-source security project, we feel the weight of what happened to Trivy not as distant observers, but as people who see their successes and failures as our own. The Trivy maintainers are our friends. We share the same CNCF community, attend the same KubeCon-s, and fight the same fights (and share the same flights ).

When your SOC alerts on “suspicious AI activity” in a production trading system, your response team faces a question that didn’t exist two years ago: can you explain to regulators exactly which function processed the malicious prompt, which internal tool it called, and how customer data ended up leaving your environment?

It’s 2:47 AM and your SOC dashboard lights up. Six alerts fire across three hours from a single Kubernetes cluster: an outbound HTTP fetch to an unfamiliar domain, a tool invocation inside a customer support agent, an API call to an internal service the agent has never contacted, a service account token read, a file write to a model artifact directory, and an outbound data transfer that looks like normal API usage.

You’re forty-five minutes into a vendor demo for AI workload security. The dashboard looks polished—posture scores, misconfiguration findings, vulnerability counts, all tagged with an “AI workload” label that wasn’t there last quarter. You ask the obvious question: “Show me how this detects a prompt injection attack on our production agent.” Long pause. The SE pulls up a generic process anomaly rule.

You’ve been securing Kubernetes workloads for years. Your CSPM is running, your CNAPP is configured, your team knows how to triage container alerts. Then an AI agent lands in your cluster — maybe from the data science team, maybe from a vendor integration, maybe from a tool you didn’t even know was running. Within a week, it’s making API calls nobody planned, accessing data stores that aren’t in the architecture diagram, and executing code it generated itself.

Your Bedrock agent running on EKS receives a prompt through your RAG pipeline. CloudTrail logs it as a normal bedrock:InvokeModel event—status 200, authorized IAM role, expected endpoint. But inside the container, the agent’s response triggers a tool call that spawns curl to an external IP, exfiltrating the context window. GuardDuty doesn’t flag it because the connection routes through a permitted VPC endpoint. You open your AWS console and see a healthy API call.

You’ve sat through three vendor demos this week. Vendor A showed you an AI-SPM dashboard with a pie chart of misconfigurations. Vendor B showed you a nearly identical dashboard with different branding and a slightly wider set of compliance frameworks. Vendor C showed you posture findings with an “AI workload” tag that wasn’t in their product last quarter.

Your CNAPP flags a misconfigured service account. Your CSPM warns about an overly permissive IAM role. Your container scanner reports vulnerabilities in a model-serving image. But none of these tools can tell you that an AI agent just called an internal admin API it has never touched before — or that a prompt injection caused your LLM to leak customer data through a RAG connector.

Your SOC gets three alerts in quick succession: an unusual outbound connection from a container, a file read on a Kubernetes service account token, and a process spawn that doesn’t match the workload’s baseline. Three different tools, three separate dashboards, three tickets.

OAuth and OpenID Connect are the backbone of modern cloud-native identity and access management. From SaaS platforms and internal APIs to Kubernetes microservices, these protocols are responsible for verifying who is allowed to access what. When a vulnerability appears in a widely used authentication library, the impact can cascade across entire application ecosystems.

Do open source tools give you full Kubernetes attack coverage? Kubescape, Trivy, and Falco each excel in their lane—posture, vulnerabilities, and runtime—but none of them builds a complete attack narrative on its own. Deploying all three still leaves you with evidence fragments rather than a connected incident story. Why can’t siloed alerts keep up with real attacks?

Why do traditional incident response playbooks break in Kubernetes? Pods spin up and disappear in seconds, destroying forensic evidence before you can investigate. Attackers exploit service account tokens and move laterally through east-west traffic that perimeter tools never see—over 50% of ransomware deploys within 24 hours of initial access, leaving no time for manual investigation methods built for static servers.

Why do traditional intrusion detection systems fail in Kubernetes? Legacy IDS tools were built for static servers with fixed IPs and clear network perimeters—Kubernetes breaks all of those assumptions. Ephemeral pods, east-west traffic, encrypted service mesh communication, and dynamic IP addresses make perimeter-focused, signature-based detection effectively blind inside clusters.

Why do 3,000 CVEs not mean 3,000 real problems? Most vulnerability scanners flag every CVE in your container images without checking whether the vulnerable code is actually loaded and executed at runtime. Only 2–5% of alerts typically require action, which means your team is likely spending days triaging theoretical risks while genuinely exploitable vulnerabilities stay buried.

Your security team has done the homework. You’ve built a risk taxonomy covering agent escape, prompt injection, tool misuse, and data exfiltration. You’ve mapped those threats against your agent architecture’s seven layers. You’ve classified your agents by autonomy level — separating read-only chatbots from fully autonomous workflow agents that can book meetings, modify databases, and invoke other agents. The risk assessment is thorough.

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.

You’ve deployed five AI agents into your production Kubernetes cluster: a customer support chatbot, a fraud detection agent, a data pipeline processor, a code generation assistant, and an internal summarization bot. Your security team writes one set of guardrails and applies them uniformly. Within a week, you discover the code generation agent needs interpreter access the chatbot should never have.

Last Tuesday, a platform security engineer at a mid-size fintech company ran a routine audit on their production Kubernetes clusters. The audit surfaced three LangChain-based agents, two vLLM inference servers, and a Model Context Protocol (MCP) tool runtime. None had been reported by the development teams. None appeared in any security inventory. All had been running for weeks. One of the agents had been making outbound API calls to a third-party data enrichment service every four minutes.

You’re evaluating AI workload security tools and every demo looks the same. Vendor A shows you an AI-SPM dashboard. Vendor B shows you a nearly identical AI-SPM dashboard with slightly different branding. Vendor C shows you posture findings with an “AI workload” tag that wasn’t there last quarter.

Automation platforms sit at the center of modern infrastructure. They connect APIs, databases, CI/CD pipelines, SaaS tools, and internal systems. But when automation engines become compromised, the blast radius can be enormous. In February 2026, n8n, a widely used open-source workflow automation platform, disclosed four critical vulnerabilities that can lead to remote code execution (RCE) by authenticated users with workflow creation or editing permissions.

Your CISO just got word that engineering is deploying AI agents into production Kubernetes clusters next quarter. Not chatbots—autonomous agents that generate and execute code, call external APIs through MCP tool runtimes, access internal databases, and make decisions without human review. The question lands on your security team: “How are we securing these?”

Your security stack was built for workloads that follow predictable code paths. AI agents don’t. They interpret prompts, generate code on the fly, invoke tools dynamically, and escalate privileges in ways no developer anticipated — all as part of normal operation. The signals that indicate a compromise in a traditional container are indistinguishable from an AI agent doing its job. And most detection tools can’t tell the difference. This isn’t a theoretical gap.

Every cloud security vendor now has an AI-SPM dashboard. Strip away the branding, though, and most of these dashboards are doing the same thing: checking IAM configurations, scanning for misconfigured network access, inventorying AI models across cloud accounts, and flagging compliance gaps. It’s cloud security posture management with an AI label applied. That’s a problem, because AI workloads don’t behave like other cloud workloads.