AI Agent Security on Kubernetes

AI agents are getting Kubernetes access. Coding agents create deployments. Monitoring agents read pod logs. Data agents access storage. The question is: what happens when an agent goes wrong?

A misconfigured or compromised AI agent with cluster-admin can destroy your production environment in seconds. This guide covers the security patterns you need.

The Threat Model

AI agents on Kubernetes face unique risks:

1. Prompt injection — malicious input tricks the agent into executing harmful commands
2. Scope creep — agent given broad permissions “to be safe” that it does not need
3. Data exfiltration — agent sends sensitive data to external endpoints
4. Resource exhaustion — agent creates unbounded pods, consuming all cluster resources
5. Lateral movement — compromised agent accesses other namespaces or services

Layer 1: RBAC (Least Privilege)

Every AI agent gets its own ServiceAccount with minimal permissions:

# Dedicated namespace for AI agents
apiVersion: v1
kind: Namespace
metadata:
  name: ai-agents
  labels:
    pod-security.kubernetes.io/enforce: restricted
---
# ServiceAccount per agent
apiVersion: v1
kind: ServiceAccount
metadata:
  name: coding-agent
  namespace: ai-agents
---
# Role: only what the agent needs
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: coding-agent-role
  namespace: ai-agents
rules:
  # Can read pods and logs in its own namespace
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  # Can create deployments (but only in ai-agents namespace)
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "create", "update", "patch"]
  # CANNOT delete anything
  # CANNOT access secrets
  # CANNOT access other namespaces
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: coding-agent-binding
  namespace: ai-agents
subjects:
  - kind: ServiceAccount
    name: coding-agent
roleRef:
  kind: Role
  name: coding-agent-role
  apiGroup: rbac.authorization.k8s.io

Key principle: No ClusterRoles for agents. Namespace-scoped roles only.

Layer 2: Pod Security

apiVersion: v1
kind: Pod
metadata:
  name: coding-agent
  namespace: ai-agents
spec:
  serviceAccountName: coding-agent
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: agent
      image: my-agent:latest
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]
      resources:
        limits:
          cpu: "2"
          memory: "4Gi"
          # No GPU unless explicitly needed
        requests:
          cpu: "500m"
          memory: "1Gi"
      volumeMounts:
        - name: workspace
          mountPath: /workspace
  # gVisor sandbox for untrusted agent workloads
  runtimeClassName: gvisor
  volumes:
    - name: workspace
      emptyDir:
        sizeLimit: 10Gi

Layer 3: Network Policies

Restrict what the agent can reach:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: agent-network-policy
  namespace: ai-agents
spec:
  podSelector:
    matchLabels:
      app: coding-agent
  policyTypes:
    - Ingress
    - Egress
  egress:
    # Allow DNS
    - to: []
      ports:
        - port: 53
          protocol: UDP
    # Allow HTTPS to LLM API providers
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
      ports:
        - port: 443
          protocol: TCP
    # Block access to internal services
    # (default deny for anything not listed)
  ingress: []  # No inbound traffic to the agent

Layer 4: Runtime Detection

Use Kubescape 4.0 for AI-aware runtime monitoring:

• Detect unexpected network connections
• Alert on file system modifications outside workspace
• Monitor for privilege escalation attempts
• Track API calls that exceed the agent’s expected behavior

Layer 5: Audit Logging

Log every action the agent takes:

# Kubernetes audit policy for AI agents
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    users: ["system:serviceaccount:ai-agents:coding-agent"]
    resources:
      - group: ""
        resources: ["pods", "services", "configmaps"]
      - group: "apps"
        resources: ["deployments"]

The Principle: Trust, But Verify

AI agents should be treated like junior developers with production access:

1. Limit blast radius — namespace isolation, resource quotas
2. Log everything — audit trail for every action
3. Monitor behavior — runtime detection for anomalies
4. Review regularly — periodic RBAC audits
5. Sandbox experiments — gVisor for untrusted workloads

Related Resources

• Kubescape 4.0: AI Agent Security
• Lima v2.1: AI Agent Sandboxing
• Kubernetes RBAC Guide
• Kubernetes Network Policies
• Container Security with Trivy
• DevSecOps Pipeline
• Zero Trust Architecture

About the Author

I am Luca Berton, AI and Cloud Advisor. I design security architectures for AI workloads on Kubernetes. Book a consultation.