SuperAPI AI Directory

dvalincode

Provider-neutral, local-first CLI coding agent (Chat/Cowork/Code modes) built for governance: org policy engine, enforced network egress, and a verifiable hash-chained audit trail. Works with any OpenAI-compatible endpoint (DeepSeek, OpenAI, Claude via OpenRouter, Groq, Ollama). Zero runtime deps. M

Open website

About this tool

Dvalin is an independent security verification runtime that sits between code generation and merging, serving humans, coding agents, and CI. It does not ask the model that wrote the fix whether the fix works; instead, it rescans on its own, runs the project's own tests, and reads the exit codes of the processes it starts, ultimately producing a Verified Fix Record—a small JSON file that anyone can re-derive offline on a laptop with no network and no Dvalin state.

Key capabilities

  • Security scanning: built-in rules cover injection, hardcoded secrets, XSS, eval, and unsafe shell usage. The default policy runs only Dvalin Built-in, so the first scan works with no configuration. Engines such as Snyk Code (SAST) and Snyk OSS (dependencies) can be explicitly added as needed.
  • Automatic fix loop: --until-clean turns a single fix attempt into a bounded loop. The executor edits the code, Dvalin rescans with the same engines and runs the project checks itself, sending back to the executor only the issues that still exist (targets still present, newly introduced findings, the last few lines of output from failed checks, added suppressions) so it can continue fixing. Dependency-type findings are prioritized.
  • Independent verification: dvalin verify, the MCP dvalin_verify_findings tool, single-round --fix --verify, and CI reverify all use the same judgment logic, producing a dvalin-fix-record/v3 record. The record notes what the scan actually covered, and it is judged a failure if the fix merely hid the finding (such as deleting a vulnerable file, deleting a test, or deleting an assertion).
  • Anti-evasion checks: rejects common agent tactics for "quieting the scanner," such as moving the vulnerability point to a sibling API of the same kind (eval → new Function, exec → spawn with shell: true), deleting a vulnerable file, or deleting a test or assertion. For code findings, the loop first requires a test-only reproduction case, and it must fail on the unfixed code (assertion failure, not a missing runner).
  • Merge readiness based on the current trunk: --rebase-onto rebases the fix onto upstream before starting and after each round, then judges there. On conflicts, it hands only the conflicted files to the executor and tells it "do not run git"; Dvalin continues the rebase itself.
  • CI and pull requests: Provides an example workflow docs/examples/dvalin-fix-loop.yml, which can re-execute records on a PR (reverify: true), re-scan base and head, re-run checks, must fail if a fix is reverted, must pass after restoration, and then sign with the CI key.
  • Installation-free PR checks: findings appear as inline comments in the PR diff and in the Security tab, with no API key or model required, and scanning is deterministic and runs locally. diff: true reports only the lines changed in the PR, enabling the gate to block issues newly introduced by this change.
  • Signing and trust: after using signing-key, new records are signed with Ed25519 (based on their hash). The key is removed from the environment before project checks run, so code cannot read it. Records that are unsigned or signed only by an unspecified key fail under --trusted-key.
  • MCP server: any MCP-capable agent can call it. dvalin_scan accepts diff: "uncommitted" and reports only what the agent just wrote. dvalin_begin_verification records the local workflow, dvalin_get_finding retrieves findings by fingerprint, dvalin_verify_findings requests an independent re-scan and returns a Verified Fix Record. dvalin_verify_fix can re-derive the record offline.

How to use

  • 30-second no-install trial run: run the built-in rules against the current directory and print findings. No account, model, or configuration required, and code never leaves the local machine.
  • Configure policy: name engines and set gates and suppression rules in dvalin.security.json, which can be committed with the repository. Suppressions require a reason and can specify an owner and expiration date.
  • Installation and integration: the repository provides a GitHub Action example, MCP configuration commands (automatically adapting to VS Code's servers and Cursor's mcpServers), and a plugin payload containing both Codex/Claude dual-native manifests plus a shared security gate skill.

Use cases

  • After a human or AI agent writes code, independent security verification is needed before merging.
  • Incremental "no new high-risk findings" gate in CI.
  • Let a coding agent writeand then request an independent judgment itself, without trusting the author.
  • Need offline-reviewable proof of fixes for release tasks, other repositories, or auditors.

Limitations

  • The record only states: these findings have disappeared, and these checks were observed to pass. It does not claim the code is safe, and Dvalin does not allow itself to be interpreted that way.
  • Re-derivation can only prove that the record is internally consistent; it cannot prove that the record was issued by the actual runner. This must be remedied by re-executing and signing on the runner.
  • Details not covered (such as specific pricing, platform support scope, and performance metrics) are not currently provided.
  • License is MIT.