Verify JEF-284 pivot-quarantine gates on evidence, not mere reachability+CVE (JEF-322)

[thejefflarson]

Summary

This is a verification + regression-test ticket (JEF-322), not a feature. It answers: does quarantine_targets_on_path's RemotelyExploitable pivot-quarantine trigger (engine/src/engine/reason/proof/chain.rs) require on-pod exploitation evidence, per the JEF-284 design intent ("never a merely-reached pod") and the product thesis (presence ≠ exploitability, ADR-0011/0013/0016) — or does it fire on mere reachability + CVE presence?

Finding: it fires on reachability + CVE presence alone

RemotelyExploitable's condition is node != entry && net_reachable(node) && compromisable(node). compromisable is the static CVE/KEV predicate — the same one used for the compromise-gate walk — not actively_exploited's live-signal one (alert / notable exec / alarming write). No runtime evidence, corroboration, or model verdict is required.

This is sharper than it first looks, because of the actuator side too: Mitigation::is_live_corroborated special-cases every QuarantineWorkload mitigation — including a RemotelyExploitable one — as unconditionally auto-actionable, bypassing the corroborated || promoted + adjudicated + breach_relevant gate that ADR-0013 requires for the entry-foothold lane. ADR-0013 exists specifically to reverse "CVE presence alone auto-cuts" for the entry ("the engine never cuts on mere CVE presence... with no model a foothold is propose-only"). The pivot-quarantine path does exactly what ADR-0013 forbids for the entry, with no model involved at all.

This confirms the tension the ticket describes on a live cluster: the e2e's pivot pod store gets deterministically quarantined (RemotelyExploitable, no model, no alert) purely because it's reachable from the exposed web entry and carries a critical CVE.

What I did

• Traced the exact trigger in chain.rs and the actuator's is_live_corroborated gate in respond/mod.rs, confirmed empirically with tests.
• Added engine/src/engine/reason/proof/pivot_quarantine_tests.rs — a characterizing regression suite (documents, doesn't endorse) that locks the current behavior in place so it can't silently drift further:
  • pivot_reachable_plus_cve_alone_currently_promotes_to_remotely_exploitable — a pivot pod reachable from an exposed entry with a critical CVE and zero runtime evidence still gets RemotelyExploitable at target selection, and Mitigation::is_live_corroborated() returns true for it.
  • entry_foothold_alone_does_not_meet_the_stricter_action_bar — contrast: the SAME chain's entry-side meets_action_bar() stays closed with no corroboration/promotion (ADR-0013's stricter bar), highlighting the asymmetry.
  • pivot_with_live_signal_is_actively_exploited_not_remotely_exploitable — a live signal on the pivot correctly upgrades it to ActivelyExploited (the one shape that DOES carry genuine evidence).
• Added short comments at both trigger sites (chain.rs, respond/mod.rs) citing the JEF-322 finding for future readers.
• No production behavior changed — this ticket is a verification, and per its own instructions I did not silently alter quarantine semantics.

DECISION NEEDED

Per the ticket: since the code fires on mere reachability+CVE (not evidence), this needs an explicit call from the architect between:

1. Model-gate the pivot too — require the model's affirmative verdict (or a live signal) before RemotelyExploitable promotes to a quarantine target/auto-action, mirroring ADR-0013's entry-foothold bar. Closes the asymmetry but narrows JEF-284's original "always contain a remotely-exploitable pivot" guarantee and adds a model dependency to a currently-deterministic, always-available lane.
2. Accept deterministic pivot-quarantine as intended — the asymmetry is deliberate: full isolation of a non-entry pod is a narrower blast radius than the entry-quarantine/foothold-promote lever (ADR-0022 precedence explicitly excludes the entry from this set), so the bar for it doesn't need to be as high, and shadow-mode + blast-radius + scope gates in decide() still apply before anything actually applies live. Close JEF-322 with no code change beyond this verification's regression tests.

I did not pick between these — it changes quarantine's live-actuation surface, which is exactly the kind of call the ticket asks the architect to make explicitly rather than have an agent decide silently.

Test plan

• cargo fmt — clean
• cargo clippy --all-targets -- -D warnings — clean
• cargo test — 926 passed (923 prior + 3 new), 0 failed, 2 ignored
• /soundcheck:pr-review — comments-only diff + new test file, no Critical/High findings
• /simplify — deduplicated repeated graph-fixture code across two new tests into one parameterized helper

Closes JEF-322

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01VtjoJttCvBY4dzCoE4f9vP

[thejefflarson]

Architect note (INTEGRATE) — merging the verification/tests as-is; recording the open decision.

The characterizing suite + doc comments are merged on green: they lock current behavior in place without endorsing it, and touch no quarantine/actuation/corroboration logic (non-test files are comment-only; the unconditional QuarantineWorkload auto-action in Mitigation::is_live_corroborated that the tests pin is pre-existing on main, not introduced here). JEF-322 (the verification) is complete.

Open decision recorded for a /plan-sprint follow-up (NOT resolved here — this is a product/thesis call, not an integration one): quarantine_targets_on_path's RemotelyExploitable trigger fires on reachability + static CVE presence (compromisable), with no on-pod live evidence and no model verdict — and the actuator treats every QuarantineWorkload mitigation as unconditionally auto-actionable, bypassing the corroborated || promoted gate ADR-0013 imposes on the entry-foothold lane. That is in tension with ADR-0013's "presence ≠ exploitability, CVE presence no longer auto-cuts." Two ways to resolve, to be decided in an ADR:

1. Model-gate the pivot lane (require corroboration or an affirmative verdict before RemotelyExploitable becomes auto-actionable), bringing it in line with the entry; or
2. Ratify deterministic pivot-quarantine as intended (the pivot's reachability+CVE is a different, weaker-blast-radius containment than the entry cut, and is accepted as such) — in which case ADR-0013's scope should be amended to state the asymmetry explicitly.

No code changed to resolve this; filing the decision as an ADR + ticket is the main loop's follow-up.

Minor non-blocking nit for that follow-up: the new chain.rs doc comment has a garbled sentence ("...a deliberate, verified asymmetry, not an\n and the ticket's DECISION NEEDED...") — a missing clause. Cosmetic, no compile/behavior impact; worth tidying when the ADR lands.