Included Deployment

What Included Deployment Means in Practice

Included deployment is a packaging pattern, not a security control by itself. The application and monitoring agent ship together in the same image, so deployment becomes simpler, but the two components now share release timing, runtime boundaries, and often the same trust envelope.

That coupling is the defining trade-off. What you gain in convenience, you lose in independence: the agent cannot be updated, replaced, or removed as cleanly as it could be in a separate deployment model, and the application image now carries more operational responsibility.

Why Included Deployment Changes Troubleshooting and Governance

Because the monitoring agent travels with the application, the build and release pipeline has to treat observability code as part of the shipped artifact. That can help standardise telemetry, but it also means a change to logging, metrics, or tracing code is no longer a sidecar concern, it becomes part of the application release itself.

This matters for governance because ownership is less clean. Teams must decide who approves the agent version, who is responsible when the agent affects startup or performance, and how to separate an application defect from an observability defect when both are delivered together.

Included deployment also reduces troubleshooting flexibility. If the agent consumes resources, fails to initialise, or behaves unexpectedly, the application and its monitoring layer are tied together unless the image is rebuilt or replaced.

Containment, Isolation, and Operational Blast Radius

The main architectural consequence is reduced separation. When the agent and application share the same container image, a failure in one can more easily affect the other, and the image may expose more runtime surface than a design that isolates monitoring externally.

That does not make the pattern inherently unsafe, but it does raise the importance of least functionality, image hardening, and careful review of what the bundled agent can access. A bundled monitoring component should be treated as production code with real operational impact, not as a harmless add-on.

For readers comparing deployment models, the practical question is whether the convenience of a single artifact outweighs the loss of modularity, especially in environments where rollback speed, service isolation, and fault containment matter.

When Included Deployment Is the Right Trade-off

Included deployment is most defensible when the application and monitoring requirements are tightly coupled, the team wants a repeatable single-image release process, or operational simplicity is more valuable than component independence. It is a pragmatic pattern when the deployment unit must always carry the same observability baseline.

It is less attractive when the monitoring layer changes frequently, when different teams own the application and the agent, or when you need to isolate failures and lifecycle decisions. In those cases, a separate sidecar or external instrumentation model often gives cleaner control boundaries.

A useful test is whether bundling the agent changes only packaging, or whether it also changes how you govern updates, diagnose failures, and contain runtime impact. If the second effect is material, the deployment pattern deserves explicit architectural review.

Risk and Threat Considerations

Bundling a monitoring agent with the application can increase exposure if the agent is compromised, misconfigured, or granted broader access than it needs. The same packaging convenience that simplifies rollout can also widen the blast radius when the shared image is reused across environments or promoted without careful review.

Failure mechanism: The monitoring component inherits the application’s deployment path and runtime trust boundary, so a weakness in the bundled agent, image contents, or update process can affect both observability and application integrity at once.

Impact: Organisations can lose containment, introduce harder-to-isolate operational failures, and create a more attractive target for abuse of the monitoring layer, especially where the agent has visibility into logs, process data, or internal service traffic.

Practitioner Guidance

Why practitioners should care: Included deployment should be chosen deliberately, not by default. Treat it as a packaging decision that also affects ownership, rollback, and fault isolation, because those operational consequences are often larger than they first appear.

Common misunderstanding: Teams sometimes assume that bundling the agent makes the system easier to manage end to end. In practice, it can make upgrades and incident response harder, because observability changes now ride along with the application release cadence.

Practitioner takeaway: Use included deployment when the simplicity of a single artifact clearly outweighs the loss of separation, and avoid it when you need independent lifecycle control or stronger containment.

Related resources from NHI Mgmt Group

• How do sidecar and included deployment patterns differ for Kubernetes agents?
• What are the main reasons AI agents struggle to achieve enterprise-scale deployment?
• When should organizations reconsider the deployment of AI agents?
• Why is it necessary to address authorization challenges in AI agent deployment?