🧪 Variablee · Frontier AI Security Lab

Vulnerability detection
for large enterprise codebases ✨

Our patent-pending algorithm AI security MW for code parsing slices your app into routes with execution and auth logic, each in its own digestible context slice, allowing frontier models to review each route for vulnerabilities.

TLDR: Let us show you the vulnerabilities in your code.

96%of known BOLAs caught (24 of 25) on our benchmark
1 / 28false positives on routes known to be safe
4real-world apps with published BOLAs, from CVEs to OWASP targets
9frameworks across Ruby, Python and JavaScript / TypeScript

Benchmark: OWASP RailsGoat, OWASP crAPI, dvws-node and aegra (CVE-2026-44504). See the full results →

🧩

1. Parse

Indexes every method and class across Ruby, Python and JS / TS, and finds every route in Rails, Django, FastAPI, Express, NestJS and more.

✂️

2. Slice

Follows each route through its auth filters, middleware and guards into the handler and the calls that read or write data, and packs that path into its own context slice.

🧠

3. Reason

A frontier model reviews each slice on its own: is the requested object tied to the current user? Every flag comes with evidence and a fix.

One route, one slice

Only the code that runs for this request goes to the model, in the order it runs:

GET /orders/:id → OrdersController#showroute
ApplicationController#authenticate_user!auth filter
OrdersController#showhandler
Order.find(params[:id])data access, not scoped to current_user

Because each slice is small and self-contained, the codebase's size doesn't limit the review: every route gets the model's full attention.

The bug class

One ID swap away from someone else's data

A signed-in user changes an ID in the URL and gets another customer's invoice, order or account. Nothing crashes and no pattern matches: the bug is a permission check that isn't there. That's BOLA / IDOR, the #1 risk in the OWASP API Security Top 10.

Diagram: a caller-controlled invoice ID flows from the request through the controller and an ID-only lookup to the response, with no object-level permission check
Our method

One route at a time

We inventory every route, collect the shared middleware and the handler code that governs the object ID, and review access for that route alone. Then the next route, until the whole inventory is covered.

Three steps: inventory routes, collect route context (shared middleware, handler and calls), review access and flag a possible BOLA
Under the hood

A real context slice

This is the actual trace for one route: the handler, every call it makes with its file and lines, and the source of each filter on the way. That slice, and nothing else, is what the model reviews, so a large codebase never crowds out the code that matters.

JSON trace of GET /admin/users/:id: its handler, the calls it makes with file and line ranges, and the source of its before filter
What you get

Findings you can triage

Each candidate names the auth it passed, the check that's missing, nearby checks that hint at intent, and a concrete next step to confirm it, so your team spends time on real issues.

Illustrative scan output: three candidate BOLA findings, each with shared auth, the missing or unclear check, a nearby check, and a next step
Sella Rafaeli
From the lab
AI-native SAST for IDOR / BOLA How we built BOLA Detector, by Sella Rafaeli · Read the blog post →