vibecheck
vibecheck
A fast, agent-native "safe to ship?" gate for vibe-coded apps. It parses your JS/TS/JSX/TSX
(@babel/parser), Python (the stdlib ast), and Go (go/parser) with real parsers and uses taint analysis
(inter-procedural for JS/TS, Python, and Go — return-taint + param→sink summaries, within a file and across files) to flag the security classes AI coding agents get wrong — committed secrets, SQL
injection through abstracted raw-query APIs, XSS, SSRF, path traversal, command injection, insecure
deserialization, weak JWT/CORS/cookies — and ranks every finding by confidence so an agent can fix
the real ones and ignore the noise.
vibecheck . # human report (severity + confidence)
vibecheck . --ci # exit 1 only on high-confidence (taint-backed) issues
vibecheck . --json # machine-readable findings for agents / CIWhat it is — and what it is not (read this)
vibecheck is not a replacement for Semgrep or
CodeQL. Those are deeper, broader, multi-language engines and you should
run them for full coverage. vibecheck aims to be better on one narrow, measurable axis: a
low-false-positive, taint-backed gate for the AI-vibe-coding failure classes that runs inside agent
loops and pre-commit in milliseconds, with published precision/recall so you can trust the
--ci/MCP signal. Use it alongside the big engines, not instead of them.
vibecheck | Semgrep | CodeQL | |
Parsing | real AST (Babel JS/TS/JSX + Python | real, many langs | real, many langs |
Data-flow | inter-procedural (return-taint + param→sink; intra-file + cross-file by import) | taint (Pro) | full inter-procedural |
Languages | JS/TS/JSX/TSX + Python + Go | many | many |
Speed / infra | ms, local, no account | fast | slower, CI-oriented |
Agent-native (MCP, confidence gating) | yes, first-class | partial | no |
Breadth of rules | small, focused | 2000+ | huge |
If you only adopt one general SAST, adopt Semgrep or CodeQL. Adopt vibecheck as the fast agent/CI pre-flight that won't drown an agent in false positives.
Related MCP server: Zfuzz
Measured quality (not claimed)
Against a labeled benchmark of 91 cases across JS/TS, Python and Go (vulnerable + safe + deliberately
tricky-safe), the core detectors score (see METRICS.md, reproduce with bun benchmark/run.ts):
Precision 100%, Recall 100%, F1 100% on the corpus.
The tricky-safe cases that produce zero false positives include: parameterized queries, tagged-
template SQL, numeric-coerced and schema-validated input, ORM/RegExp .exec(), Supabase anon /
Stripe publishable keys, hardened cookies, allow-listed CORS, and pinned JWT algorithms — exactly
the patterns a regex linter trips on. This benchmark is curated; for a real-world measurement (9 pinned
OSS repos, 1,218 files, manually triaged), see docs/CORPUS.md — which exposed a
critical bug (Python/Go files weren't being scanned in real scans) and drove precision fixes (relative
redirects, server-source-only SSRF).
Confidence
Every finding has a confidence:
high— a user-input source provably flows into the sink (taint-backed), or a deterministic fact (committed secret, JWTnone). These fail--ciand are what the MCPscantool returns by default.medium— a dangerous sink on a non-literal value with no proven source (e.g.eval(x)).review— a structural smell that needs a human (e.g. a route with no visible auth). Excluded from--ciand from the agent loop by default, so agents never chase phantom work. Add--allto include them.
Install & use
npm i -D @arisrhiannon/vibecheck # or: bun add -d @arisrhiannon/vibecheck (Node >= 20)
vibecheck . --ci
vibecheck explain VC-SQLI
vibecheck mcp # MCP stdio server exposing a `scan` tool (high-confidence by default)Agents: see AGENTS.md — run vibecheck . --ci before declaring a task done and fix every
high-confidence finding.
JS/TS scanning needs nothing extra. Python scanning requires
python3on PATH; Go scanning requires agotoolchain on PATH (the analyzer is compiled once and cached). If a runtime is absent those files are skipped; if an analyzer fails, a warning is printed to stderr (so a crash never silently drops findings).
Rules (implemented + benchmarked)
Taint-backed: VC-RCE-EVAL, VC-RCE-CHILD-PROCESS, VC-SQLI, VC-XSS-REACT, VC-XSS-DOM, VC-SSRF,
VC-PATH-TRAVERSAL, VC-OPEN-REDIRECT. AST config: VC-CORS-WILDCARD, VC-JWT-NONE,
VC-JWT-UNPINNED, VC-COOKIE-INSECURE, VC-STACK-EXPOSURE. Provenance/secrets: VC-SECRET-* (8),
VC-ENV-COMMITTED/DRIFT/MISSING, VC-NEXT-PUBLIC-SECRET, VC-SUPABASE-SERVICE-ROLE. Advisory:
VC-ROUTE-NO-AUTH (review), VC-INPUT-NO-VALIDATION. Python (VC-PY-*): VC-PY-RCE,
VC-PY-CMDI, VC-PY-SQLI, VC-PY-DESERIALIZE, VC-PY-YAML, VC-PY-SSTI, VC-PY-OPEN-REDIRECT,
VC-PY-PATH. Go (VC-GO-*): VC-GO-CMDI, VC-GO-SQLI, VC-GO-PATH, VC-GO-OPEN-REDIRECT,
VC-GO-SSRF. vibecheck explain <id> prints the fix for each.
Limitations
JS/TS/JSX/TSX + Python + Go (Python needs
python3, Go needs agotoolchain on PATH). More languages are roadmap (each via its own real parser, never hand-rolled).Taint scope: JS/TS taint is inter-procedural with real cross-file module resolution — function summaries carry return-taint and parameter→sink reachability, resolved within a file and across files via resolved relative imports (named, aliased
a as b, and namespace* as ns), propagated multi-hop by a fixpoint; sanitizers respected. Not tracked (false negatives): re-exports (export { x } from …), default exports, CommonJSrequire/dynamicimport(), bare/package imports, chains deeper than ~7 hops in worst-case file order, methods, and destructured params. Python is also inter-procedural (return-taint + param→sink and class@staticmethodresolution, intra-file and cross-file via resolvedfrom .mod import/import mod; not resolved:import a.bdotted-unaliased,*/re-exports, decorators). Python request sources span Flask, Django, aiohttp (request.match_info,await request.post()), FastAPI/ Starlette (request.query_params/path_params,await request.json()/form()), Tornado, Bottle, Pyramid. Go is inter-procedural within and across packages (return-taint + param→sink; unaliasedpkg.Funcresolves by package name). Aliased package imports (import u "…/util") and multi-return assignments (x, _ := f(src)) are not tracked.Config/secret rules are pattern-based where AST adds no value.
A high-signal gate and early-warning — not a proof of security. Pair it with Semgrep/CodeQL and review.
Config — .vibecheck.json
{ "ignoreRules": ["VC-INPUT-NO-VALIDATION"], "allowPaths": ["test/**"], "failSeverity": "high" }License
MIT © 2026 Aris Rhiannon — see LICENSE.
Available Tools
1 toolscanA
Scan a project directory for vibe-coding security / ship-readiness issues (offline, no AI). Returns high-confidence (taint-backed) findings as JSON by default; pass includeAll:true for medium/review too. Run before declaring a coding task done.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | project directory to scan (default '.') | |
| includeAll | No | include medium/review-confidence findings (default false) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses key traits: offline operation, no AI involvement, default output is high-confidence JSON findings, and includeAll flag for medium/review findings. It does not mention permissions or performance, but for a read-only scan this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient sentences with no wasted words. The main action and key differentiators are front-loaded, making it easy for an AI to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 params, no output schema, no siblings), the description covers purpose, parameters, usage timing, and output format completely. No gaps remain for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds value by explaining the effect of includeAll (include medium/review findings) and clarifies default behavior (high-confidence). This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans project directories for security and ship-readiness issues, offline and without AI, and returns findings as JSON. The verb 'scan' and resource 'project directory' are specific, and the purpose is unambiguous even without sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The explicit instruction 'Run before declaring a coding task done' provides clear when-to-use guidance. No alternatives or when-not-to-use are given, but the context of no sibling tools makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
scan
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusing it with other tools. Agents will always select the correct tool.
With a single tool, naming consistency is trivially maintained. The name 'scan' is a clear verb that matches its action.
A single tool is on the low end for a server, but it is acceptable for a narrowly focused utility that performs one well-defined task. The tool covers a specific security scanning need without requiring multiple operations.
The one tool handles the primary scanning operation with configurable output levels, but lacks supporting tools for managing scan history, configurations, or results. It covers the core function but leaves gaps for typical workflows.
Related MCP Connectors
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security firewall for AI agents — scans MCP calls for injection, secrets, and risks.
Security & DLP proxy for MCP: tool-poisoning scans, PII redaction on tool args/results. Beta.
Zero-install security baseline for AI coding agents — OWASP/CWE-cited rules over MCP.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceEnables scanning of AI agent code for security vulnerabilities such as prompt injection, tool abuse, and data exfiltration, directly from MCP-compatible clients like Claude Code.2LGPL 3.0
- AlicenseNot gradedqualityCmaintenanceReal security scanners for AI coding agents — SAST (441 rules), secret detection (419+ patterns), dependency CVEs (OSV.dev), MCP/skill vetting, MITRE ATT&CK. Open-source, Rust, free7 npmApache 2.0
- AlicenseNot gradedqualityAmaintenanceSecurity scanner for MCP servers — vet an MCP before you wire it into an agent. Detects prompt-injection, credential exfiltration (via taint analysis), RCE, and supply-chain risks, and catches cross-server exfil chains no single server reveals. Zero-dependency local CLI, SARIF output, CI-gateable, no account.42 npmMIT
- AlicenseCqualityBmaintenanceSecurity scanner and MCP server that catches dangerous patterns in MCP servers and AI agent projects, such as leaked secrets, shell execution, and prompt-injection text. Runs as both a CLI and MCP server with CI-friendly severity gates.21MIT