Security audit
Security checks for vulnerabilities and agentic risk
This verifier can approve fabricated certificates despite promising to confirm legitimate issuance and non-revocation.
Do not use its successful result as proof of certificate authenticity or as the sole basis for supplier approval. Reliable verification needs an issuer-controlled registry, defined revocation enforcement, and strict evidence-hash validation. No malicious intent or destructive behavior was established, but the current security claims are unsupported.
scripts/badge_verify.pySelf-authored certificates pass verification without issuer authentication
An unissued or altered certificate can receive a successful verification result. The digest establishes only internal consistency, not issuer authorization, allowing a dishonest supplier to misrepresent certification to the recipient.
The manifest promises evidence-hash validation and confirmation of issuance and non-revocation, but the implementation checks only hash-field presence and permits successful verification without a ledger. Its ledger lookup also does not explicitly evaluate revocation status, so the advertised supply-chain identity assurance exceeds the implemented checks.
When --registry is omitted, the ledger check is excluded from the aggregate result, allowing verified=true and a successful exit status based solely on required fields and a self-consistent fingerprint. Because anyone can recompute this unkeyed fingerprint for fabricated certificate data, the result does not establish legitimate issuance or non-revocation despite being presented as successful verification.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
Verify a badge certificate: recompute fingerprint (anti-tamper) + evidence-hash format + registry cross-check (serial exists & not revoked).
**Pain point**: issuance without verification is forgeable — the loop lacked reverse checking and the trust chain broke.
Part of the **LGD moat loop**: Passport (registered) → Evidence chain (evidenced) → Gate (gated) → **Badge (issued/verified)**.
The code requires evidence_sha256 to exist but does not validate its type, length, or hexadecimal encoding. A malformed value can pass the integrity checks when included in a matching fingerprint, undermining the explicitly promised evidence-hash format assurance.