How CamelHive works

A production-readiness audit for AI-built code: a fixed snapshot, a public catalog of checks, and a result that shows what it couldn't determine — never a silent pass.

One snapshot, five stages

An audit runs against a single immutable snapshot — never a live repo, and a snapshot is never updated in place. Re-auditing the same commit takes a new snapshot, so a result never drifts under you.

00
Snapshot
The commit is cloned once and frozen. Every finding points to where it was seen inside that frozen copy: a file and line when the rule is about a line of code, a file or directory when the rule is about a file, and the repository itself when the rule is about something that is missing. Nothing cites the branch as it stands today.
01
Deterministic tools
Scripts and static checks resolve what they can resolve without a model — the fastest, cheapest, and most repeatable part of the catalog.
02
Agent
What the tools leave open goes to a model that reads the snapshot and proposes a verdict with cited evidence. It never reports outside the catalog's own rules.
03
Adversarial review
A second pass tries to refute each proposed finding before it's reported. A citation that doesn't hold degrades the finding — it doesn't get reported as fact. A finding the second pass never reached, for any reason, is reported as undetermined and marked as unreviewed — never as confirmed.
04
Resolution
What still can't be closed is reported as undetermined, with the specific question that's missing — never dropped, and never counted as a pass.

"We don't know" is a result, not a gap

Every rule closes as pass, fail, not applicable, undetermined, or excluded by the client's own declaration. An undetermined finding carries the reason it couldn't be closed — access we didn't have, a call that needs a person, evidence that needs a retry — and it is never rendered as a pass.

A score never travels without its coverage

A score is computed only over the rules that resolved to pass or fail. It always ships next to how many of the catalog's rules that covers — a 65/100 on 40 rules and a 65/100 on 180 rules are not the same claim, and this page never lets them look the same.

Our team can issue a signed, verifiable attestation

For a finished audit, our team can issue a signed, dated attestation: a public verification link, the scope actually covered, and what the client itself declared as public or excluded. How to verify one you're handed.

The full catalog is public

242 checks, versioned and citable by ID — 185 of them active today. Every check names its area and severity, and whether it's resolved by a deterministic tool (41) or reaches the agent (201).

Browse the standard

Open-source tools our audits run

When a repository contains what they check, some rules are resolved by these tools, pinned to an exact version, instead of by a model. Each keeps its own license and is run unmodified by us.

Gitleaks — MIT — secrets in the git history
Trivy — Apache-2.0 — known vulnerabilities in Python dependency files (requirements.txt, poetry.lock, Pipfile.lock)
Opengrep — LGPL-2.1 — JavaScript, TypeScript and Python code patterns, with rules written by us

CamelHive is not affiliated with, sponsored by, or endorsed by these projects or their maintainers.

What each tool measures, per its own documentation

This is a scope comparison, not a results comparison — nothing here claims CamelHive finds more or finds it better. A results comparison on the same commits is in progress. Researched and dated 2026-09-07.

Capability	Semgrep / CodeQL	Snyk	SonarQube	Corgea / ZeroPath	CodeRabbit / Greptile	Human audit	CamelHive today
Vulnerabilities in code	yes	yes	yes	yes	in the diff	yes	yes, recall not measured
Dependencies & secrets	yes	yes	partial	yes	no	manual	yes, deterministic
Reliability, scale, data, architecture	no	no	quality only	no	opinion	yes	yes, across the catalog
Score with stated coverage	no	no	quality gate, no coverage	no	no	no	yes
Abstention as a result ("couldn't determine")	no	no	no	no	no	sometimes	yes, with a stated cause
File:line evidence verified against the snapshot	yes	yes	yes	source-to-sink	cited, unverified	in the report	yes, plus adversarial review
Public badge	no	no	yes, AI Code Assurance	no	no	no	designed, not published
Signed attestation with client declarations	no	no	no	no	no	attestation letter (pentest)	yes
Report for a third party	no	reports	reports	reports	no	yes, PDF	in progress
Own reliability benchmark, published	Semgrep audited its own	n/a	3.2% false positives, self-reported	recall published	third-party	no	precision published, recall not
Reference price	$0–40/mo	per seat	Community free; PR paid	$350–1,000+/mo	$12–40/seat	$500–3,000/audit	per audit

Green: does it, per its own documentation. Amber: partial, or with caveats. Red: doesn't. The CamelHive column is what exists in the repo today, not what's planned.

Sources

What we've measured so far

Of 98 findings from a CamelHive audit, adjudicated blind by two independent human reviewers: 65 of 98 (66%) are ones the project's own owner would actually fix — the 3 repositories measured gave 53%, 71% and 76%.

93 of 98 (95%) are true by the letter of the rule after the two reviewers cross-checked each other's calls — the 3 repositories measured gave 92%, 94% and 97%.

Measured 2026-09-06 against catalog v3.7.0 on three public repositories built with AI, deepseek-v4-flash. Not a claim about recall, and not a comparison to any other tool.