signatory

A CLI and MCP server that aggregates trust signals about open-source code, projects, and the people behind them — so humans and LLM coding agents can decide, on evidence, whether to adopt a dependency. Designed and shipped from zero to working MVP in four weeks.

Why It Exists

Frontier AI models can now find zero-day vulnerabilities at scale, and LLM coding agents readily suggest open-source packages because those packages appear in their training data — not because anyone has reviewed them recently. The combination flips a long-standing assumption: the older and more widely cached a package is, the larger its blast radius if compromised.

Most existing tools assume packages are trustworthy and flag the ones with known CVEs. Signatory takes the opposite default. It borrows from counterintelligence and fraud investigation: gather evidence on projects and the teams behind them, weigh each signal by how hard it is to forge, and decide whether something is worth trusting, worth forking, or worth replacing.

How It Works

Three interfaces over one local trust database:

• CLI for direct querying, posture management, and burn-list maintenance.
• MCP server so LLM coding agents can consult the same evidence before recommending a dependency.
• Claude Code skill (/analyze) that dispatches analyst agents over the collected signals and proposes a verdict.

Signal collection is mechanical and deterministic — pulled from GitHub, git history, and package registries — and stored locally. Analysis is the variable, expensive layer: agents read from the cache rather than re-fetching, so a second look at the same dependency is cheap and a third look is nearly free.

Design Decisions

• Aggregator, not scanner. Signatory surfaces signals from existing sources rather than running its own vulnerability checks. It’s invoked at decision moments — pre-adoption, version bumps, incident triage — not swept across a dependency tree on a schedule.
• Raw signals, not opinionated scores. No black-box risk number. Users (and their LLMs) define their own thresholds and scoring.
• Explicit postures, recorded. Each dependency sits in a named tier — vetted-frozen, trusted-for-now, unexamined, unknown-provenance, or rejected — with the rationale and source signals linked. Decisions persist across sessions and are visible to both humans and models.
• Burn ledger. When a package or maintainer identity is compromised, burn it; the record surfaces alongside every future signal.
• Counterintelligence framing. The trust model draws on OSINT and fraud-investigation methodology rather than developer-dashboard conventions. See design/vision.md for the short version, or the broader design/ corpus for the full model.

Validation

Each new real-world supply-chain incident is treated as a test case for the signal model: would Signatory have surfaced this? The design/threat-landscape/ directory works through recent attacks and industry developments — coordinated disclosure collapse, the Bufferzonecorp campaign, vendor parity in Mythos-class capabilities — and notes where the model held and where it needs to grow.