vulnerability-remediation.md · Applied AI
Vulnerability remediation
A security workbench that shows whether a patch reached every affected target, why a case remains open and who needs to act next.
- TypeScript
- Next.js
- Tailwind CSS
- Fastify
- LangGraph
- Claude
- PostgreSQL
- Docker Compose
A patch can be merged while a production target still runs the vulnerable build. This workbench helps a security coordinator follow the gap between an approved change and a verified deployment.
Each case connects an advisory, service owner, artifact inventory, required checks and runtime evidence. It shows what prevents closure and who needs to act next. All services, deployments and identities in the demonstration are synthetic.
Archive date: 30 July 2026. Implementation and evidence reviewed on 24 October 2026.

Synthetic Orders checkpoint in rules-only mode, with no model call. Framed crop of the actual workbench.
How it works
The operator inspects the evidence for every target in scope. A pure policy evaluates whether the fixed artifact, approved change, checks and observations support closure. Missing or stale evidence leaves a named blocker.
A bounded LangGraph agent can investigate those blockers and draft a next step with evidence references. A person reviews the draft; the agent cannot approve, merge, deploy or close a case. Human commands also require the exact case revision, so a stale approval is refused.
History preserves earlier decisions. If a later observation shows a rollback to the affected artifact, the case reopens with the superseding evidence.

Synthetic rollback in rules-only mode. The framed assessment crop explains why the earlier closure no longer holds.
Results and scope
The verification record covers application checks, stale approval, rollback, recovery and restore on the final pre-publication build. The separate synthetic agent evaluation found no advantage over the deterministic investigator: decisions tied, and grounded findings remained weaker.
There is no real runtime-observer connector, so the application cannot verify a real deployment. It is a local, single-operator experiment, not production security software.
The Next.js workbench, Fastify API and agent worker run in one application container with separate PostgreSQL. The public repository and quickstart run without a model key. Read the design and evaluation article for the evidence behind these choices.