Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

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.

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.

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.