Every guardrail you write is a hypothesis about what good code looks like, and the only way to know if it's right is to watch it run. Now you can. When a coding agent hits a Zenable finding, it doesn't just fix or skip it: it files a verdict (applied, deferred, declined, or needs-human) with a structured reason and, when it disagrees, evidence, in the form of real code snippets showing what the rule should still catch and what it wrongly flagged. Your developers grade the guardrails too, with a reaction on any of Zenable's PR review comments.
All of that signal shows up where you work. The detailed findings page puts agent feedback and human sentiment side by side on every finding. A green "94% positive" tells you a rule is landing; an amber "intent mismatch" tells you it's generating noise, before anyone complains.
Then the guardrails improve themselves, but always on your terms. You set the standards, the grading rubric, and the tolerances; your agents do the grading and the legwork; and Zenable's analyzer proposes a refinement only when the negative signal crosses the threshold you set. Rules that are working are left alone, by design. In our own testing, we watched hundreds of requirements rewrite themselves over a two-week stretch. One comment-quality rule narrowed to pure restatements, excluding docstrings, task markers, and license headers, exactly the false positives the feedback exposed.
That's what self-improving guardrails means here: sharpened by your agents, graded by logic you wrote, and refined only within the tolerances you defined. A refinement is only auto-accepted when it clears a policy you wrote, and of course, we built guardrails for our guardrails: you can define the changes that always require a specific approval flow, so you decide when a human stays in the loop and when you'd rather move at the line speed of Zenable's self-improvement loops. Self-improving, never self-governing. More in the requirements and guardrails docs.