AI agent firewall sidecars: what breaks when they share a pod?

TL;DR: In-pod AI agent firewall sidecars collide with Kubernetes NetworkPolicy because the policy applies per pod, not per container, so any attempt to isolate the agent while preserving sidecar internet access creates a structural bypass risk, according to PipeLab. The architectural boundary has to move to a separate pod model, where the agent pod can only reach the firewall service and the firewall pod owns egress.

Editorial analysis by NHI Mgmt Group, based on content published by PipeLab: “Per-Pod NetworkPolicy in Practice: Migrating Five Agents in a Day”.

Key questions

Q: What breaks when an AI agent firewall sidecar shares a pod with the agent?

A: The boundary breaks because Kubernetes enforces NetworkPolicy per pod, not per container.

Q: Why does proxy-based egress control fail as a containment model?

A: Proxy settings shape application behavior, but they do not create a security boundary at the kernel or CNI layer.

Q: How do teams know whether a pod-level egress control is actually working?

A: They test for direct egress that should not be possible.

Practitioner guidance

• Map every sidecar-bound control to its real policy unit Inventory which container functions depend on pod-scoped controls and identify any design that assumes container-level isolation inside a shared namespace.
• Split firewall logic into a dedicated pod Move the scanning or mediation function into a separate deployment with its own egress NetworkPolicy, then restrict the agent pod to that service only.
• Remove direct internet egress from the agent pod Delete broad outbound rules from the agent workload and keep only the path needed to reach the firewall service or equivalent mediation point.

Bottom line: Kubernetes NetworkPolicy cannot isolate one container inside a pod, so in-pod AI agent firewalls create a boundary mismatch.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →