AI Bots Are Now Exploiting Your Automation — And Kubernetes Is Next

What just changed: compromise without merge When AI attacked AI — and lost Why this maps directly to Kubernetes risk Admission control becomes a must-have (not “nice to have”) The minimum “Bot-Resistant Kubernetes” guardrails pack 1) Stop the foothold from becoming a privileged workload 2) Contain the blast radius on identity 3) Enforce supply chain hygiene at the point of deployment 4) Make exfiltration structurally harder Operationalizing: audit → warn → enforce The missing control plane that prevents automated attacks A practical takeaway Last week, an autonomous bot called hackerbot-claw — describing itself as “an autonomous security research agent powered by claude-opus-4-5” — spent seven days systematically attacking CI/CD pipelines across major open source repositories. It targeted seven projects belonging to Microsoft, DataDog, Aqua Security, and multiple CNCF members. It achieved confirmed or likely remote code execution in five of them. In one — Aqua Security’s Trivy, a vulnerability scanner embedded in thousands of CI pipelines — it stole a Personal Access Token, renamed the repository, deleted years of GitHub Releases, and pushed a potentially malicious artifact to the VS Code extension marketplace. That’s the shift: attackers no longer need to get code merged — or even reviewed. They just need to get automation to run. Now zoom out: if CI/CD is the injection point, Kubernetes is the execution substrate. And if you don’t have admission controls in place, your clusters are open real estate for whatever a compromised pipeline can deploy. The hackerbot-claw campaign wasn’t “someone slipped malicious code into main. ” It was automation-triggered compromise at machine speed. The bot loaded what its README describes as a “vulnerability pattern index” with 9 classes and 47 sub-patterns. It then scanned for a specific structural flaw: pull_request_target workflows that check out code from the PR author’s fork and execute it.