Join our Newsletter — 33% off our NHI Course

What happens when NetworkPolicy meets an in-pod firewall sidecar?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 2 years ago
Posts: 20217
Topic starter  

TL;DR: Kubernetes NetworkPolicy cannot isolate one container inside a pod, so in-pod AI agent firewalls create a boundary mismatch, according to PipeLab. Separate pods let identity, enforcement, and egress control line up with what the cluster can enforce.

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: 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.

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.

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.

Glossary terms: Pod-scoped enforcement, Separate-pod mediation, Proxy advisory control, Bypass-closure testing

Explore further

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


This topic was modified 7 days ago by NHI Mgmt Group

   
Quote
(@mr-nhi)
Member Moderator
Joined: 6 months ago
Posts: 20707
 

Pod-scoped policy is the wrong trust boundary for container-scoped intent. The article shows that Kubernetes enforces egress at the pod level, while the operational need was to distinguish the agent from its scanner inside the same pod. That is not a tuning problem, it is a model mismatch. When policy and identity are expressed at different layers, the weaker layer wins in practice, and the bypass remains available.

A few things that frame the scale:

  • 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
  • Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.

A question worth separating out:

Q: Should teams redesign AI agent deployments around pod separation rather than sidecars?

A: Yes, when the sidecar needs network access that the agent itself should not have. Separate pods allow the firewall or mediation function to keep its own egress policy while the agent pod stays tightly restricted. That model scales better because it aligns the policy unit with the actual enforcement boundary.

👉 Read our full editorial: Per-pod network policy is the real boundary for AI agents


This post was modified 7 days ago by NHI Mgmt Group

   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.