leeh vs Semgrep: They Scan What's Inside. We Guard the Gate.
They inspect the house after the guest is already inside. leeh checks the guest at the door.
The Obvious Question
"Semgrep and Snyk already scan code for vulnerabilities. Why do I need leeh?"
It's a fair question. And the answer is simple:
They solve different problems.
Semgrep scans code that's already in your repository. leeh controls whether code reaches your repository in the first place.
What Semgrep / Snyk / GitHub Advanced Security Do
These are excellent tools. They perform static analysis on your codebase:
Find SQL injection patterns
Detect hardcoded secrets
Flag insecure deserialization
Check for known CVEs in dependencies
They run in CI/CD pipelines, in pre-commit hooks, or on scheduled scans. They analyze code that already exists in your repository.
This is valuable. No one should stop using these tools.
But they all share one assumption:
The code is already inside your network.
The Gap Nobody Talks About
Here's the scenario these tools don't address:
A developer uses Claude Code on an isolated AI workstation
They generate 500 lines of Python
They somehow transfer it to the internal network
It lands in the repository
Now Semgrep scans it
Steps 1 through 4 have zero security controls.
Who sent this code? (No signature verification)
Was it modified in transit? (No integrity check)
Was it quarantined before landing? (No isolation)
Is there an audit trail of the transfer? (No logging)
Did a human approve it? (No attestation)
The code arrived. It's in the repo. Semgrep finds no vulnerabilities. Everyone moves on.
But how it got there — that's the blind spot.
What leeh Does Differently
leeh doesn't replace Semgrep. leeh sits before Semgrep.
Without leeh:
AI tool → (uncontrolled transfer) → Repository → Semgrep scan
With leeh:
AI tool → leeh push → Gateway → Signature verify → Scan → Quarantine → Repository
| Capability | Semgrep/Snyk | leeh |
|---|---|---|
| SAST scanning | Yes | Yes (uses Semgrep internally) |
| Secret detection | Yes | Yes (uses gitleaks internally) |
| Ed25519 signature verification | No | Yes |
| SHA-256 integrity check | No | Yes |
| 3-state quarantine | No | Yes |
| One-way transfer enforcement | No | Yes |
| Admin approval gate | No | Yes |
| AI code intent analysis | No | Yes (Semantic Scrubber) |
| Transfer audit trail | No | Yes |
| Spec Contract path enforcement | No | Yes |
leeh actually uses Semgrep and gitleaks as part of its scanner pipeline. They're complementary, not competing.
The Real Difference: Pre-Entry vs Post-Entry
Think of it like airport security:
Semgrep = the security camera inside the terminal. It watches what happens after you're already inside.
leeh = the checkpoint at the entrance. It verifies your identity, scans your luggage, and decides whether you're allowed in.
Both are necessary. But if you only have cameras and no checkpoint, anyone can walk in.
Why This Matters for AI-Generated Code
Traditional code review assumes a human wrote the code, committed it through git, and a reviewer checked it. The chain of custody is implicit in the git workflow.
AI-generated code breaks this assumption:
Volume: AI can generate thousands of lines per hour. Manual review can't keep up.
Origin: The code wasn't written inside the network. It was generated externally and transferred in.
Identity: Git author names are self-reported strings. Anyone can claim to be anyone.
Autonomy: AI coding tools can execute shell commands. An AI agent could run
leeh pushdozens of times without human intervention.
For code that originates outside your network, you need more than a scanner. You need a controlled entry point.
When You Need Both
Use Semgrep/Snyk for:
Scanning code written by internal developers on internal machines
CI/CD pipeline checks
Dependency vulnerability scanning
Continuous monitoring of existing codebases
Use leeh for:
Any code that originates from an external AI development environment
When you need cryptographic proof of who sent the code
When you need a quarantine step before code touches internal Git
When your security policy requires inbound verification
When AI agents can push code autonomously and you need a human gate
Use both together for:
- Complete security = outbound blocking + inbound verification + internal scanning
The Bottom Line
Semgrep asks: "Is this code safe?"
leeh asks: "Should this code be allowed in?"
Different questions. Different layers. Both essential.
leeh — LLM Escrow & Entry Hub. One-way secure inbound pipeline for AI-generated code.