Org policy bounds the agent
A company — not the developer — constrains modes, shell commands, paths, tools, and models via dvalin.policy.json. A repo policy can only narrow the machine policy, never widen it.
Policy reference
Any model · local-first · policy-bound · audit-ready — AI coding your security team can actually approve.

Don't take the claims on trust — verify them on your own machine:
curl -fsSL https://raw.githubusercontent.com/arthurpanhku/dvalincode/main/scripts/install.sh | bash
dvalincode trusttrust prints this install's live security posture: the resolved org policy and its hash, per-boundary network enforcement (provider · shell · MCP), and the tamper-evident audit status — the exact evidence a security reviewer needs, straight from the tool itself.
Then let the agent work, and prove what it did after the fact:
dvalincode report verify # re-derive the hash chain of the last run's audit logWindows builds and manual downloads for every platform are on the releases page, with SHA256SUMS.txt and build provenance attestation for each archive.
Run dvalincode bare for an interactive terminal agent with streaming output, inline approvals, and red/green diffs — or dvalincode serve to host the web GUI for browser and remote use. An experimental desktop app ships on a separate pre-release track. All three drive the same agent core.

DvalinCode is an approvable agent runtime, not just another coding agent. The product is the evidence a security, compliance, or platform team needs to safely allow AI coding in finance, healthcare, and other confidential codebases:
dvalincode trust makes the posture self-verifiable.Start with the threat model to see the full attack surface — malicious AGENTS.md, poisoned MCP servers, prompt-injection escalation, egress, audit tampering — each mapped to the control that defends it and the honest residual gap.