Skip to content
Learn Agentic AI
Learn Agentic AI11 min read2 views

Kubernetes Network Policies for AI Agent Security: Isolating Agent Communication

Design Kubernetes Network Policies to secure AI agent communication — including namespace isolation, egress restrictions to LLM APIs, and deny-all defaults with explicit allow rules.

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:

flowchart TD
    START["Kubernetes Network Policies for AI Agent Security…"] --> A
    A["Why Network Policies Matter for AI Agen…"]
    A --> B
    B["Default Deny: The Foundation"]
    B --> C
    C["Allow Ingress from the API Gateway"]
    C --> D
    D["Allow Agent-to-Agent Communication"]
    D --> E
    E["Restrict Egress to Approved Services"]
    E --> F
    F["Labeling Strategy for Multi-Agent Secur…"]
    F --> G
    G["Verifying Network Policies"]
    G --> H
    H["FAQ"]
    H --> DONE["Key Takeaways"]
    style START fill:#4f46e5,stroke:#4338ca,color:#fff
    style DONE fill:#059669,stroke:#047857,color:#fff
# 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.

See AI Voice Agents Handle Real Calls

Book a free demo or calculate how much you can save with AI voice automation.

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

Share
C

Written by

CallSphere Team

Expert insights on AI voice agents and customer communication automation.

Try CallSphere AI Voice Agents

See how AI voice agents work for your industry. Live demo available -- no signup required.

Related Articles You May Like

Use Cases

Automating Client Document Collection: How AI Agents Chase Missing Tax Documents and Reduce Filing Delays

See how AI agents automate tax document collection — chasing missing W-2s, 1099s, and receipts via calls and texts to eliminate the #1 CPA bottleneck.

Technical Guides

Scaling AI Voice Agents to 1000+ Concurrent Calls: Architecture Guide

Architecture patterns for scaling AI voice agents to 1000+ concurrent calls — horizontal scaling, connection pooling, and queue management.

Learn Agentic AI

Prompt Engineering for AI Agents: System Prompts, Tool Descriptions, and Few-Shot Patterns

Agent-specific prompt engineering techniques: crafting effective system prompts, writing clear tool descriptions for function calling, and few-shot examples that improve complex task performance.

Learn Agentic AI

Google Cloud AI Agent Trends Report 2026: Key Findings and Developer Implications

Analysis of Google Cloud's 2026 AI agent trends report covering Gemini-powered agents, Google ADK, Vertex AI agent builder, and enterprise adoption patterns.

Learn Agentic AI

Computer Use in GPT-5.4: Building AI Agents That Navigate Desktop Applications

Technical guide to GPT-5.4's computer use capabilities for building AI agents that interact with desktop UIs, browser automation, and real-world application workflows.

Learn Agentic AI

AI Agents for IT Helpdesk: L1 Automation, Ticket Routing, and Knowledge Base Integration

Build IT helpdesk AI agents with multi-agent architecture for triage, device, network, and security issues. RAG-powered knowledge base, automated ticket creation, routing, and escalation.