Your secret keys. Your users' private data. AI coding tools can leave them exposed without ever telling you, and you usually can't spot it by looking. CodeInspectus checks your code for you, on your own computer, with nothing uploaded.
You don't open a dashboard or learn a tool. The AI coding assistant you already use calls CodeInspectus for you.
It reads your project on your own machine and looks for exposed secrets, open data, and risky code. Nothing is sent anywhere.
Each issue comes with what it is, where it is, and why it matters to you, in normal language.
Nothing in your code changes until you say yes. You stay in control of every edit.
Four kinds of problem, in plain terms. Each one is something a non-expert can ship by accident, and an attacker can find on purpose.
Passwords, API keys, and tokens that ended up sitting in your code, including ones accidentally bundled into the app your visitors download to their own browsers.
Why it matters: anyone who finds one can run up charges on your accounts or reach the data behind them.
When an AI tool sets up a database, it often leaves the doors open, so any visitor can read, or even change, other people's records.
Why it matters: this is the most common way AI-built apps expose private user data.
If your app feeds outside text into an AI model, an attacker can hide instructions inside that text and push the model into misusing the access you gave it.
Why it matters: a newer risk older tools don't look for. We flag it as a possibility, never a certainty.
The open-source packages your app is built on can have publicly known weaknesses, often with a fix already available that you simply haven't picked up.
Why it matters: attackers scan for exactly these, because the weakness is already public knowledge.
Works on any language for exposed secrets and vulnerable dependencies. The deeper AI-code checks are built for JavaScript and TypeScript apps today, with more languages coming.
Your code never leaves your machine. No account. No upload. No company sees your code, not even us. And you can check this yourself.
CodeInspectus runs as a small program on your own computer. Your AI assistant talks to it directly, the checks run locally, and nothing phones home. There is no sign-in and no telemetry, ever. The single time it uses the network is the one-off install, when it downloads the scanning engines and verifies them. After that you can unplug the internet and every scan still works.
CodeInspectus plugs into the AI coding tools you already use: Claude Code, Cursor, Codex, Windsurf, and Cline. Here is the loop it follows, and the promises built into it.
Trust comes from being precise about the edges. Here is what CodeInspectus is not, said plainly and up front.
CodeInspectus is not a security audit or a certification. It finds real problems. It does not declare your app safe, and a clean run is not a guarantee.
A clean result means nothing obvious was found, not that nothing is wrong. Treat it as a strong first pass, not the last word.
Framework mappings show which code-level controls your findings touch. They are drafted with AI and reviewed by one security practitioner, they are not independently audited, and they never mean you pass a framework.
The AI-specific check for prompt injection is a medium-confidence signal. It is reported as a possible weak point, never asserted as certain.
If your code decides access from Supabase user_metadata, like if (user.user_metadata.role === 'admin'), CodeInspectus does not yet flag it. A signed-in user can edit their own user_metadata through Supabase's auth API and hand themselves that role, so gate privileged logic on the server-only app_metadata.role instead. Detecting this is planned as our first community-contributed rule. It does already flag a service_role key value in client-reachable code as critical, and a service_role key behind a browser-exposed NEXT_PUBLIC_ prefix as high.
None of this is a disclaimer buried in a footer. It is the point. You should know exactly what a result means before you trust it.
Everything below is for engineers and security folks who want to verify the machine, not just trust it. This console is an illustration of one local scan of code at rest. It is an example, not real output from your code, and not live network monitoring.
63 / 100, severity-weighted, illustrative. not a "% compliant" number
For the technically curious, here is exactly what happens on each call. Four analyzers run locally, their output is normalized and deduplicated into one CWE-keyed shape, mapped to framework controls, and returned. Every box is a local step. No step opens a socket.
An AI coding agent calls a tool over MCP, JSON-RPC across stdio. No HTTP, no daemon.
in codeinspectus_scan(path)
Core spawns Opengrep, Gitleaks and Trivy as subprocesses, plus its own AI-code checks.
out SARIF 2.1.0 ×4
A parser folds every SARIF stream into one compact, CWE-keyed schema with severities.
→ cwe findings
Overlapping hits collapse, including the Trivy by Gitleaks secret overlap, so a finding is reported once.
→ unique set
Each finding is tagged CWE to framework control, as honest code-level coverage.
→ framework tags
The agent receives compact JSON plus a human summary, then drives the fix.
out findings + summary
Each is a SHA-pinned binary, hash-verified before it executes, and never forked. Each one runs as a local subprocess, emits SARIF, and the normalizer folds it into the shared schema. Best-in-class scanners are the floor you should expect, not the differentiator.
Pattern-based source analysis tuned to the OWASP Top 10. Injection, broken access paths, unsafe deserialization, the structural mistakes a model repeats because the training data did.
local subprocess → SARIF → normalizer
Finds the keys, tokens, and credentials the model helpfully pasted inline. Every secret value is redacted in the output you and your agent see. The finding stays, the secret does not travel.
local subprocess → SARIF → normalizer
Dependency CVEs and software composition, infrastructure misconfiguration, license posture, and a software bill of materials. Always run with the offline flags, so the scan stays on your machine.
local subprocess → SARIF → normalizer
Pinned versions: Opengrep 1.23.0 · Gitleaks 8.30.1 · Trivy 0.71.2. CodeInspectus orchestrates, it never forks: it bundles the official binaries, verifies each SHA before it runs, and a mismatch is refused, not tolerated.
Secrets and dependency scanning work on any codebase. Static analysis covers three languages. The AI-code checks are JavaScript and TypeScript today. We would rather name the exact scope than claim "every language" and be wrong.
Gitleaks + CodeInspectus secret checks
Hard-coded credentials and leaked keys. Detection is value and pattern based, not language-parsed, so it runs the same on any codebase in any language.
Trivy
Vulnerable dependencies (SCA and CVEs), infrastructure misconfiguration, software bill of materials, and license posture, across many package ecosystems and IaC formats: npm, pip, Go modules, Maven and Gradle, Cargo, Composer, NuGet, Bundler, Dart pub, Docker, Terraform, Kubernetes, and more. See Trivy's docs →
Opengrep + the security-baseline ruleset
Injection, XSS, SSRF, weak crypto, and insecure deserialization. CodeInspectus ships its own MIT security-baseline ruleset (14 JavaScript/TypeScript rules and 5 Python rules) and runs Opengrep with no network registry packs, so coverage is exactly these three languages, deliberately narrower than Opengrep's full engine. This is not broad multi-language SAST.
client-secret bundling, Supabase RLS, prompt-injection sinks
The AI-code and vibe-coding failure modes the engines miss. JavaScript and TypeScript only, including .jsx / .tsx / .mjs / .cjs. The client-secret checks also read frontend files .vue / .svelte / .astro / .html, and the Supabase RLS check reads .sql plus .ts / .js Edge Functions. More languages are planned.
So on a Python, Go, or Rust repo you still get full secrets, dependency, IaC, and SBOM coverage, plus Python static analysis. The AI-code-specific checks simply do not fire there yet.
Borrowed engines are the commodity floor. The moat is CodeInspectus's own checks for the failure classes that AI-generated code introduces, plus a curated detection database that grows weekly.
Keys and tokens shipped to the browser in client code or build output, where a vault-only mental model says they cannot be.
The row-level-security failures and inverted authorization that AI scaffolding ships by default. Detected from the code, not a network probe.
Where untrusted text can reach an LLM call. Reported as a potential sink, a heuristic signal at medium confidence, never asserted as certain.
Behind these checks sits a curated detection database that grows every week through human-reviewed intake. The bundled engines are the floor anyone can stand on. This database is the part you cannot copy by downloading the same binaries.
CodeInspectus never writes to your code. It returns findings with remediation, the agent applies the fix, then a rescan confirms the finding is gone.
Run all four analyzers over the path. Get CWE-keyed findings, each with severity, remediation and framework tags.
→The agent reads the remediation and edits your code. CodeInspectus touches nothing. Use explain_finding for the why.
→Re-run on the changed files. The closed findings drop out, anything new surfaces, the loop continues until clean.
Trivy was supply-chain-compromised twice in early 2026. A bundled scanner is itself an attack surface, so CodeInspectus treats every engine binary as untrusted until proven.
Each binary is SHA-pinned in a locked manifest and hash-verified before it runs. A binary that is unpinned or whose hash does not match is refused. It does not execute.
Each finding's CWE maps to controls across frameworks. The numbers below count how many of each framework's code-visible controls CodeInspectus's detectors can reach. It is a coverage view, never a verdict.
Essential Eight is shown as a footnote, not a coverage panel: only Patch Applications is meaningfully code-evidenced (1 of 8 mitigations). This is not an Essential Eight assessment.
CodeInspectus is a solo, free, open-source project by one security practitioner under the Synvoya name. There is no company behind it, which is exactly why outside eyes matter.
If you write code or work in security, your scrutiny is the contribution. The detection rules and the compliance mappings are both open to review, and false-positive reports are as welcome as new rules.
The compliance mappings especially. They are AI-drafted and reviewed by the maintainer, but not yet independently verified. Of the 96 framework-control mappings, zero have been confirmed by an outside contributor. Moving one to community-verified takes a quote from the control's primary source and your basis. We report the count honestly rather than hide it.
workflow: fork → branch → pull request → maintainer review → merge
framework-control mappings community-verified so far. The headline integrity number, reported in the open.
The full set, collapsed by default. Open what you need: the enforced security properties, every detection rule, the exact engine versions, and how this is built.
These are the guarantees enforced in the code and the lockfile, drawn from the engine manifest, the source guardrail comments, the README's honest-claims, and the verify checklist. Each is a property the tool holds itself to, not a marketing line.
CodeInspectus never writes to or deletes your files. Your agent applies fixes; the SBOM is the only output, written to a managed directory.
README · no tool writes your codeOutput carries the type, location, and a redacted preview only. A raw secret value is never written back into any result.
eval E03 · verify.mdEvery engine binary's SHA256 is verified against the lockfile before it runs. An unpinned or mismatched binary is refused.
engines.lock.json · src/engines/resolve.tsPublisher signatures are mandatory: cosign for Opengrep and Trivy, signed checksums for Gitleaks, sigstore for Trivy. No valid signature, no execution.
engines.lock.json sigstore_identitiesTrivy runs with offline flags and the scan path opens no socket. There is no account, no sign-in, and no telemetry of any kind, ever.
README · src/engines/trivy.tsOutput never says "% compliant" or "you pass". It always shows the code-visible denominator and the standing disclaimer.
verify.md guardrail spot-checksOverlapping hits collapse, including the Trivy and Gitleaks secret overlap, so a single finding is reported once.
README dataflowCodeInspectus bundles the official engine binaries and calls them as local subprocesses. It does not fork or patch them.
READMEThe stdio MCP transport keeps stdout pure JSON-RPC; all human text goes to stderr. No stray console output leaks into the protocol.
src/logger.ts · src/index.tsThe custom AI checks target the AI-code and framework failure modes the generic engines miss. Generic SAST is left to the engines, not duplicated.
detection-db/manifest.jsonCodeInspectus's own curated detections: 11 AI-code checks, 19 Opengrep security-baseline rules, and 3 Gitleaks secret rules. The generic engine corpora run alongside these and are not listed here. Plain-English label, then the rule id and CWE for the technical reader.
AI-code checks · engine codeinspectus-ai · 11
| What it catches | Rule id | CWE |
|---|---|---|
| Hard-coded secret in client-reachable code | ci-ai-client-hardcoded-secret | CWE-798 / 312 |
| Secret compiled into the shipped bundle | ci-ai-secret-in-bundle | CWE-798 / 312 |
| Secret exposed via a client-visible env prefix | ci-ai-public-env-secret | CWE-798 / 312 |
| Supabase service_role key in client code | ci-ai-supabase-service-role-client | CWE-798 / 285 |
| LLM SDK set to allow browser use | ci-ai-llm-key-browser-exposed | CWE-798 / 312 |
| RLS policy USING (true), table fully open | ci-ai-rls-using-true | CWE-863 / 285 |
| Public table created without Row Level Security | ci-ai-rls-missing | CWE-862 / 285 |
| RLS policy tests role instead of user identity | ci-ai-rls-inverted-auth | CWE-863 |
| Supabase Edge Function with no auth check | ci-ai-edge-fn-no-auth | CWE-862 |
| Permissive RLS on storage objects | ci-ai-storage-rls-public | CWE-863 / 285 |
| Potential prompt-injection sink (heuristic) | ci-ai-prompt-injection-sink | CWE-1426 |
Opengrep security-baseline · engine opengrep · 19
| What it catches | Rule id | CWE |
|---|---|---|
| SQL injection via string-built query (JS/TS) | ci-baseline-sql-injection-string-build | CWE-89 |
| SQL injection via string-built query (Python) | ci-baseline-sql-injection-python | CWE-89 |
| Command injection via shell string (JS/TS) | ci-baseline-command-injection | CWE-77 |
| Command injection via shell=True (Python) | ci-baseline-command-injection-python | CWE-77 |
| Dynamic code evaluation of non-literal (JS/TS) | ci-baseline-dangerous-eval | CWE-94 |
| Dynamic eval/exec of non-literal (Python) | ci-baseline-eval-python | CWE-94 |
| NoSQL injection from request data | ci-baseline-nosql-injection | CWE-943 |
| Path traversal from request input | ci-baseline-path-traversal | CWE-22 |
| DOM XSS via innerHTML/outerHTML sink | ci-baseline-dom-xss-innerhtml | CWE-79 |
| SSRF: outbound request URL from input | ci-baseline-ssrf-request-from-input | CWE-918 |
| Weak hash algorithm (MD5/SHA1) | ci-baseline-weak-hash | CWE-327 |
| Weak or broken cipher (DES/RC4/3DES) | ci-baseline-weak-cipher | CWE-327 |
| Weak hash algorithm (Python) | ci-baseline-weak-hash-python | CWE-327 |
| Math.random() for a security value | ci-baseline-insecure-random-security | CWE-338 |
| JWT verification accepts alg "none" | ci-baseline-jwt-alg-none | CWE-347 |
| CORS wildcard origin with credentials | ci-baseline-cors-wildcard-credentials | CWE-942 |
| Session cookie without httpOnly/secure | ci-baseline-insecure-cookie | CWE-1004 |
| Insecure deserialization (node unserialize) | ci-baseline-insecure-deserialization-node | CWE-502 |
| Insecure deserialization (untrusted loader) | ci-baseline-insecure-deserialization-python | CWE-502 |
Gitleaks secrets · engine gitleaks · 3
| What it catches | Rule id | CWE |
|---|---|---|
| Stripe live-mode secret key | codeinspectus-stripe-live-secret | CWE-798 |
| Supabase service_role JWT | codeinspectus-supabase-service-role | CWE-798 |
| Anthropic API key | codeinspectus-anthropic-key | CWE-798 |
The exact pinned versions and how each is verified before execution. SHA256 values shown are the darwin-arm64 pins; the full per-platform set lives in engines.lock.json.
| Engine | Version | Verified by | SHA256 (darwin-arm64) |
|---|---|---|---|
| Opengrep | 1.23.0 | cosign | 945739e5…0265c5f |
| Gitleaks | 8.30.1 | signed checksums | ba52fb1b…bc0e84f |
| Trivy | 0.71.2 | cosign + sigstore | 7d8bf184…d619127d |
Re-verify any time with npx codeinspectus verify-engines. A null pin, or a hash that does not match, means the binary will not run on that platform.
The repository is generated from an auditable, allow-list seed and built end-to-end with a clean type-check, a build step, and a regression eval suite over fixtures. The full story, including what is and is not published, is written down.
CodeInspectus runs as a local MCP server. Register it once, then Claude Code, Cursor, Codex, Windsurf, and Cline can all call it. The first scan runs fully on your machine.
One time, and disclosed. This fetches and SHA256-verifies the three engine binaries and the initial Trivy database. It is the only step that touches the network; every scan after it runs offline.
$ npx -y codeinspectus install-enginesDrop this into your agent's MCP config. It is the standard mcpServers block, so the same three lines work across MCP-capable agents.
{
"mcpServers": {
"codeinspectus": { "command": "npx", "args": ["-y", "codeinspectus"] }
}
}No restart, no dashboard. Your agent now has six tools that never touch your code; they read and report. Ask it to scan: CodeInspectus surfaces findings in plain language, your agent proposes fixes, you approve each one, and a rescan confirms. Your agent writes only what you okay.
Then just say: "scan this project for security issues"
Register it with your agent
The block above is the standard. Here is where it goes, per agent.
claude mcp add --scope user codeinspectus -- npx -y codeinspectus
Add the block to ~/.cursor/mcp.json, or .cursor/mcp.json for one project.
Add the block to ~/.codeium/windsurf/mcp_config.json.
Open the MCP Servers panel, choose Configure, and add the block to cline_mcp_settings.json.
Add a [mcp_servers.codeinspectus] table to ~/.codex/config.toml with the same command and args.
An AI coding agent calls CodeInspectus over MCP using JSON-RPC across stdio. The CodeInspectus core runs three bundled engines as local subprocesses, Opengrep for static analysis, Gitleaks for secrets and Trivy for dependency CVEs, infrastructure misconfiguration, secrets, license checks and SBOM, plus its own AI-code-specific checks. Each engine emits SARIF 2.1.0. A normalizer parses the SARIF into one compact CWE-keyed schema, deduplicates overlapping findings including the Trivy and Gitleaks secret overlap, and a compliance mapper tags each finding from CWE to framework controls. The core returns compact JSON and a human summary to the agent. Every step runs locally on your machine. There is no network egress at scan time.
The console is an illustration of a single local scan of code at rest. It reads seven findings: one critical, two high, three medium and one low. The severity-weighted posture score is 63 out of 100, which is a distinct console reading and not a compliance percentage. The console does not perform live network monitoring.