Because a model's answer can change between runs and can be steered by the text it reads, while a release decision must be consistent and explainable. Use the model to rank and explain findings, and use fixed policy rules to decide what blocks a merge or a deploy.
Two jobs, two tools
| Job | Suited to a model | Suited to a rule |
|---|---|---|
| Summarize a finding for an engineer | Yes | No |
| Group related alerts | Yes | Sometimes |
| Suggest a likely owner | Yes, with review | Yes, from CODEOWNERS |
| Decide that a critical flaw blocks a release | No | Yes |
| Prove to an auditor why a build was blocked | Weak | Yes |
The difference is repeatability. A rule evaluates the same inputs to the same outcome. You can read it, test it and show it to an auditor.
What goes wrong without a gate
If the sole thing standing between a finding and production is a model's judgement, then:
- Two runs on the same input may disagree.
- A planted instruction in a ticket or comment may tip the result. NCSC warns models do not enforce a boundary between instructions and data and recommends deterministic controls to limit what a system can do.
- Nobody can explain afterwards why one build passed and another did not.
- A model update can silently change outcomes.
Designing the pairing
- Write the policy first in plain language. For example: block merges that add a dependency with a known exploited flaw, unless an owner has recorded an exception.
- Encode it as a rule in your pipeline, using inputs from authoritative sources such as an advisory feed and your inventory.
- Let the model add context. It drafts the explanation, suggests the fix, and writes the exception request.
- Keep humans on exceptions. A named person approves each waiver, with an expiry date.
- Log both. Record the rule outcome and the model's suggestion separately.
How to tell if your gate is really deterministic
Run the same input through twice. Change only unrelated text, such as a comment, and run again. If the outcome can change, the decision still depends on something that is not a rule. Also check that disabling the model leaves the gate working.
A note on thresholds
Gates need thresholds that people trust. Start in audit mode, measure what would have been blocked, tune the rule, then enforce. This avoids teaching developers to ignore it. A gate that blocks too much gets bypassed, and a bypass is worse than no gate.
See also policy gate vs guardrail for AI-generated changes.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the gate and notice that the outcome follows from stated rules, not from an opinion.
Where Safeguard fits
Safeguard provides policies, gates and guardrails you define yourself, with autonomous remediation off by default and every category on Manual. Try a free scan at https://gold.safeguard.sh/scan.
Quick check
Can a model enforce a policy if I prompt it strictly?
It can follow it most of the time, but it may not every time. Enforcement should be a rule that cannot be talked out of its answer.
Does a gate make the model unnecessary?
No. The model saves reviewer time on explanation and drafting. The gate keeps the decision consistent.
Sources
- NCSC, Prompt injection is not SQL injection: https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
Last reviewed: 19 October 2026.
