作者打造 vetgate，為智能體安裝套件加入事前檢查

Your agent installs packages before anyone vets them. I built a gate that runs first.

My coding agent resolves a task, picks a package, and runs the install. The postinstall hook fires before I read any output. By the time a post-install audit, a PR check, or a dashboard tells me something was wrong, the payload has already run.

That is the moment I wanted to gate: after the agent has chosen the artifact, before the install or run command executes.

What I built

vetgate is a local, deterministic pre-execution gate. It is an MCP server and a CLI mirror. Call it instead of running the install: one call, one verdict (ALLOW, DENY, or REVIEW), every finding carrying the exact evidence string it matched, and a manifest that makes the verdict re-checkable without re-running anything.

It vets three kinds of artifact:

vet_package / npm:name@version — downloads the published tarball, inspects it, never executes it.
vet_action / action:owner/repo@ref — a local form check: SHA-pinned, mutable tag, or unpinned.
vet_script / url:https://... — fetches the script text, scans it, never executes it.

There is no model, no account, no API key, and no verdict score. The default path sends nothing anywhere except downloading the artifact itself (vet_package) and fetching the script text (vet_script, labeled in the verdict manifest). All analysis is local.

The rules are stated, not learned. A finding without evidence is a bug. Any high finding means DENY; otherwise any finding means REVIEW with a safeAction — for example, install with --ignore-scripts, pin to a digest, or ask the user. A single weak signal alone (an install script that only echoes, a missing license field, a mutable tag) yields REVIEW, never a silent ALLOW and never a DENY.

A real run

From the CLI, on hand-built fixtures (no real malware, nothing fetched in fixture mode):

$ vetgate check local:tests/fixtures/exfil
vetgate: DENY — 2 finding(s)   # exit 1

$ vetgate check local:tests/fixtures/benign
vetgate: ALLOW — 0 finding(s)  # exit 0

$ vetgate check action:actions/checkout@v4
vetgate: REVIEW — 1 finding(s) # exit 1, pin to a full commit SHA

The full transcript is in the repo at docs/demo/transcript.txt, and the README shows a 30-second demo rendered from that transcript.

As an MCP server, it exposes the same three tools over stdio:

{
  "mcpServers": {
    "vetgate": { "command": "npx", "args": ["-y", "vetgate", "serve"] }
  }
}

I verified it with a real MCP session: the server lists all three tools, vet_action on actions/checkout@v4 returns REVIEW, and vet_package on the real published lodash@4.17.21 returns ALLOW with the tarball SHA-256 6a087ac9e5702a0c9d60fbcd48696012646ec8df1491dea472b150e79fcaf804.

Measured numbers, not claims

Measured locally at build time on the fixture set (analysis only; network download time excluded). The measurement script is scripts/measure-latency.mjs in the repo, so you can re-run it:

Fixture suite: 15 hand-built fixtures — ALLOW 4, DENY 6, REVIEW 5. Every malicious-pattern fixture DENYs, every benign fixture ALLOWs, every weak-signal fixture REVIEWs.
False-positive probe: 10 benign fixture contents — 0 DENY.
Determinism: the same package contents vetted twice produce identical verdicts after stripping manifest.checkedAt.
Latency over the fixture set (3,000 timed checks): median 0.006 ms, p95 0.075 ms, mean 0.026 ms per check.
Test suite: 26 tests, all passing (npm test).

Where rivals beat us

Honesty first, because a security gate that overclaims is worse than useless:

SafeDep vet beats us on breadth and on malicious detection. More ecosystems, Docker and SBOM support, policy expressions, and cloud active scanning for malicious packages in the wild. Our v1 is npm-only with a fixed local rule set and cannot match that breadth or that cloud detection power.
Socket beats us on behavioral detection depth. Its malware database, obfuscation analysis, and telemetry detection come from operating a cloud scanner at scale. Our local rules cover only the documented install-script and pattern surface.
Snyk and DeepSource beat us on monitoring and fixing. Continuous re-evaluation and fix PRs are a different, genuinely valuable job; we do neither. We vet one artifact once, before execution.
OpenSSF Scorecard beats us on maintainer-risk signals. Branch protection, review discipline, and fuzzing adoption are real risk signals our artifact inspection does not measure.
OSV and the advisory databases beat us on known-vulnerability breadth. Any local-only v1 misses known CVEs that a database lookup would catch. There is no enrichment mode in v1.
A registry firewall beats us on position. Blocking at the registry edge stops a bad package before download; we inspect after download and before execution, by design, because we are the gate for agents that install from anywhere, not just one registry.

The wedge is narrow and deliberate: a gate that sits inside the agent loop at the moment of execution, returns a deterministic verdict with quotable evidence, and runs fully locally with no account, no key, and no data leaving the machine. If you need breadth, cloud detection, monitoring, or fix PRs, use the tools above — vetgate does not replace them.

What is NOT in v1

Other ecosystems (PyPI, Maven, Go, Ruby, Rust, PHP). npm only.
Agent skill / MCP-server-config vetting — a real pain, a different detection domain, and the first follow-up candidate.
Container image layer inspection, monitoring, re-scanning, fix PRs, dashboards, accounts, cloud APIs, or policy languages.
Any claim about malware families beyond the stated rule list. The tool reports what its rules matched, nothing more.

The roadmap is in the README: skill/config vetting first, then ecosystems one at a time, then optional labeled network enrichment, off by default.

Try it

npm ci
npm run build
npm test

Requires Node 20 or later. The repo is MIT licensed, and the code, rules, fixtures, and measurement script are all in the open:

Repo: https://github.com/techdevfun/vetgate
README: https://github.com/techdevfun/vetgate#readme

If you run it on a package your agent was about to install, I would like to hear what it caught — or what it missed. The rule list is explicit, so a miss is a concrete bug report, not a vague score to argue about. What would you want the gate to check next: another ecosystem, or skill/config vetting?