Summary
AI agents that manage computer systems like Kubernetes can change important settings by reading messages and running commands. This can be risky because harmful instructions might trick the AI into doing unsafe things. The authors explain why we should assume these AI agents can be hacked and propose ways to protect the system using multiple layers of security built into Kubernetes tools. They create a plan with guiding ideas and practical examples for keeping these AI agents contained. They also show how these protections work in cloud services like Amazon, Microsoft, and Google Kubernetes.
What this means in practice
- •For cloud infrastructure teams: Implement a layered security framework to safely run AI agents with full operating access on Kubernetes clusters.
- •For cybersecurity engineers: Use the reference architecture and policies to develop automated defenses against AI agent compromise and misuse in containerized environments.
A position paper. It proposes an approach and reports no results.
Abstract
Large language model (LLM) agents are moving from chat interfaces into infrastructure operations, where they read telemetry, call tools, generate and execute code, and change the state of production Kubernetes clusters. This collapses a boundary that conventional cloud-native security assumes: the boundary between data and control. Content that an agent merely reads (a log line, a ticket, a tool description) can redirect what it does. This paper argues that the model must not be treated as a security boundary and that agent safety on Kubernetes is therefore an infrastructure problem: every guarantee must continue to hold under the assumption that the agent is fully compromised by prompt injection. We contribute (i) a threat model and ten-class threat taxonomy for agents operating on and within Kubernetes, aligned with emerging OWASP guidance for agentic applications; (ii) nine design principles, centered on complete mediation at the tool boundary and on breaking the combination of untrusted input, sensitive access, and external egress; (iii) a seven-layer defense-in-depth framework that maps each principle to native or widely adopted Kubernetes mechanisms: workload identity, RBAC and ValidatingAdmissionPolicy, gVisor/Kata sandboxing via the SIG Apps Agent Sandbox project, FQDN-aware egress policy, an agent/MCP gateway with policy-as-code over tool arguments, and eBPF runtime enforcement; (iv) a reference architecture with concrete policy artifacts and per-layer bindings for Amazon EKS, Azure Kubernetes Service, and Google Kubernetes Engine; and (v) a qualitative evaluation comprising a threat-control coverage matrix and four attack walkthroughs, with a proposed empirical methodology. We report no measured attack-success or overhead figures; instead we identify residual risks and the measurements needed to validate the framework.