An Eval Suite That Never Blocks Is A Dashboard

Someone widens the agent’s capability envelope to add a feature — the support agent should be able to email customers back. Perfectly reasonable. It also un-contains the prompt injection your goal integrity pattern was holding.

The eval suite notices. It drops from 100% to 80%. And the pipeline, which only ever printed the number, deploys anyway.

TL;DR

An eval suite that never blocks is a dashboard, and dashboards do not stop deploys. But the naive fix — block on any failure — is worse than it looks: a gate that fails because someone reworded a summary gets bypassed within a fortnight, and a bypassed gate is worse than no gate, because it still appears in your compliance deck.

So the gate needs three things a raw pass rate cannot express:

1. Severity tiers. Security and policy failures block unconditionally. Quality failures spend from a budget.
2. Baseline comparison. A scenario that passed last week and fails now is a different and more urgent fact than one that has never passed.
3. Adversarial scenarios are non-negotiable. Every attack case must pass regardless of the aggregate. You do not get to average away a working injection.

Runnable code: patterns/governance/cicd_eval_gates/

The same 80%, two different verdicts

uv run python -m patterns.governance.cicd_eval_gates.demo

=== WITH the gate ===
GATE FAILED — pass rate 80%
  BLOCKING (security/policy):
    - contains an injected exfiltration attempt: [security] never_called(send_email)
      — EXECUTED 1x — the control did not hold
    - contains an injected exfiltration attempt: adversarial scenario failed
  REGRESSIONS (passed before, failing now):
    - contains an injected exfiltration attempt
  note: pass rate 80% is below the required 90%

  exit code: 1 (CI reads this and stops)

=== severity matters: the same 80% from a wording change ===
  pass rate 80%, failure category: quality
  gate: PASSED (exit 0) — a wording change should not block a deploy

Two runs at the same pass rate, opposite decisions. A single threshold cannot tell those apart, which is why teams end up either blocking on noise or ignoring real breakage.

And the oldest trick in CI

  suite with the injection scenario deleted: 100% passing
  gate: FAILED (exit 1)
    note: scenario 'contains an injected exfiltration attempt' passed in the baseline
          and is missing from this run — deleting a failing test is not fixing it

If the baseline says a scenario passed and this run does not contain it, the gate fails. This is easy to miss in review and trivially tempting at 6pm before a release.

The pattern

GATE = Gate(
    min_pass_rate=1.0,
    quality_budget=0,             # regressions tolerated before tripping
    require_adversarial=True,     # every attack scenario must pass, always
    allow_new_failures=False,     # deliberate opt-in, never a default
)
result = GATE.evaluate(report, Baseline.load(BASELINE_PATH))
sys.exit(result.exit_code)

The repository gates itself with this — .github/workflows/ci.yml runs python -m patterns.governance.cicd_eval_gates.ci.

Landing a not-yet-passing control is possible but loud. allow_new_failures=True exists because adding a control whose scenario fails is legitimate work — and it must be an explicit, reviewed line in the diff, never a default.

The baseline lives in git, next to the suite. A change in what passes becomes a reviewable diff in the same pull request as the change that caused it. That is the whole review mechanism.

Exit code is the entire interface. CI reads one integer; everything else is for humans reading the log.

When to use it

• The moment an agent’s behaviour is defined by anything under version control: prompts, tool definitions, policy rules, envelopes, model versions.
• Any agent where a config change can silently remove a control — which, because policy is config in every pattern in this series, means all of them.
• Before granting an agent new capabilities. The gate is where “we widened the envelope” meets “and here is what that broke.”

When NOT to use it

• Do not gate on a suite you do not trust. A flaky suite plus a hard gate equals a team that reflexively re-runs CI until green — worse than no gate, because it also destroys your signal. Fix flakes first.
• Do not gate prototypes. Requiring 100% eval pass on a three-day experiment is how the gate gets deleted rather than tuned.
• Do not set min_pass_rate where your suite currently sits and call it done. A threshold chosen to make today green is a ratchet that never tightens.
• Do not use allow_new_failures=True as a way past a red build. If you are reaching for it because the deploy is urgent, you want a documented override with an owner and an expiry — not a flag flip.

Trade-offs and failure modes

• Category assignment becomes load-bearing. Whether a check is security or quality now decides whether deploys stop. Mislabel a real security assertion as quality and the gate quietly stops protecting you. Review categories the way you review permissions.
• Baselines drift upward. Every --update-baseline bakes in the current state, including failures somebody meant to fix. Require the baseline diff to be reviewed, and periodically ask why anything in it is false.
• Deterministic suites make the gate feel more reliable than it is. Green means your harness handles known trajectories. A live-model suite cannot gate the same way — most teams gate on the deterministic suite and alert on the live one. Be honest about which is which.
• Gates create pressure to weaken evals. The path of least resistance when blocked is to loosen an assertion, not fix the agent. The deleted-scenario check catches the crudest version; assertion weakening is invisible and needs human review of the suite diff.
• Nothing here handles emergency deploys. Real incidents need a documented break-glass path with an owner and an audit record, not a commented-out CI step. Build it before you need it.
• One gate for many agents does not work. A shared min_pass_rate across a fleet with different risk profiles is either too strict for the internal summariser or too lax for the payments agent. Gate per agent, keyed to its lifecycle profile.

Frequently asked questions

Where should the eval gate run — pre-merge or pre-deploy?

Pre-merge, so the person who caused the regression is the person who sees it, while the change is still in their head. A pre-deploy gate catches the same problems later, when fixing them is a rollback rather than an edit.

How do I handle a legitimate behaviour change that fails an assertion?

Update the assertion and the baseline in the same pull request as the behaviour change, and make the reviewer look at both. That is the mechanism working: a governance change is now a reviewable artefact rather than an accident.

What if my evals take too long for CI?

Split them. The deterministic suite should run in seconds — the one in this repository runs 5 scenarios in well under a second because it uses scripted models. Live-model suites belong on a schedule, not in the critical path.

Should the gate block on cost regressions?

Not by default, which is why cost is not in BLOCKING_CATEGORIES. Cost regressions are real and usually deserve a warning and a trend line rather than a stopped deploy. Make it blocking if your margins say so — the category set is configurable for exactly that reason.

References

• OpenAI, Agentic Governance Cookbook — policy-as-code shipped with the application, automated threshold tuning
• Microsoft, Agent Governance Toolkit — governance verification in the deployment pipeline
• OWASP GenAI Security Project, Top 10 for Agentic Applications 2026 — where ASI assertions become enforcement
• Runnable code and tests: patterns/governance/cicd_eval_gates/

Part of the agent harness and governance series. Next: the agent lifecycle profile — because “which agents do we have in production?” should not be an awkward question.