Precedent

An agent that remembers every security warning your team has ever dismissed—and why—so nobody re-investigates the same false positive twice

Comment

Inspiration

Inspiration I’ve always hated how security scans slow developers down. You run a static analysis (SAST) tool, and it immediately blasts you with what I call an "alert cannon"—dozens of warnings with zero context . The real kicker? Roughly two-thirds of the security alerts we actually take the time to review are just false positives . If a developer spends two hours digging into a complex CVE only to realize it's a false alarm, that decision is usually typed into a pull request comment and immediately forgotten . The moment a different repository (or even the same repo on a subsequent run) flags the same warning, the next developer has to start the entire investigation from scratch . I built Precedent to give development pipelines a persistent, queryable memory so we never have to solve the same false positive twice .

What It Does

Precedent is a scanner-agnostic, serverless overlay that sits on top of whatever security tools you already use (like Semgrep, Snyk, or Trivy) . When your scanner finishes, you throw its raw JSON output at our ingest endpoint . Precedent instantly coordinates a multi-step agentic loop: Semantic Matching: It converts the raw warning into a lightweight vector and searches our operational database for similar past alerts . Ink-Stamp Badges: On our S3-hosted React UI, it stamps the warning with a physical, tactile "Precedent Found" or "No Precedent" ink-stamp . It surfaces what was decided last time, the actual human reasoning, and the exact match distance . Audit Trail: You can click "View Audit Trail" to see the full chronological history of a CVE across your entire fleet for absolute compliance transparency . Interactive Decisions: You can hit Accept to rubber-stamp the recommendation, or Override to type a new decision . The second you hit submit, the database learns it, compounding Precedent’s memory for the next scan . Shared Precedents: We built a toggle that lets you anonymously pool your reasoning with other organizations . If a peer team has already solved a common open-source CVE (like a prototype pollution bug in lodash), you get to leverage their reasoning instantly

How I Built It

We designed Precedent to be 100% serverless, elastic, and run at virtually $0 in operational costs The Memory (CockroachDB Serverless): All warnings and human verdicts are stored in a CockroachDB Serverless cluster . We used Distributed Vector Indexing directly on a VECTOR(128) column to run high-performance similarity searches right inside our primary relational database, preventing any sync drift . The Handshake (Managed MCP Server): To check how widespread a vulnerability is across codebases, our ingest Lambda queries the CockroachDB Cloud Managed MCP Server to run isolated, read-only cross-repo lookups via JSON-RPC over Server-Sent Events (SSE) . This keeps our direct write-credentials secure . The Logic (AWS Lambda): We deployed four stateless Python 3.12 Lambdas (Ingest, Decide, History, and an embed backfill helper) . The UI (S3): The frontend is a single static React page hosted directly out of an Amazon S3 bucket

Challenges I Ran Into

The biggest hurdle was a nasty database deadlock . Early on, our ingest Lambda would randomly freeze and time out . I realized our Lambda was inserting a new warning but keeping the database transaction open . In the middle of that uncommitted transaction, the Lambda called the CockroachDB Managed MCP Server to run a SELECT query on that exact same table to calculate the cross-repository frequency . Because the write lock was still held, the MCP server was blocked, causing a classic self-lock . Committing each insert immediately before triggering the MCP query completely solved the issue . We also wrestled with the Server-Sent Events (SSE) streaming protocol on the MCP server . Since stateless Lambdas expect a clean JSON payload and MCP channels stay open indefinitely, we had to write a custom streaming parser that reads the stream line-by-line and shuts down the connection the instant it gets the matching JSON-RPC response ID .

Accomplishments That I am Proud Of

We built a fully functioning, closed-loop system . Being able to upload a raw scanner payload, watch it pull reasoning from a fictional second organization with a beautiful teal "shared community" badge, and then write our own custom override that instantly gets learned for the next run was an incredible "it actually works!" moment .

What I Learned

I learned that orchestrating autonomous agents that read and write to the same transactional database requires being incredibly careful with session lifecycles and locks . I also realized that finding out Semgrep recently shipped a proprietary "Memories" feature wasn't a project-killer—it was validation . It proved alert memory is the future of AppSec . But unlike Semgrep's vendor-locked, closed SaaS platform, Precedent is scanner-agnostic, completely inspectable, and 100% self-hostable .

What's Next for Precedent

Moderation before sharing — right now, opting into the cross-org shared pool is a self-serve checkbox. Before this could be used by real organizations, that needs a review step so nothing company-specific slips into anonymized precedent by accident. Native scanner adapters — Precedent already accepts any tool's JSON output generically. Purpose-built parsers for Trivy, Grype, and Snyk's specific formats would remove the small amount of manual mapping currently needed. Org-level admin controls — usage analytics, override-rate tracking per team, and visibility into how often shared precedent actually gets used versus overridden, so a security lead can see whether the memory is actually earning trust. Swap the free embedder for a real one, behind a flag — the zero-cost hashing vectorizer was a deliberate choice to keep this hackathon build free to run, but it's a ceiling on match quality. A proper embedding model (still cheap, still optional) would catch paraphrased warnings the current version misses. Expiring or re-confirming stale precedent — a dismissal reasoning from two years ago might not hold up after a codebase changes. Some notion of precedent "aging out" and needing re-confirmation is the natural next trust mechanism.

Share this project:

Updates

Submission history