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

Why the Sidecar Pattern Fails in a Shared Pod

The architectural failure is that Kubernetes NetworkPolicy is enforced at the pod boundary, not at the container boundary. Once the firewall sidecar and the agent share one pod, they share the same network identity and the same allow or deny outcome. That means the policy cannot block the agent while sparing the firewall, so the design loses the separation it was supposed to create.

That is why the issue is not just an implementation bug, but a control-placement problem. If the enforcement point cannot distinguish the firewall container from the agent container, then the firewall cannot act as an independent gatekeeper for the traffic it is meant to inspect or restrict.

What Breaks Operationally

The practical break is binary: either the pod stays reachable enough for the firewall to function, or the policy is tightened enough to stop the agent and also stop the firewall. In either case, the architecture stops delivering the intended security property. A shared pod turns the firewall into a co-resident process rather than an independent enforcement layer.

That matters most when the firewall is expected to mediate outbound calls, block suspicious destinations, or enforce per-request policy decisions. If the firewall cannot observe or constrain the agent without inheriting the agent's own permissions, then the environment is forced into a choice between ineffective filtering and overbroad access.

What the Architecture Needs Instead

The fix is to move the control boundary so the enforcement component is no longer trapped inside the same pod as the thing it governs. For Kubernetes-based designs, that usually means separating the agent and the control plane element into different pods or otherwise placing the enforcement point where it can act independently. The important design principle is that the policy boundary must be outside the workload boundary it is meant to constrain.

This is also why sidecar patterns are often poor fits for controls that must remain authoritative over the primary workload. If the security function shares scheduling, network scope, and lifecycle with the workload it controls, it becomes vulnerable to the workload's own privileges and failure modes. The safer pattern is one that preserves separable trust domains and independent enforcement.

Risk and Threat Considerations

When a control container shares the same pod as the agent it is supposed to restrain, the result is a weak trust boundary. An attacker who gains agent execution can often inherit the same pod-scoped reachability and use that to defeat the intended containment model, while a too-strict policy can disable the firewall and leave the pod open by default.

Failure mechanism: Kubernetes evaluates NetworkPolicy at pod scope, so the firewall and the agent cannot receive different network treatment when they are colocated in one pod. That collapses the separation needed for selective enforcement and creates either shared exposure or self-blocking control failure.

Impact: The organisation loses confidence in the firewall as an independent control, and any assumption that the agent can be selectively restricted becomes invalid. In practice, that can widen blast radius, complicate incident response, and leave security teams with a control that appears present but cannot reliably enforce the intended boundary.

Practitioner Guidance

What to verify: Check whether the firewall depends on pod-level isolation to function, and confirm whether the agent and control component share the same pod, namespace policy, or network path. If they do, treat the design as structurally unable to enforce asymmetric rules between them.

Decision rule: If the security function must remain authoritative over the agent's network behaviour, place it outside the pod or redesign the trust boundary so the policy engine is not subject to the same enforcement domain as the workload it governs.

What good looks like: The enforcement layer has an independently controllable boundary, the agent cannot bypass it through shared pod privileges, and blocking the agent does not also disable the mechanism intended to inspect or restrict it.

Practitioner takeaway: When a control must govern a workload, do not co-locate it inside the same enforcement scope as that workload, because shared boundaries turn policy into a self-defeating constraint.

Related resources from NHI Mgmt Group

• What breaks when AI agent baselines are defined per pod instead of per deployment?
• What breaks when an AI agent shares access through a Slack channel?
• What breaks when an AI agent shares one credential across tools and model calls?
• What breaks when AI agent access is reviewed only after the fact?