Dvalincode MCP server

English · 中文 · 🌐 dvalincode.dev

Open security engineering for code written by humans and AI agents. Every repair carries its own proof.

When an agent fixes a security finding, someone has to decide whether the fix worked. Almost every tool asks the model that wrote it — which is the one question a model cannot answer against its own interest.

Dvalin decides instead, and hands you the proof. It re-scans, runs your project's own tests itself, and reads the exit codes from processes it started. Who wrote the repair — our agent, Claude Code, Codex, Copilot, a person — is recorded and never consulted. The result is a Verified Fix Record: a small JSON file anyone can re-check offline, on a laptop with no network and no Dvalin state.

dvalin verify-fix fix-record.json

Fix record 2c9d71ac03e0 · VERIFIED · scan-and-checks
  executor: claude-code (recorded, not consulted)
  targets: 1 before · 0 remaining
  coverage: complete → complete
  introduced: 0 (gate high/new)
  outcome: verified
  ✓ test: npm run test (exit 0)
  audit: run verify-36509f42 @ 414644c75af0

That record says something narrow on purpose: these findings were gone, and these checks were observed to pass. It is not a claim that your code is safe, and Dvalin will not let it be read as one — every record carries what the scan actually covered, and a repair no check could confirm does not pass. The open profile →

A repair is a change, and a change can add as well as remove. So the record also carries what the re-scan saw that the first scan did not, and the gate threshold the verdict was reached under: a fix that removes an eval and introduces an SQL injection is recorded as regressed and does not verify. Neither does a record whose issuer never looked — introduced: not determined fails, because a verifier that skips the question must not score better than one that asks it and finds something.

Shortened. The full README is on GitHub.