Currently, Harness defaults to running all pods and containers in privileged mode, which is not aligned with container security best practices. In most use cases, elevated privileges are unnecessary and introduce avoidable security risks. Problem: Privileged containers have unrestricted access to the host system, which increases the attack surface and violates the principle of least privilege. Many enterprise environments enforce strict security policies that prohibit privileged workloads, requiring additional configuration or workarounds to use Harness. This default behaviour can lead to non-compliance with internal security standards and external regulatory requirements. Proposed Solution: Change the default behaviour so that all pods and containers launched by Harness run in non-privileged mode by default. Allow users to explicitly opt-in to privileged mode only when required, with clear documentation and warnings about the associated risks. Provide configuration options at the account, org, and project levels to enforce non-privileged execution as a policy. Benefits: Aligns Harness with Kubernetes and container security best practices. Reduces the risk of privilege escalation and host compromise. Improves compatibility with hardened environments and security-conscious organisations. Enhances trust and adoption among security and compliance teams.