Every platform team eventually learns the same lesson: a policy that only says "denied" gets bypassed by Friday. I have watched carefully-written Kyverno and OPA rules rot into decoration because they told engineers what they couldn't do without saying why — or what to do instead. Guardrails developers keep follow three rules.
Warn before you block
Every new rule ships in audit mode for one sprint. Violations post to the team's channel with a link to the fix, and only then does the rule start blocking. By enforcement day nobody is surprised, because the rule has already proven it only fires on real problems.
- Audit mode first, with violations routed to the owning team.
- Every denial message names the fix, not just the rule number.
- Exemptions are time-boxed pull requests, not back-channel favors.
Explain the incident behind the rule
A rule that says "containers must set memory limits" invites a shrug. The same rule with "checkout throttled every Black Friday for three years because of copy-pasted limits" gets kept. I put the story in the rule's description field, one sentence, so the denial carries its own justification.
Measure bypasses, not just blocks
The health metric for policy-as-code isn't how much it blocks — it's how rarely teams ask for exemptions. When exemption requests spike, the rule is wrong or the golden path is missing. Either way the platform team has work to do, and the data tells them exactly where.
Write rules like you write error messages: for the tired engineer reading them at midnight. Do that and the guardrails stop being the team's adversary and start being its memory.
- Policy as Code
- Kyverno
- OPA
- Platform
