Harness Shifts Argo CD Plugin to Explicit Opt-In Model for Manifest Generation

Harness released an update to its Argo CD GitOps plugin architecture, shifting application detection from implicit repository matching to explicit, per-application declarations. Under the revised behavior, the Harness GitOps plugin no longer automatically claims and processes applications simply based on repository contents. Instead, teams must explicitly configure each Argo CD application using either the `spec.source.plugin.name: argocd-harness-plugin` field directly on the Argo CD Application custom resource or by committing a dedicated `.harness.yaml` marker file located specifically within the application's source path. This update addresses a subtle yet persistent security and operational hazard common in enterprise GitOps environments: implicit tool execution. In large, multi-tenant Kubernetes setups where hundreds of applications share repositories or deployment agents, automatic plugin execution creates unnecessary blast radiuses. If an intermediary plugin automatically executes against every discovered manifest directory, misconfigurations or repository restructuring can route untrusted manifest generation through proprietary rendering pipelines without operator consent. Moving control from the ambient agent level to the explicit application boundary restores strict least-privilege scoping across declarative deployment definitions. This move fits into a broader cloud-native trend centered on tightening software supply chain controls and Config Management Plugin (CMP) isolation within the Argo CD ecosystem. As organizations scale out GitOps across disparate teams, the open-source community and commercial vendors alike have steadily moved away from implicit, repo-wide conventions toward strict declarative boundaries. Isolating sidecar plugins and manifest generators ensures that each application manifest is rendered using only authorized toolchains, mirroring wider hardening patterns across Kubernetes controllers and admission paths. In practice, engineering teams must review and audit their existing Harness-managed Argo CD applications prior to upgrading or recreating their GitOps agents. Workloads relying on legacy auto-detection will immediately stop resolving dynamic variables, environment overrides, and secret expressions once upgraded without the explicit identifier. Platform teams should automate this migration by patching Application manifests via GitOps or embedding `.harness.yaml` into Helm and Kustomize boilerplate templates. While the change introduces a small configuration burden, the resulting isolation guarantees that manifest rendering remains fully auditable, deterministic, and protected from unintended plugin execution.