Vulnerability remediation needs deployment evidence

A dependency update passes its checks and merges. One production target receives the new build. Another still runs the affected version.

For the engineer handling the pull request, the change is complete. For the security coordinator responsible for the service, work remains. Someone needs to connect the advisory, approved change, built artifact and running targets before saying the vulnerability is resolved.

The vulnerability remediation workbench makes that evidence visible in one case. It combines explicit closure rules with an agent that investigates missing information and drafts a next step. The demonstration uses synthetic services and deployments; it does not observe a real production environment.

Archive date: 30 July 2026. Implementation and evidence reviewed on 24 October 2026; the archive date does not date the experiment.

Define what “fixed” means

The case belongs to a particular service, environment and affected component. Its scope matters: checking one healthy target tells us nothing about an omitted target.

For an affected case to close as fixed, every target in scope needs a current observation of the fixed artifact. That artifact must connect to the approved change, and the required checks must have passed. Missing, conflicting or stale evidence keeps the work open with a reason.

This distinction changes the operator's next action. A merged change awaiting rollout needs deployment evidence. A failed compatibility check needs engineering attention. An unowned service needs an owner. Asking every team to “fix the vulnerability” hides these different problems.

Recorded synthetic Orders checkpoint, cropped to the first viewport. Fixture data, simulated sign-in and rules-only mode; no model call.

Keep the decision open to new evidence

Closure is a conclusion about evidence at a particular time. It cannot promise that the environment will stay unchanged.

In the recorded Orders story, revision 6 supports closure. A later observation shows one target running the affected artifact again. Revision 7 reopens the case and identifies the rollback that superseded the earlier decision. The old decision remains available in history, so a reviewer can reconstruct what was known then.

Synthetic rollback scenario in rules-only mode. This framed detail crop names the target and the observation that invalidated closure.

Human approval needs the same discipline. A decision names the proposal and case revision the person reviewed. If another session changes the case, the API refuses the old form. Refetching preserves the draft for another review instead of silently applying it to new facts.

Framed review-dialog crop from the synthetic approval scenario. Rules-only mode; the refusal is enforced by the API.

Give the agent an investigation job

The LangGraph agent reads a bounded case snapshot through nine scoped tools. It can inspect evidence, identify a gap and draft an action or question with supporting references. It cannot edit a repository, approve a change, merge code or deploy anything.

A draft pauses for durable human review. Accepting that draft still leaves the normal operator command to perform. The closure guard also refuses a closure draft unless the deterministic policy already supports it.

The implementation keeps these responsibilities explicit: a Next.js workbench presents the case, a Fastify API accepts authorized commands, and a worker runs investigations. PostgreSQL retains history, review waits and spending records. These three processes share one application container, with the database separate. The architecture guide documents the shared process boundary and recovery behavior.

Measure useful investigation separately

Correct decisions alone made the agent look stronger than its evidence justified. On the fresh synthetic evaluation, it produced 42 correct decisions across 14 cases run three times each. Only 18 of those 42 runs met the grounding criteria, which required the necessary reads and supported findings.

A deterministic investigator tied every case's decision. After a documented baseline correction, it grounded 7 of 14 cases, compared with the agent's 42.9% of runs. This set shows no measured agent advantage. The evaluation recorded zero false closures, but the closure guard enforces that boundary by construction. Evaluation and correction.

The separate 24 October verification record reports passing application gates, stale-approval and rollback checks, restart recovery and fresh-volume restore. It records the final pre-publication build, not a new live-model evaluation; publication edits are disclosed alongside it.

The public repository runs locally without a model key. Its largest missing integration is a trusted runtime observer. The GitHub reader only prints metadata and does not add it to case evidence. Until actual inventory and runtime observations are integrated and validated, the workbench demonstrates how to reason about closure, not how to certify a real deployment. Whether its agent reduces a coordinator's effort remains an open question.