middleware entry point session_token auth_logic token check request_ctx trust_boundary unenforced cors_policy rate_limit csrf_token input_validation secrets_scan 22 categories jwt_verify api_gateway data_flow permissions db_access row_policy storage env_config hardcoded_secret SERVICE_ROLE_KEY bypasses RLS catch_block swallows error fail_open auth skipped RLS_bypassed all rows exposed trust_boundary violated CRITICAL unauthenticated db access

Pattern matching
can't reason.
We can.

Most breaches don’t come from unknown vulnerabilities. They come from the interaction between ordinary decisions. We built the tool to see that.

Three things are true at once.
01
Code is shipping faster than it can be reviewed.
AI assistants write production code in minutes. Release cycles that used to take weeks now take hours. More code is reaching production, with less time to scrutinize it.
02
The tools watching it find only what they were taught.
Pattern matching. Signature databases. CVE lookups. Useful against known-bad, silent about everything else. They have no model of your system. They can't follow logic across files or reason about what the code actually does.
03
The breaches live in that silence.
The vulnerability in the intersection of three ordinary decisions in your codebase has no CVE. No rule was written for it. It's unique to your system — and scanners walk past it.
What we built.

A good security engineer does not review a codebase as a pile of files. They build a model of the system: how data moves, where trust changes, what permissions exist, and what happens when something fails.

Tools that reason like a security engineer.
Data flow Trust boundaries Permissions Failure behavior Compound impact

The goal is not to find more isolated findings. The goal is to understand what those findings become when they interact.

The relationship
is the vulnerability.

Attackers don’t exploit findings in isolation. They chain them together, and the risk compounds. The tool is built to reason through that chain.

High High confidence
Service-role key used in middleware
middleware/auth.ts · line 47
Supabase client initialized with SERVICE_ROLE_KEY, bypassing every Row Level Security policy on the database.
+
Medium High confidence
Empty catch block causes fail-open
middleware/auth.ts · line 53
Auth errors are swallowed silently. If token validation throws, the request continues as authenticated.
Critical High confidence
Unauthenticated full database access
Token validation fails silently and the request continues. The middleware client carries a service-role key, giving an unauthenticated caller unrestricted read and write access to every row in the database. RLS does not apply. Neither finding is critical in isolation. Together they are.
AI is the reasoning layer.

AI is not useful here because it knows every vulnerability pattern.

It is useful because it can read a codebase, hold system context, follow relationships, and ask what becomes possible when pieces interact.

Inference Security is built on that shift: AI as the reasoning layer over code paths, trust boundaries, and compound risk.

AI reasoning layer
Holds full codebase context Follows chains across files Infers failure modes Reads docs and config Reasons about intent Identifies compound impact
Compound risk
Inference Recon is the first tool.

Run it against a local repository inside Claude Code or Codex. It builds a model of your codebase — control flow, data flow, trust boundaries — follows relationships across files, and produces a graded security report with exploitation paths for every finding.

Open source. Early release. Works today.

sample output · real project · 41 files · Next.js + Supabase · claude-opus-4-8
Code
F
Dependencies
A
Secrets & Config
C
Architecture
F
Overall
F
Dev admin bypass grants any authenticated user full admin access — against the production database
critical conf: high ARCH_auth_bypass OWASP A01
Evidence — lib/adminAuth.ts
export async function requireAdmin() {
  if (process.env.NODE_ENV === 'development' &&
      !process.env.ADMIN_CLERK_IDS) {
    return true  // ← any authenticated user becomes admin
  }
  // validate against ADMIN_CLERK_IDS allowlist...
}
Cross-reference — project documentation
Dev and production share one Supabase project.
Scripts, migrations, and local dev runs connect to production directly.
Why this is critical

The requireAdmin() short-circuit is a reasonable dev convenience in isolation. The shared production database is a separate architectural decision. Neither is the vulnerability on its own — the intersection is. Any developer who has ever been granted a session can run locally without ADMIN_CLERK_IDS set and gain unrestricted admin access to live production data.

local dev + no env var set → admin on production → every user record exposed
Inference Recon · Coming Soon
Contact

Built by a security engineer with multiple decades of experience defending systems at scale. This is the tool I needed. It didn't exist. So I built it.

mark@inferencesecurity.ai