PRGuard vs Semgrep
Semgrep deserves real credit: it made custom static rules something you write in minutes, not an engineering project.
The difference with PRGuard isn’t effort — it’s expressiveness. A Semgrep rule is still a pattern that matches code shapes, per language.
A PRGuard rule is a sentence about what the code should mean, judged by an LLM against every change.
Semgrep
Fast, deterministic patterns you write per language.
PRGuard
Plain-language standards judged semantically — one rule, every language.
The verdict
Patterns for precision, sentences for meaning — a strong pair.
What Semgrep is built for
What PRGuard is built for
Take two standards most teams actually have:
“Payment webhook handlers must be idempotent” and “Never log plain-text credit card numbers.”
One is architecture, one is compliance — both are intent, not syntax.
rules:
- id: idempotent-webhook
languages: [python]
pattern: |
def $HANDLER(request):
...
$DB.create(...)
# matches only the code shapes you
# thought to write down, in Python
message: handler may not be idempotent
severity: WARNINGPayment webhook handlers must be idempotent.
The honest trade-off: Semgrep’s pattern fires identically every run; PRGuard’s judgment is an LLM’s, which is why a human approves every fix before it lands. Patterns for precision, sentences for meaning.
No pattern to write, no per-language variants. Here is PRGuard enforcing that one sentence on a pull request — recognising a non-idempotent handler by what the code means, and explaining the consequence in plain language.
non-idempotent-handler
Payments
Details
billing/webhooks.py:14
A retried webhook charges the customer twice. Stripe redelivers events after timeouts, and nothing here records what has already been processed.
Non-idempotent payment handler: in handle_webhook(), the charge is written at line 14 without checking ProcessedEvent. Because event.id is never recorded, a redelivered event re-executes the whole charge path — violating your rule that payment webhook handlers must be idempotent.
handle_webhook() with a guard: ProcessedEvent.objects.get_or_create(stripe_id=event.id), returning early when the event was already processed.
View rule: payments.md
Illustrative example. Findings are advisory by default — a person approves every fix before it lands.
| Semgrep | PRGuard | |
|---|---|---|
| Rules come from | Patterns authored in YAML, per language, from your own rules or the public registry | Plain-language context files your whole team writes |
| Analysis | Deterministic pattern matching at the core; AI-assisted detection in its commercial platform | LLM reasoning over the diff plus your rules — semantic judgment, human-approved before anything lands |
| Custom standards | Fast to write for patterns — but still patterns, per language, and Semgrep’s AI features don’t extend to your custom rules | Write a sentence once — it applies across every language |
| Typical catches | Banned APIs, dangerous calls, taint flows, known misuse patterns | A non-idempotent handler, personal data in a log line, a violated architecture decision, a broken money-handling convention |
| AI cost | Core matching is static, so it spends no tokens; AI features vary by tier | AI is the engine, and it’s included — no API key, no separate token bill |
| Fixes | Rule-defined autofix; AI-drafted fixes arriving in its commercial platform | Findings always; fixes on request — approve an AI fix and PRGuard commits it onto your PR’s branch (or opens a fix PR), then re-audits to close the finding |
| Price | Free open-source CLI; commercial tiers for deeper analysis, and your own hosting or their cloud | $10 trial, then flat plans with a metered AI credit allowance included |
Comparison last reviewed July 2026. Semgrep ships continuously, so its capabilities may have changed since — if anything here is out of date, tell us and we’ll fix it.
Fair question
It does, and it has moved well past triage. Semgrep Assistant auto-triages findings and drafts fixes, and the newer Multimodal detection pairs AI reasoning with its rules to catch complex security flaws. For vulnerability hunting, that’s genuine capability.
The nuance is whose rules the AI serves: by Semgrep’s own documentation, those AI features run on Semgrep’s detections — they aren’t available for the custom rules you write, which remain per-language patterns.
PRGuard starts from the other end: the rule is your sentence — your architecture, compliance, and business standards — judged semantically on every change.
Semgrep’s AI hunts known classes of vulnerability; PRGuard’s AI enforces the standards your team wrote.
If a standard is genuinely a pattern — a banned API, a dangerous call — Semgrep is the right tool and always will be.
PRGuard picks up where patterns stop: the intent-level standards your team debates in review, written once in plain language and enforced on every PR and push, with the AI included in the price.
No — they pair well.
Keep Semgrep for rules that genuinely are patterns: banned APIs, dangerous calls, framework misuse.
Add PRGuard for the intent-level standards a pattern can’t express, checked on every pull request and push.
A Semgrep rule is a pattern that matches code shapes, written per language.
A PRGuard rule is a plain-language sentence judged semantically — so one rule covers every language, and it recognises violations in code shaped nothing like anything it has seen.
No — not by PRGuard. We don’t build or train models of our own, and we never use your code or governance rules to train anything.
Your data stays scoped to your organisation, and diffs are processed in memory for the audit — never written to our database.
The audit runs through the major AI providers’ commercial APIs, whose current terms exclude data submitted this way from training their models, and we choose those channels deliberately for that reason. Those providers are third parties under their own terms, which are outside our control, so our privacy policy spells out exactly what is sent and to whom.
AI usage is part of your subscription, not a bill on the side. Every plan includes a set monthly AI credit allowance, and each audit draws from it — no separate API key to bring, no separate token invoice. And if a busy month needs more, top-up credits are available anytime and roll over.