Semgrep Guardian vs. CodeTruss Boundary: find the vulnerability, or prove what was checked?
Guardian is Semgrep pointed at the agentic moment: it scans every file an agent writes, at write time, with the same rules-and-dataflow engine behind Semgrep Code, Supply Chain, and Secrets, then prompts the agent to regenerate until the scan is clean. It is deterministic detection with LLM remediation, and it is very good at what it does. CodeTruss Boundary is not a rules race. It answers the change-level question Guardian does not ask — did this agent stay inside its assigned scope, did the exact final state pass the checks this repository requires — and it leaves a signed artifact that says what was checked and what was not.
Use Semgrep Guardian when...
Teams that want deep, deterministic vulnerability detection — 35+ languages, cross-function and cross-file dataflow analysis, secrets and dependency scanning, org-level rule policies, SARIF and GitLab SAST output — enforced at write time across whatever agent or IDE the team uses, and rolled out centrally without installing anything on laptops.
Use CodeTruss when...
Developers and teams that need the change itself governed and recorded: an explicit task contract, scope classification of every touched path, your own verification commands, and a signed receipt a third party can re-verify offline — with a deterministic path that requires no account and no network call.
Feature comparison
| Question | CodeTruss | Semgrep Guardian |
|---|---|---|
| Primary job | Gate the change: classify every path an agent touched against an explicit policy, run analyzers and repository verification commands, and issue a deterministic PASS, REVIEW_REQUIRED, or FAILED with reasons. | Find the vulnerability: scan every file an agent generates for vulnerabilities, malicious packages, and hardcoded secrets, then prompt the agent to regenerate the code until the scan comes back clean. |
| Detection depth | The security rule pack runs locally in the CLI over JavaScript, TypeScript and TSX — the same rules and the same source-to-sink taint tracking as the hosted audit, with no account, no upload, and no network call. Python runs locally too, behind an opt-in grammar pack (codetruss grammars install python) whose artifacts are pinned to exact SHA-256 digests compiled into the binary and re-verified on every load; installing it is the only network call, and analysis never makes one. Because that pack is the hosted parser, Python is scanned with the whole rule pack rather than the narrower subset the CLI's own JavaScript parser is restricted to. The cross-file symbol graph stays hosted, and so does the route authorization graph — missing authorization (CWE-862) and cross-tenant object references (CWE-639) are hosted-only, security-scan-only, Prisma and Drizzle only, and produce no finding at all in a repository with no machine-readable schema. On a seeded 6-bug fixture the local pass flagged the SQL injection as CRITICAL with its taint path (request input → query call) and the un-awaited database write as MEDIUM, in 0.39 seconds (CLI 0.2.38). The published benchmark is 6 of 9 AI-agent bug classes detected with 0 false positives across 8 repositories — and the 3 misses are named. That 0 is a result on that corpus and not a general precision claim: a larger ten-repository corpus we did not choose found false positives, including a CRITICAL SQL-injection report on a parameterized drizzle query, fixed in CLI 0.2.53. Semgrep has the deeper security ruleset today, and we say so. | Semgrep rules encapsulating pattern matching and dataflow analysis, interprocedural by default and optionally cross-file, across 35+ languages with published GA/beta/experimental maturity tiers per language. |
| Account and data boundary | The deterministic path needs no account and makes no CodeTruss request. Only an explicit sync uploads one redacted receipt, never the patch. | A Semgrep account is required. In Claude Code, Guardian uses a remote server by default; other IDEs run the Semgrep CLI locally, and the local-scan docs describe sending findings to the platform with a --dry-run option to suppress that. Semgrep Community Edition is separately free, LGPL-licensed, and runs locally without login. |
| Output artifact | A signed Markdown and JSON receipt: task, scope, findings, check results, verdict, explicit reasons, and content hashes, re-checkable offline with codetruss verify and no CodeTruss account. The signature proves the receipt was not altered after signing, not who ran it. | Inline agent feedback plus the full Semgrep CLI output surface — JSON, SARIF, GitLab SAST, JUnit XML — and granular exit codes, with platform metrics tracking issues introduced and fixed. No signing, attestation, or provenance is mentioned on the Guardian docs, launch post, product page, CLI reference, or pricing page. SARIF is an interchange format, not a verifiable one. |
| Accuracy disclosure | The full corpus, method, per-target sweep, and the three undetected bug classes are published, including what the benchmark does not show. | Semgrep publishes numbers and their limits — a metrics page with confidence rates and an explicit caveat about what they do not mean, plus a third-party Doyensec comparison showing its own free Community Edition detecting 48% and 44% of true positives against 72% and 75% for Semgrep Code. Publishing an unflattering third-party result is rare, and it is to their credit. |
| Price of the free path | The CLI is free with no repository or contributor cap on the deterministic local path. | Guardian is included in all three tiers. The free Semgrep tier covers up to 10 contributors and 10 repositories; Teams starts at $30 per contributor per month for Code. Community Edition is free and unlimited with 3,000+ open source rules. |
Market facts checked 2026-08-07. Sources: Semgrep Guardian launch post · Semgrep Guardian docs · Semgrep Code overview · Semgrep supported languages · Semgrep CLI reference · Semgrep pricing · Doyensec comparison of Community Edition and Semgrep Code
Everything in the Semgrep Guardian column is what that vendor publishes, quoted so you can check it. We have run no cross-tool benchmark, so nothing here claims we detect more, better, or with fewer false positives than they do. Vendor capabilities and plans change; verify current details with the vendor before buying.
Bottom line
Do not choose between these on rule count — Semgrep wins that, and Guardian is the stronger vulnerability detector at write time. Choose on what you need to hold afterward. Guardian tells an agent to fix the file; Boundary decides whether the finished change was inside its authority and leaves a signed record of exactly what was checked, what was skipped, and why the verdict came out as it did. If your problem is "the agent wrote something insecure," run Guardian. If your problem is "we cannot prove what was verified before this merged," run Boundary. Most teams shipping agent-written code have both problems.
Next decision points
Review one real change
Run the account-free local workflow on work an agent has already changed.
Inspect the boundary
See exactly how scope, sensitive surfaces, analyzers, checks, and receipts fit together.
Read the network boundary
Verify what stays local, what a provider receives, and what explicit sync uploads.