Progmune

AI Trust Decision Engine for AI-generated software.

Verify AI-generated code before it reaches production. Progmune checks whether your AI-generated code follows correct protocol lifecycles — TLS handshakes, auth flows, payment integrity, resource management — violations that SAST and SCA tools cannot see because they span sequences of function calls, not single statements.

Progmune doesn't trust what the model says. It verifies what the program actually does.

One Command

npm run sdk src/server.ts --explain

Output: APPROVED / NEEDS_REVIEW / BLOCKED — with Trust Score, evidence, and repair suggestions.

Two Paths: Intercept or Verify

Progmune covers two code sources with two complementary mechanisms:

This is the core product thesis: verify at generation time, not after the fact. LLM outputs are proposals; the state machine is the referee. LLMs can be persuaded — state machines cannot.

What Progmune Detects

AI code generators produce syntactically valid code that often violates protocol lifecycles — the correct sequence of operations like open→read→close or auth→validate→respond. These violations are invisible to traditional static analysis.

Source-level detections use an extractor-marker architecture: the IR extractor performs taint tracking, import resolution, and cross-file analysis (templates, module constants), emitting synthetic markers that rules consume — zero pipeline changes, fully auditable.

Quick Start

npm install progmune-runtime

# Verify a file — get a Trust Decision
npm run sdk src/server.ts

# Full explanation with evidence and repair suggestions
npm run sdk src/server.ts --explain

# Trust check (CI-ready JSON output)
npm run trust -- --project . --json

# Run benchmark suite
npm run precision:all

The Trust Decision

Progmune's output is a decision backed by evidence, not a raw list of findings:

Critical violations → hard BLOCK regardless of score. Enterprises care about "can I deploy?" not "is my score 58 or 61."

→ Trust Decision Model

Coverage

Progmune is honest about what it can and cannot verify.

Framework adapters: 2/13. Express ✅ and tRPC ✅ have dedicated detectors; Next.js has version-aware governance; NestJS is partial. Django, FastAPI and 8 more remain — framework adaptation is the #1 product gap.

What Progmune does NOT cover (honest boundaries)

• TS-side taint-based injection flaws — the source-level SQLi/XSS/SSRF detections ship for Python; the TypeScript extractor is name/call-based, so TS injection classes remain uncovered (documented, not hidden).
• SCA / dependency vulnerabilities — hallucinated package names, supply-chain issues. Separate tooling exists for this.
• Runtime behavior — Progmune is static analysis only; no DAST/sandbox execution.
• Framework internals — well-known framework dispatch/cache machinery (e.g. django-unicorn internals) can produce a small number of boundary false positives; they are documented per-corpus in the benchmark gold files.
• Known failure boundaries are documented rather than hidden: if Progmune cannot verify a language (e.g. Go), Confidence is lowered instead of pretending 100%.

→ Full Coverage Matrix

Benchmarks

Public, reproducible precision data. All numbers measured against gold-annotated benchmarks.

TypeScript (Blind Benchmark v6 — 100 projects)

Python (Blind Benchmark v1 — 90 projects)

Real-world validation (PyGoat, OWASP vulnerable-by-design Django app)

→ Real-world validation report · Benchmark baseline

C (Gold Benchmark — research status)

C analysis is research-only: gold benchmark F1=16.5% across 4 repos (curl, libssh, nginx, openssl). The bottleneck is rule coverage, not context. L3 (cross-function) was terminated with data; L4 (pointer/CFG) is a multi-year research problem and not planned. See C Language Status for the full picture and reasoning.

P0-P3 Rule Injection (2026-08)

• +19 new detections across 10 TS projects, 0 false positives across 6 C repos + PostgreSQL
• Bootstrapping deadlock broken: all 21 protocol namespaces now have rule vocabulary
• excludePatterns + languages architecture for FP management

→ Two-Hump Report · P0-P3 Final Report

Architecture

SDK (src/sdk.ts)           verify() → APPROVED / NEEDS_REVIEW / BLOCKED
  └─ Trust Engine           4-dimension scoring → Decision
       ├─ Policy Engine     Enterprise policy enforcement (ALLOW/WARN/BLOCK)
       ├─ SSG Validator     Protocol state machine verification
       ├─ Protocol Detector  Regex-based protocol step detection (22 detectors)
       ├─ IR Extractors     TypeScript (ts-morph) + Python (ast module) → function IR;
       │                    source-level markers: taint tracking, import resolution,
       │                    qualified call chains, cross-file template analysis
       ├─ Repair Executor   detect → plan → fix → validate → commit/rollback
       └─ Knowledge Base    31 domains, 140 rules, evidence chains

Interfaces

Scientific Foundation

Progmune is built on the premise that LLM outputs are statistical performances, not reasoning — a view developed by Subbarao Kambhampati et al. in the position paper "Stop Anthropomorphizing Intermediate Tokens as Reasoning/Thinking Traces!" (arXiv:2505.22285, 2025) and elaborated in his ICML 2026 talk "On the Role of Verifiers and Thinking Traces in Reasoning Models". Rather than trusting what the model says about code, Progmune verifies what the program actually does — using protocol state machines, IR extraction, and evidence-backed decision chains.

Coverage-gap analysis borrows the "two-hump problem" terminology as a cross-domain analogy from Sergei Gukov's work in mathematical physics (the Andrews-Curtis conjecture in group theory, 2026) — it describes a bimodal coverage distribution, not a collaboration. See Two-Hump Report for the full methodology.

→ Investor Whitepaper · Trust Decision Model

Contributing

See CLAUDE.md for architecture and code conventions, and CONTRIBUTING.md for the development workflow.

High-impact contribution areas:

• Framework adapters (Express, Next.js, FastAPI) — the #1 product gap
• Python verification rules — extend beyond TypeScript
• Bug fixes for existing detectors and safeguards

Status

• Runtime Pipeline: Detect → Explain → Repair → Validate (L1–L4)
• Trust Engine: 4-dimension scoring with binary explainability gate
• MCP Tools: 19 — progmune_trust_check, progmune_score, progmune_policy_check, progmune_certify, and more
• Framework Adapters: Express ✅, tRPC ✅, NestJS partial (2/13)
• Knowledge Base: 31 domains, 148 protocol rules, 22 detectors, 26 safeguards, PLSB 13/13 categories — plus 15 source-level detection rules (Python)
• Corpus: 2,500+ trajectories across 6+ repositories; blind benchmarks 100 (TS) + 90 (Python) projects; real-world validation on 4 application repos
• Current focus: Enterprise PoC validation + remaining framework-internal boundary FPs

License

MIT — LICENSE