Security

Last updated June 2026. Every claim on this page is specific on purpose — if a statement here stops being true of the implementation, the statement is removed, not softened.

How it finds things

Curated rules, not just “ask an LLM”

Each audit dimension carries an enumerated ruleset, so the same checklist runs on every project and every finding keys to a stable rule id — not whatever the model happened to think of that run. The model reasons over your code against those rules; it does not freelance.

Deterministic grounding before the model runs

A static pass scans for hardcoded credentials (provider key formats and sensitive assignments) and checks your declared dependencies against the OSV vulnerability database. These matches carry a guaranteed-real file and line — they matched bytes that are actually there, so they cannot be a hallucinated location. Secret matches are still adjudicated by the model skeptic (is it a live key or a placeholder?); dependency advisories are database facts, so they are reported as confirmed and sourced to OSV, not run past the model.

Cross-file access-control check

A static pass enumerates your route handlers and flags the inconsistent one — an endpoint with no authentication or ownership check sitting among siblings that all have one (the “19 of 20 endpoints check auth, why not the 20th?” case). This broken-access-control / IDOR class is exactly what file-by-file review misses. Each flag is a candidatethe model skeptic then confirms or clears, so deliberately-public endpoints don't cry wolf.

Two independent models — and the second one adds, not just approves

In multi-model mode Aedis runs two finders from different vendors (Anthropic and OpenAI) over the same code, independently, then takes the unionof what they find. The point is recall: the second model surfaces issues the first missed, instead of only rubber-stamping the first model's list. One vendor can only see what one model sees — this is the difference between one model's recall and two.

A skeptic tries to refute every finding

Each surviving finding is handed to an adversarial cross-check instructed to assume it is a false positive and to enumerate why it might not be exploitable — input not attacker-controlled, sanitized upstream, unreachable, dead code. It is kept only if that refutation fails. Findings the skeptic rejects never reach you.

Findings are banded by how much the models agreed

You see how sure the system is, not a binary verdict. Confirmed = both models flagged it and the skeptic could not refute it; Likely = one model flagged it and the skeptic confirmed it; Needs review = one model flagged it and the cross-check could not confirm. The band is shown on every finding.

Honest about what it is good and bad at

Aedis is strongest on issues visible within a file — hardcoded secrets, injection, insecure credential storage, cleartext traffic, weak crypto — plus dependency CVEs and the inconsistent-authorization case described above. It is weaker on deep multi-file logic flaws, custom auth schemes the route scanner can't recognize, and anything that only manifests at runtime (it never executes your code). Treat results as a rigorous reviewer that catches far more than a single pass, not as a guarantee of completeness.

Your code

Processed in memory, never stored

Uploads are extracted and audited in server memory, per request. There is no database, no upload bucket, and no disk write — nothing of your code exists on Aedis infrastructure after the response is sent. Server logs record that a request happened and whether it failed, never file contents.

Never executed

The audit reads your code; it does not run it. There is no sandbox that executes uploads, because nothing executes uploads.

Hardened ingestion

The zip pipeline counts actualdecompressed bytes against hard caps (25 MB upload, per-file and whole-archive decompression ceilings, 10,000-file and 64-deep path limits), so zip bombs and path-traversal entries are rejected at the boundary. Entry names are sanitized before they can reach a log line or the UI.

Model calls

Keys never reach your browser

All model calls happen server-side behind a router seam. The provider modules are marked server-only, which makes the build fail if any client code ever imports them — the "no key ships to the client" promise is enforced by the compiler, not by review.

Named providers, bounded spend

Live audits send your files to Anthropic (find/fix) and OpenAI (independent cross-check) via OpenRouter, solely to perform your audit — named with policy links in the privacy terms. Neither trains on this traffic. Every audit carries a hard token budget, so a hostile or pathological upload cannot run an unbounded model bill.

Dependency checks send names, never code

On a live audit, the names and versions of your declared dependencies are sent to the OSV public vulnerability database to look up known advisories — package coordinates only, never your source. Simulated runs make no such call.

Model output is not trusted either

Everything a model returns crosses a validation boundary before it reaches you: severities are enum-checked, line numbers clamped, lengths capped, and malformed verification responses degrade to uncertain— never silently to "confirmed". Fix prompts are structured so file content cannot impersonate instructions.

Your consent

Nothing is applied without approval

Fixes are proposed as diffs computed locally from your original file versus the patched version — the diff you review is byte-for-byte the patch you receive. The download bundle is built only from fixes you explicitly approved. There is no auto-apply mode, and there will not be one.

The engine never lies about itself

Every audit response is stamped engine: live | simulated and the UI copy switches accordingly. You always know whether frontier models or the deterministic rule engine produced what you are reading.

Verify it

Check the transport security yourself

Every response carries a Content-Security-Policy, Strict-Transport-Security (1 year), X-Frame-Options: DENY, nosniff, Referrer-Policy and Permissions-Policy headers — run curl -sI https://aedis.stackrift.dev and read them. Rate limits apply per route; the audit endpoint is the most expensive and the most tightly capped.

Report a vulnerability

Found something? Email support@stackrift.dev with "Security report" in the subject. You will get a human reply, and a fix or an honest explanation — we audit other people's code for a living; reports against ours are taken as the compliment they are.