VibeGuard Security Linting for AI Code

VibeGuard is zeroFhacker’s open-source Python security linter for AI-generated code, posted as a Show HN project on August 29, 2026. It deals with a plain problem: assistants can generate vulnerable code faster than people can review every line. The practical takeaway is to keep AI-written changes behind a small, repeatable security boundary before they merge. For Cursor, Anysphere’s AI code editor, that means pairing the scanner idea with cursor rules, review receipts, and careful use of Cursor subagents and skills.

A security linter is a tool that scans code for known unsafe patterns and reports them before the code ships. VibeGuard’s angle is narrower than a general scanner: it focuses on mistakes the project says AI coding assistants repeatedly produce.

Read the project before trusting the grade

VibeGuard’s README describes a zero-config, CI/CD-ready linter that grades code from A to F. The listed rule areas include SQL injection, hardcoded secrets, command injection, JWT algorithm bypass, XML external entities, insecure randomness, path traversal, permissive CORS, production debug mode, and unsafe pickle deserialization.

That list is why developers paid attention. It reads like the greatest hits of “the generated code looked fine until someone checked the boundary.” A Cursor Agent can build a working endpoint, wire the test, and update the route in minutes; the same speed makes it easier to miss a string-built SQL query or a shell=True helper hiding in the diff.

The trap is treating an A–F grade as a security proof. As of the August 29, 2026 source snapshot, VibeGuard was a very small open-source project, mainly Python, with one GitHub star. That does not make it uninteresting. It means the right first move is to inspect the rule set and run it on throwaway diffs before making it part of a serious merge gate.

Notice where AI code gets risky

The risky moment is usually not dramatic. It is a normal editor loop.

A developer asks Cursor to add a Flask search endpoint. The generated code passes the query string into an f-string SQL statement because the prompt emphasized speed and shape, not parameter binding. The tests pass because the happy path works. The review conversation then centers on product behavior, not injection safety.

The same pattern shows up around auth and platform glue. A model may generate JWT verification without checking the algorithm, write a temporary token into a config file, or call a shell command with user-controlled input. None of these require a malicious prompt. They are ordinary code-completion failures with security consequences.

VibeGuard is interesting because it names those repeated patterns directly. The better mental model is not “AI code is bad.” It is “AI code needs a cheap first security pass because the mistakes are familiar.”

Put one small boundary in Cursor

The smallest useful boundary is a rule that makes risky generated code stop and explain itself. Keep durable repo constraints in AGENTS.md when they apply everywhere. Use a scoped Cursor .mdc rule when you want the agent to remember a review habit only for certain files or risk areas.

This is where Cursor subagents and skills fit naturally. A Cursor skill can hold the repeatable security-review steps. A Cursor subagent can run a focused check and return a receipt instead of continuing to edit. If you want the broader pattern, the related training topic on Cursor subagents and skills is the right next page.

A good boundary has three parts: what to check, when to stop, and what receipt to leave. Do not ask the same agent that wrote the risky code to silently fix everything. Ask it to surface findings, suggest patches, and mark anything that still needs a human security decision.

This also matters when agents leave the editor and touch shells, services, or external tools. The same “show the receipt before you act” idea appears in TaskShell Bridges AI Coding Agents, where command execution needs a clear review edge.

Copy this Cursor rule

Here is a small .mdc rule you can adapt. It does not assume VibeGuard is installed. It creates the review boundary VibeGuard is pointing at.

---
description: Check AI-generated changes for common security bugs before accepting risky code
globs:
  - **/*.py
  - **/*.js
  - **/*.ts
  - **/*.tsx
alwaysApply: false
---

When reviewing AI-generated code, stop for a security pass if the diff touches:

- database queries or ORM raw SQL
- auth, JWTs, sessions, cookies, or tokens
- subprocess, shell commands, eval, exec, or dynamic imports
- file paths, uploads, downloads, archives, or XML parsing
- secrets, API keys, production config, CORS, or debug flags
- deserialization, random values used for security, or crypto

Before accepting the change:

1. Run the project security linter if one exists. If VibeGuard is installed, run it against the changed files or the repository.
2. Inspect the diff manually for SQL string concatenation, hardcoded secrets, command injection, JWT alg:none bypass, XXE, path traversal, permissive CORS, debug mode, and unsafe deserialization.
3. Do not auto-fix auth, crypto, secrets, shell execution, deserialization, or production config without a human review step.
4. Return a short receipt with: files checked, command run, findings, proposed fixes, and unresolved risks.

The important line is the receipt. Without it, the agent can “fix” the issue by editing more code, creating a second review problem. With it, the developer sees the command, the finding, and the remaining risk in one place.

If you add VibeGuard later, keep the rule boring. Point the agent at the real project command from the repository, not a made-up wrapper. The boundary should survive tool changes.

Common questions

• Does VibeGuard replace a normal SAST scanner?

  No. VibeGuard is best read as a focused linter for repeated AI-generated security mistakes, not a replacement for mature SAST, dependency scanning, secret scanning, or threat modeling. The project describes 15+ rule areas and A–F grading, which is useful as a first pass but not enough to prove code is safe.

• Why make a linter specifically for AI-generated code?

  Because AI assistants often repeat predictable insecure patterns while producing otherwise plausible code. The VibeGuard README calls out examples like SQL concatenation, hardcoded secrets, unsafe shell execution, JWT algorithm bypass, and permissive CORS. A focused linter gives reviewers a fast checklist for the mistakes most likely to slip through an ordinary feature review.

• How should I use this with Cursor rules?

  Use Cursor rules to make the security pass hard to forget when generated code touches risky surfaces. A scoped .mdc rule can ask Cursor Agent to run the available linter, inspect the diff, and return a receipt. Keep repository-wide rules in AGENTS.md when the constraint applies across the whole codebase.

• Can a Cursor subagent fix VibeGuard findings automatically?

  Sometimes, but it should not be the default for sensitive code. A Cursor subagent can propose a parameterized query or remove a hardcoded secret, but auth, crypto, deserialization, shell execution, and production config deserve human review. The safer pattern is “detect, explain, propose,” then let a person accept the patch.

• What is the main limitation of this approach?

  Pattern-based linting catches known shapes, not every vulnerability. A scanner may miss context-specific authorization bugs, business-logic flaws, unsafe trust boundaries, or framework-specific edge cases. That limitation is fine if you treat the linter as the first security pass, not the whole security review.

Best ways to use this research

• Best for: Cursor users who already let agents write code and want a lightweight security edge around generated diffs.
• Best first artifact: A scoped .mdc rule that asks for a linter run, a manual risk pass, and a short receipt before accepting sensitive changes.
• Best comparison angle: Compare VibeGuard against your existing scanner by running both on the same AI-generated branch and noting which findings are unique.
• Best Cursor habit: Use a Cursor skill or subagent for the repeatable check, but keep final approval separate from the agent that wrote the code.

Further reading

• Cursor — Agent
• Cursor — Rules
• vibeguard — source

Run it on one generated diff

Pick one AI-written branch that touches auth, SQL, files, or shell commands, then run a focused security pass before changing your process. If VibeGuard catches something real, turn that finding into a Cursor rule receipt you can reuse.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.