Human-Certified Module Repositories: Trust Infrastructure for AI-Assembled Code
Ciprian · · 3 min read A paper on Human-Certified Module Repositories introduces HCMRs — a framework for vetted, provenance-rich package repositories designed for an era where AI agents assemble code from open source components.
The Problem
Open source never had formal trust infrastructure. No certification body. No mandated audit process. No credential a maintainer had to earn before publishing to npm or PyPI.
What existed instead was a dense, informal layer of social and behavioral signals: stars, download counts, contributor history, known maintainer reputation. Developers learned to read these over years of shipping software.
AI agents cannot read these signals. When an LLM suggests a dependency or assembles components, it optimizes for functional fit, not supply chain trust. The reliability of AI-assembled systems depends critically on the trustworthiness of the building blocks — and the current selection process has no trust layer.
The Proposal
HCMRs combine human oversight with automated analysis. The framework defines repositories that are curated, security-reviewed, provenance-rich, and equipped with explicit interface contracts.
Key components:
- Reference architecture for vetted module repositories
- Certification and provenance workflows — who reviewed what, when, and what they verified
- Threat surface analysis for modular ecosystems
- Lessons from recent supply-chain failures (event-stream, ua-parser-js, colors.js)
- Governance and accountability frameworks
Why This Matters Now
The slopsquatting problem — AI hallucinating package names that do not exist, which attackers then register — is a symptom. The disease is that AI code generation operates without trust boundaries in the package ecosystem.
When a human developer picks a dependency, they bring context: they have used it before, they know the maintainer’s reputation, they check the last commit date. When an AI agent picks a dependency, it pattern-matches from training data. The selection process has no trust layer.
HCMRs would create that layer: a subset of the package ecosystem where every module has been reviewed, its provenance is documented, and its interfaces are explicitly contracted. AI agents would preferentially draw from this vetted pool rather than the open ecosystem.
The Tradeoff
Higher curation barriers mean slower ecosystem growth. The paper acknowledges this: AI-era development may require higher curation barriers than contemporary open source practices to ensure auditability and predictability.
This is a real tension. The npm/PyPI model works because anyone can publish. HCMRs work because not everyone can. The question is whether the trust benefit justifies the participation cost.
For teams shipping AI-generated code, the answer is increasingly yes.