How do sidecar and included deployment patterns differ for Kubernetes agents?

Why This Matters for Security Teams

For Kubernetes-based agents, the deployment pattern is not just an engineering preference. It shapes the trust boundary, token handling, patch cadence, and blast radius when an agent is compromised. Sidecar patterns preserve a cleaner separation between the agent and the workload, while included deployments collapse that boundary into a single image and often a single release path. That difference matters when the agent has access to secrets, APIs, or cluster services.

Security teams often focus on image hardening and miss the operational effect of co-location. An included pattern can make dependency management and rollout simpler, but it also increases coupling between the application lifecycle and the agent lifecycle. Sidecars can reduce that coupling, yet they still inherit the pod’s permissions and network reach if the pod is over-privileged. Current guidance aligns with Zero Trust thinking: reduce standing access, scope tokens tightly, and treat the pod as the real trust unit rather than the container. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the kind of condition that makes either pattern dangerous when governance is weak. In practice, many security teams discover the problem only after an agent inherits application permissions and begins using them more broadly than intended.

How It Works in Practice

In a sidecar deployment, the Kubernetes pod contains both the application container and the agent container. They can share localhost, volumes, and pod identity, which makes the agent useful for tasks like request inspection, policy enforcement, log enrichment, or tool mediation. The main benefit is modularity: the agent can often be updated independently, tested separately, and removed without rebuilding the application image. In an included deployment, the agent is baked into the same image as the application. That can simplify release coordination and ensure version lockstep, but it also means any agent change requires a new image build and redeploy.

From a security perspective, the key question is where authorization is enforced. For agentic workloads, static role assignments are usually too blunt. Better practice is emerging around context-aware controls, short-lived credentials, and workload identity. For example, a sidecar can fetch ephemeral tokens per task and revoke them on completion, while the application container keeps only the minimum permissions needed for its own function. The identity primitive should be the workload, not the human operator, which is why standards work around SPIFFE-style workload identity and runtime policy evaluation is gaining traction. That model fits the guidance in NIST AI Risk Management Framework and the threat modeling approach described in CSA MAESTRO agentic AI threat modeling framework.

That is why NHIMG’s analysis of agentic risk patterns in the OWASP Agentic Applications Top 10 matters here: the deployment model changes how easily an agent can chain tools, inherit trust, and move laterally within a pod or cluster. These controls tend to break down when teams run included agents with broad service account permissions in clusters that still rely on long-lived static secrets.

Common Variations and Edge Cases

Tighter isolation often increases operational overhead, requiring organisations to balance deployment simplicity against containment. That tradeoff shows up quickly in Kubernetes because sidecars are not always the best answer. Some agents need direct filesystem access, shared process context, or extremely low latency, which can make a sidecar pattern practical. Other teams prefer included deployments for tightly versioned agent-app bundles, especially when the agent is effectively part of the product logic rather than a separate security control.

There is no universal standard for this yet, but current guidance suggests treating sidecars as a better fit for security mediation and included deployments as a better fit for tightly coupled application features. The risk is that either pattern can become unsafe if the pod has persistent secrets, overbroad RBAC, or unrestricted egress. A sidecar does not fix bad authorization design, and an included image does not become safer just because it is easier to ship. The stronger pattern is the one paired with least privilege, short TTL credentials, and runtime policy checks.

In real incidents, the failure mode is usually not the container topology itself. It is the way the topology hides privilege accumulation until an agent is already trusted to do too much, which is why NHIMG research on OWASP NHI Top 10 and the broader Kubernetes risk discussion in Ultimate Guide to NHIs should be read together. In practice, included deployments tend to fail fastest in clusters where build pipelines, secrets, and runtime permissions are already blended into one release path.

Related resources from NHI Mgmt Group

• How should security teams authenticate AI agents in enterprise environments?
• How do namespace-scoped policies change Kubernetes access governance?
• Why do IP-based controls fail for Kubernetes workload access?
• How does delegated credentialing differ from forwarding a user token?