Per-pod network policy is the real boundary for AI agents

At a glance

What this is: This is a field report on moving AI agent firewall functionality from in-pod sidecars to separate pods because Kubernetes NetworkPolicy cannot isolate a single container inside a pod.

Why it matters: It matters because IAM and platform teams cannot treat container-level intent as enforceable boundary control when the kernel and CNI only recognise the pod as the identity and policy unit.

Context

Kubernetes NetworkPolicy is enforced at the pod boundary, not the container boundary, so a design that expects one container to be tightly restricted while another container in the same pod has internet access is relying on a control model that does not exist. That mismatch matters for AI agent deployments because the firewall and the agent share the same runtime identity from the network layer's perspective.

The practical problem is not whether the agent is well behaved in theory, but whether the network boundary can actually prevent direct egress when the agent and its scanner live together. When the policy unit is the pod, the only reliable boundary is to separate the enforcement point from the actor it is meant to constrain.

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. If the firewall and the agent share one pod, they inherit the same network privileges, so a policy that blocks the agent also blocks the firewall. The result is either an open pod or a nonfunctional control, which is why the architecture has to change.

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. If the pod still has outbound allowance, a workload can bypass the proxy path or clear the environment in a subprocess. That means the proxy is useful for routing, but it cannot be the only control for containment.

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. Raw TCP dial attempts, subprocesses that clear proxy variables, and explicit NO_PROXY bypass checks reveal whether the pod can reach the internet outside the intended path. If any of those succeed, the architecture is relying on policy intent rather than enforcement.

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.

Technical breakdown

Why NetworkPolicy cannot isolate a single container

Kubernetes NetworkPolicy operates on pods, which are the unit of enforcement seen by the CNI plugin. Containers inside the same pod share a network namespace, so they also share the same allow and deny decisions. That means a sidecar cannot have a different egress policy from the main container unless the architecture changes. In effect, the pod becomes the security principal, even if operational logic wants to treat the sidecar as a separate control plane. See the Kubernetes Security Guide.

Practical implication: Design egress controls around pod separation, not around container intent.

Why HTTPS_PROXY is not a boundary

A proxy variable can redirect normal application traffic, but it does not change the underlying network authority of the pod. If a container can clear the environment variable, open a direct socket, or route around application logic, the kernel still evaluates the packet against the pod's NetworkPolicy. That is why proxy-based containment is advisory rather than structural. It can shape behavior, but it cannot replace an enforceable network boundary.

Practical implication: Treat proxy settings as routing hints, not as the control that enforces containment.

How the separate-pod model restores enforceable separation

A separate-pod model places the firewall in its own pod with its own egress policy, while the agent pod is restricted to calling that firewall service. The network layer then sees two distinct identities with two distinct policy envelopes. The agent pod has no direct internet route, and the firewall pod owns the outbound path. That removes the contradiction created by shared namespaces and gives the control plane a shape it can actually enforce. Read Zero Trust for AI Agents.

Practical implication: Move the trust boundary to the pod-to-pod link and make that link the only allowed egress path.

NHI Mgmt Group analysis

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.

Proxy-based confinement creates a false sense of containment. HTTPS_PROXY can steer traffic, but it cannot stop a container from attempting direct egress if the pod's network rules allow it. The result is a control that depends on cooperative behavior from the workload it is meant to constrain. Practitioners should treat that as advisory instrumentation, not as a security boundary.

Separate-pod firewalling is a network governance pattern, not just an implementation choice. Once the scanner moves into its own pod, the policy unit and the enforcement unit align. That gives platform teams a clean separation between the actor being constrained and the control that observes it, which is the only way to make per-pod enforcement meaningful at scale.

Runtime boundary design matters more than post-deployment hardening. The migration worked because it changed where authority lived, not because it added more rules around the same architecture. Agent identity models matter here: the network layer only enforces what it can distinguish. If the deployment collapses multiple functions into one pod, the security boundary collapses with it.

From our research library:

• 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.
• Read next: Zero Trust for AI Agents

What this signals

Identity boundaries in Kubernetes only work when the policy unit matches the workload boundary. If the deployment mixes the constrained actor and the enforcing control in one pod, the network layer cannot distinguish them. That is why separate-pod containment becomes the practical expression of least privilege for AI agent traffic.

The broader signal for platform teams is that container-level intent has to be translated into pod-level architecture before it becomes enforceable. The lesson is not specific to one firewall product or one agent pattern. It applies wherever the control depends on traffic mediation, because the cluster will only enforce what it can see as a distinct identity.

For practitioners

• 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.
• Test for bypass, not just intended routing Run raw socket checks, subprocess egress tests, and environment-clearing probes to confirm the pod cannot reach the internet outside the approved path.
• Audit mount and init patterns before migration Check ConfigMap mount shapes, init container dependencies, and other operational assumptions that can block a clean move to the separate-pod model.

Key takeaways

• Kubernetes NetworkPolicy cannot isolate one container inside a pod, so in-pod AI agent firewalls create a boundary mismatch.
• Proxy-based control is not enough on its own because the pod can still have a direct network path if policy permits it.
• Separating the firewall into its own pod aligns identity, enforcement, and egress control in a way that the cluster can actually enforce.

Related NHI Mgmt Group resources: Kubernetes Security Guide · AI Agent Authorisation Guide · Agentic AI Identity Guide · Zero Trust for AI Agents

Key terms

• Pod-scoped enforcement: A control model in which the pod, not the individual container, is the unit that the network or policy engine can see and restrict. In Kubernetes, this means every container in the pod shares the same egress decision, which makes container-specific network isolation impossible without changing the architecture.
• Separate-pod mediation: An architecture that moves a control function, such as a firewall or scanner, into its own pod so it can have its own policy envelope. The pattern restores a real boundary between the actor and the control that inspects or constrains it, which is especially important when the original workload needs tight egress control.
• Proxy advisory control: A routing mechanism that influences how traffic leaves a workload but does not by itself enforce a hard security boundary. It can be useful for steering requests, yet it remains bypassable if the pod retains direct network reach or if the application can ignore the proxy path.
• Bypass-closure testing: A verification step that checks whether a workload can reach an excluded destination through any alternative path, such as direct sockets, subprocesses, or environment-variable changes. It proves whether the intended containment model is real, rather than assumed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.