Security for the era of vibe coding.
ADA scans your code and detects vulnerabilities using semgrep and a dedicated secret scanner, catching real issues like SQL injection, command injection, and leaked API keys.
ADA is an accuracy-first, AI-native vulnerability platform for the vibe-coding era. Developer-first. Trust-obsessed.
People don't trust scanners — too many false alarms, or worse, missed real bugs. So we obsess over one thing: accuracy. Not finding counts. Not flashy dashboards. Just what's real.
When developers engage in vibe coding—using AI to rapidly generate features
via natural language without worrying about syntactic details—traditional security testing
breaks down. Generative models are trained to prioritize "making the code work on the happy
path." As a result, research shows that 40% to 60% of unguided
AI-generated code contains security flaws like unparameterized SQL, missing auth checks,
or insecure deserialization (pickle.loads()).
Measured against 1,526 annotated vulnerable lines across 429 files — a corpus written by Semgrep's own team, never seen while ADA's rules were authored.
Our custom ruleset beats Semgrep's flagship security pack head-to-head — 29.8% versus 25.2% on the same corpus, rule-for-rule. Run together they reach 92.4%, because they catch different vulnerabilities: ours target the idioms that show up in AI-generated code and nowhere else. Every number is reproducible from the benchmark harness in our repo, caveats included.
We don't chase headline vulnerability counts. A finding that isn't real isn't a feature — it's noise. Signal over volume, always.
Every finding traces back to a rule you can audit — detection is 100% semgrep, trufflehog and OSV. AI reads findings afterwards to judge and explain them; it can question a finding, never invent or hide one.
Shipping fast with AI-generated code isn't going away, and it shouldn't have to. ADA fits into that workflow instead of asking you to slow down for a security review you'd skip anyway.
We're shipping alongside the people who use this daily. Fast iteration, real feedback loops, zero ivory tower.
Safe should be the easy path, not the extra step. We're building toward guardrails that fit into how code already gets written.
You shouldn't need a security degree to ship safely — that's the whole point. Built for builders using Lovable, Bolt, Cursor, and everything in between.
The moat isn't detection — Snyk, Semgrep, and CodeQL already do that well. It's understanding. AdaRE is the reasoning layer that sits on top of every scanner: it re-reads each finding in context, separates real threats from false alarms, explains the impact in plain English, and generates a fix you can actually trust — the judgment a security engineer adds, on top of scanners we integrate rather than try to replace. It already powers the triage, explanations, and suggested fixes you see in the scanner today.
Scan as you code, right inside your editor — catch issues the moment they're written, before they ever reach a commit.
Don't just flag what's wrong — get the safer fix, ready to apply. Remediation, not just detection.
Threat modelling and attack simulation on top of findings — show the actual exploit path, not just the flagged line. Aggregating more scanners as we go, since detection is a commodity and judgment isn't.
Our backgrounds span offensive security and applied AI, and ADA is built at that intersection.
Detection — the ruleset, the benchmark harness, the security model behind the app itself — comes from graduate cybersecurity work at Georgia Tech and hands-on offensive security: web application attacks, binary exploitation, intrusion detection, and exploiting Log4Shell in controlled environments.
AI triage comes from Stanford CS and production engineering on an AI-powered security platform — LLM agents, retrieval pipelines, and vulnerability management workflows.
Finding vulnerabilities and judging which ones actually matter are different problems. We build them as different systems, and we publish the numbers for both.
Want to get in touch, or see the full team's LinkedIn profiles and backgrounds? Send us a message.
Send us a message and we'll get back to you — or email us directly at contactus@adasecure.net.
Last updated: 31 July 2026
ADA is a security scanner. You paste code into it, so we think you deserve an unusually specific answer about where that code goes. This page is that answer — no vague "we may share data with partners."
If you scan without an account: the code you paste is processed to run the scan, and a record of that scan — the code, the findings, and the write-up — is kept so we can measure usage and improve the scanner. That record isn't linked to you: no account, no IP address, no session identifier. See "We keep a record of every scan" below. Your IP is used in memory to enforce rate limits and isn't stored with the scan.
If you sign in with Google: we receive and store your email address, name, profile picture URL, and Google account ID. We also save your scan history — the code you scanned, the findings, and the AI write-up — so you can revisit past scans.
If you use the contact form: we store the name, email address, and message you submit, plus your IP address.
Running a scan sends data to these third parties. This is the section most privacy policies leave vague, so here it is in full:
requirements.txt or package.json, the package names and version
numbers are sent to look up known vulnerabilities. Your code is not sent.The scanners themselves (semgrep and trufflehog3) run locally on our server. We have explicitly disabled semgrep's usage telemetry, so no scan data is reported to them.
This applies whether or not you have an account. When you run a scan, we store the code you submitted, the findings, the risk verdict, and the AI write-up. We use these records to measure how ADA is used, to see which detection rules fire on real code and which produce false positives, and to improve the scanner.
These records are not linked to you. We store a flag for whether the scan came from a signed-in account, but not which account, and no IP address or session identifier. Credentials are masked first, exactly as described below.
If you're signed in, your scan history is stored separately and is linked to your account — that's what makes the history dropdown and report export work.
The practical version: don't paste code you wouldn't be comfortable having stored on our servers. If your employer restricts sending source code to third-party services that retain it, that restriction applies here.
If a scan detects a credential (an API key, token, or password) in your code, we mask it
before saving anything to our database. The masked form keeps just enough to identify which
credential it was — for example AKIA…[redacted]. Live secrets are not stored in
plaintext.
That said: if you paste a real, active credential, you should treat it as exposed and rotate it. It passed through our server and Anthropic's API in order to be scanned.
Two cookies, both first-party. No advertising cookies, and no third-party analytics — we don't load Google Analytics or anything like it.
ada_vid) — a random ID we generate, used to
count visitors and to see whether people come back. It's an analytics cookie, so we'll call
it what it is: it does track your return visits. It contains a random string and nothing
else — no name, no email, no IP, and no link to your account if you have one. Clearing your
cookies resets it and we lose the connection entirely.We record page loads: the page, the time, the visitor cookie above, and the domain
of the site that linked you here (for example reddit.com) — never the full
referring URL, which can contain search terms. We use this to know how many people visit, how
many go on to run a scan, and where they came from.
Requests from bots and crawlers are excluded, and we don't store IP addresses against page views.
Account details and scan history are kept until you ask us to delete them. Contact messages are kept so we can reply and follow up. Scan records (see below) are kept indefinitely at present; if we adopt a fixed retention period we'll say so here.
Email contactus@adasecure.net and we'll delete your account and its scan history. We're a small team — expect a human reply, not an automated portal.
If this policy changes materially, we'll update the date at the top. Continuing to use ADA after a change means the updated policy applies.
Questions about any of this: contactus@adasecure.net.
Last updated: 28 July 2026
The rules for using ADA. The most important part is the section on what ADA does not guarantee — please actually read that one.
ADA scans code you provide for common security problems: hardcoded secrets, risky code patterns, and known-vulnerable dependencies. It then uses AI to explain the findings, judge which are likely false positives, and suggest fixes.
This is the part that matters most. A clean scan does not mean your code is safe. ADA finds specific classes of known problems — it does not find every vulnerability, and no scanner does. Do not treat ADA as a substitute for a security review, a penetration test, or your own judgment.
ADA is provided "as is", without warranty of any kind. We are not liable for any damages, breach, or loss arising from your use of it — including vulnerabilities ADA failed to detect, or findings it reported that turned out to be wrong.
The summaries, the "likely real / likely false positive" triage, and the suggested fixes are generated by an AI model. They can be mistaken. Suggested fixes are suggestions — review and test them before putting them anywhere near production. ADA never applies a fix to your code automatically, by design.
Don't submit code you don't own or otherwise have the right to share, and don't submit code you're contractually barred from sending to a third-party AI service. Scanning sends your code to Anthropic — see the Privacy Policy.
Rate limits apply. Don't try to bypass them, don't use ADA to attack it or anything else, and don't resell access. We can suspend accounts that abuse the service.
You're responsible for what happens under your account. Accounts are created via Google sign-in; keep that account secure.
These terms may change. Material changes get a new date at the top, and continuing to use ADA means you accept them.