Helm v3 release history retention without configurable revision cap or pruning permissions

Helm v3 persists each release revision as a separate object in the configured storage backend, typically a Kubernetes Secret in the release namespace, and retains that history indefinitely by default with no built-in maximum revision enforcement. The helm uninstall command preserves revision history unless --no-keep-history is specified, yet the client does not provide a configurable revision cap or automatic pruning policy. Over time, long-lived clusters accumulate revision metadata that consumes storage quota and complicates audit trails.

Removing stale revision objects requires direct access to the storage namespace, which is frequently broader than the permissions intended for routine release operators. This leaves an unresolved boundary between managing live releases and cleaning up their historical metadata. The same ambiguity applies to automatic rollback during helm upgrade --atomic, where the initiating principal performs the rollback without a separate approval gate or permission check. Because storage backend limits and secret size constraints vary across Kubernetes distributions and Helm versions, the effective retention boundary should be confirmed against the target environment.

Which documented mechanism or external controller should enforce a revision retention limit for Helm v3 releases, and how can storage namespace access be scoped so that release operators may prune only their own release history without gaining broader cluster permissions? Should automatic rollback and hook execution privileges be separated from normal workload privileges through an admission policy or service account boundary?