Kubernetes Network Policies for AI Agent Security: Isolating Agent Communication

Why Network Policies Matter for AI Agents

AI agents are powerful — they call external APIs, execute tools, and communicate with other agents. This power creates a large attack surface. A compromised agent Pod could exfiltrate training data, call unauthorized APIs, or move laterally to internal services. Kubernetes Network Policies enforce firewall rules at the Pod level, ensuring each agent can only communicate with the services it legitimately needs.

Default Deny: The Foundation

Start by denying all traffic in the AI agents namespace. Then add explicit allow rules for each required communication path:

# deny-all.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: ai-agents
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

This policy selects all Pods in the namespace (empty podSelector) and blocks both incoming and outgoing traffic. Nothing works until you add explicit allow rules.

Allow Ingress from the API Gateway

Only the API gateway should send requests to your AI agents:

# allow-gateway-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-gateway-to-agents
  namespace: ai-agents
spec:
  podSelector:
    matchLabels:
      app: ai-agent
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: api-gateway
          podSelector:
            matchLabels:
              app: gateway
      ports:
        - protocol: TCP
          port: 8000

This allows traffic only from Pods labeled app: gateway in the api-gateway namespace, and only to port 8000. Any other ingress is denied.

Allow Agent-to-Agent Communication

In a multi-agent system, the triage agent needs to reach specialist agents:

# allow-agent-to-agent.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-triage-to-specialists
  namespace: ai-agents
spec:
  podSelector:
    matchLabels:
      role: specialist-agent
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: triage-agent
      ports:
        - protocol: TCP
          port: 8000

Specialist agents accept traffic only from the triage agent, not from each other or from external sources.

Restrict Egress to Approved Services

Control which external services your agents can reach:

# allow-agent-egress.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-agent-egress
  namespace: ai-agents
spec:
  podSelector:
    matchLabels:
      app: ai-agent
  policyTypes:
    - Egress
  egress:
    # Allow DNS resolution
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    # Allow access to the database
    - to:
        - namespaceSelector:
            matchLabels:
              name: databases
          podSelector:
            matchLabels:
              app: postgresql
      ports:
        - protocol: TCP
          port: 5432
    # Allow HTTPS to external LLM APIs
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 10.0.0.0/8
              - 172.16.0.0/12
              - 192.168.0.0/16
      ports:
        - protocol: TCP
          port: 443

This allows DNS resolution, PostgreSQL access within the cluster, and HTTPS calls to external APIs like OpenAI. It blocks access to all internal RFC 1918 addresses that are not explicitly allowed, preventing lateral movement.

Labeling Strategy for Multi-Agent Security

Use consistent labels to build clear network policies:

# Python script to generate labeled Deployment manifests
AGENT_ROLES = {
    "triage": {"can_reach": ["specialist", "tool-service"]},
    "specialist": {"can_reach": ["tool-service", "database"]},
    "tool-service": {"can_reach": ["database"]},
}

def generate_labels(agent_name: str, role: str) -> dict:
    return {
        "app": agent_name,
        "role": role,
        "tier": "ai-agent",
        "network-policy": "restricted",
    }

Verifying Network Policies

Test that your policies work by attempting blocked connections:

# Deploy a debug Pod
kubectl run nettest --image=busybox --rm -it --namespace=ai-agents -- sh

# Test allowed connection (should succeed)
wget -qO- --timeout=5 http://ai-agent-svc:8000/health

# Test blocked connection (should timeout)
wget -qO- --timeout=5 http://some-other-service:8080/api

FAQ

Do I need a CNI plugin that supports Network Policies?

Yes. The default kubenet CNI in some Kubernetes distributions does not enforce Network Policies. You need a CNI plugin like Calico, Cilium, or Weave Net. Calico is the most widely used for Network Policy enforcement and supports both Kubernetes native policies and its own extended policy format with additional features like DNS-based egress rules.

How do I allow AI agents to reach only specific external API domains?

Kubernetes Network Policies operate at the IP level, not the DNS level. To restrict by domain name, use Cilium Network Policies with DNS-aware filtering or configure an egress proxy like Squid or Envoy that whitelists specific domains. Route all agent egress through the proxy and block direct internet access.

What happens if I apply conflicting Network Policies?

Network Policies are additive. If one policy allows traffic on port 8000 and another allows port 9090, both ports are accessible. There is no deny-override behavior — if any policy allows a connection, it is permitted. This is why starting with a deny-all policy and adding specific allows is the safest approach.

---

#Kubernetes #NetworkSecurity #NetworkPolicies #AIAgents #ZeroTrust #AgenticAI #LearnAI #AIEngineering