Vault Sprawl Risk Patterns and a Secrets Governance Model for Multi-Team CI/CD

Vault sprawl in multi-team CI/CD is usually a governance failure, not a tooling failure. The practical model that works is: short-lived identity-based access (OIDC/workload identity), path ownership boundaries, policy-as-code with review gates, and measurable rotation/usage controls per team. The Problem As teams scale, secrets handling drifts into four repeating failure patterns: Sprawl pattern What breaks Typical incident One shared Vault namespace for many teams No clear ownership, broad blast radius Team A pipeline can read Team B secrets Long-lived CI tokens in repo/org secrets Rotations lag, credentials leak and persist Exposed token keeps working for weeks Inconsistent secret paths/names Automation and auditing become brittle Rotation scripts miss critical paths Manual exceptions outside policy review Shadow access accumulates Emergency grants never removed Kubernetes guidance still warns that native secrets can be mishandled without encryption-at-rest and strict RBAC. The same