⊘
Assistants refuse the work
General-purpose models are tuned to back away from anything that looks offensive, so the defensive review your team actually needs gets declined or answered in generalities.
RUNS ENTIRELY ON YOUR HARDWARE
Security review that never sees the cloud
Coding agents that audit your source the way a security engineer would, on a developer laptop or a build server you control. No upload, no telemetry, no third party holding your code.
5STAGE PIPELINE
0BYTES LEAVE THE MACHINE
ANYCODEBASE SIZE
WHY THIS EXISTS
Security is where most
AI tooling stops
Three walls block teams that want AI help finding real vulnerabilities. The harness was built to get past all three.
↑
Scanners want your source
Cloud analysis means shipping a regulated codebase to a vendor. For most banks, insurers, and agencies that ends the conversation before the trial starts.
∞
Legacy code breaks context
A few million lines will never fit in a prompt. Tools that try end up skimming, which is why they miss the flaws that span four files and two decades.
LOCAL BY DESIGN
Your code stays
on your machine
The harness installs like any other developer tool and runs against a checkout on local disk. Engineers can point it at a repository on a Monday morning and read findings the same day, with nothing crossing the network.
- ✓Source, findings, and logs never leave the host
- ✓Runs fully offline, including on air-gapped build machines
- ✓No telemetry, no phone-home, no vendor dashboard
- ✓Model runtime is yours: local weights or your own hosted endpoint
- ✓Same binary on a laptop, a workstation, or a CI runner
HOW IT WORKS
A tailored investigation,
in five stages
The harness does not grep for patterns and hand you a list. It narrows the codebase down, then investigates each candidate properly before anything reaches your queue.
Static analysis narrows the field
The run starts with a full static pass over the repository. It builds the file graph, resolves imports, and scores every file on how much security-relevant surface it carries.
- ▸Flags the code that handles authentication, sessions, crypto, deserialization, queries, file paths, and process execution
- ▸Weights by reachability, so code behind a public route ranks above an internal script
- ▸Language agnostic, including the older stacks that carry the most risk
OUTPUT · A ranked candidate list, not a raw dump
auth/session.py
billing/reports.rb
api/upload_handler.go
legacy/xmlparse.java
ui/theme.css
An agent opens every candidate
Each ranked file gets its own investigation. The agent reads the code in context, follows the call graph across file boundaries, and traces untrusted input from where it enters to where it lands.
- ▸Traces data flow from source to sink, through helpers and across modules
- ▸Checks trust boundaries: what is validated, where, and by whom
- ▸Reads migrations and config alongside the code, so a fix that never shipped is caught
- ▸Works file by file, so a four million line repository is a queue, not a context limit
OUTPUT · Candidate findings with the path that proves them
params[:report_id] · HTTP request
↓ ReportsController#show
↓ ReportQuery.build (no sanitizer)
↓ ActiveRecord::Base.connection
execute(sql) · raw SQL sink
4 FILES CROSSED
NO VALIDATION FOUND
REACHABLE FROM ROUTE
A second agent tries to break it
Every candidate is handed to an independent agent whose job is to disprove it. It looks for the sanitizer upstream, the framework protection, the guard clause, the reason the path cannot actually be reached.
- ▸Anything that cannot be shown as a real, reachable path is dropped
- ▸Framework and library defenses are checked before a finding survives
- ▸This is the stage that keeps the queue short enough for people to trust it
OUTPUT · Findings that survived an attempt to kill them
✓ KEPT · no sanitizer on any path to the sink
✕ DROPPED · ORM escapes this parameter
✕ DROPPED · unreachable, dead since 2019
✓ KEPT · guard runs only when a flag is off
167 CANDIDATES
46 SURVIVED
Findings become something you can act on
Survivors are written up the way a good security engineer writes them up. Severity, classification, the exact path, the affected code, and a concrete suggestion for the fix.
- ▸Severity rated on exploitability and blast radius, not on pattern name
- ▸CWE classification and the owning team, resolved from code ownership
- ▸A remediation sketch, so the ticket starts with a direction instead of a debate
OUTPUT · Reviewed findings with severity and a suggested fix
CRITICALbilling/reports.rb:118
HIGHauth/session.py:64
HIGHapi/upload_handler.go:203
MEDIUMlegacy/xmlparse.java:77
CWE MAPPED
OWNER RESOLVED
FIX SKETCHED
Out to the tools your team already uses
Results leave as standard formats your security stack understands, or as tickets in the tracker your engineers live in. Where the export goes is your decision, and it is the only point where anything moves.
- ▸SARIF for code scanning dashboards and pull request annotations
- ▸JSON for your own pipelines, Markdown for the review meeting
- ▸Optional tracker integration, with the full audit log of the run attached
OUTPUT · SARIF, JSON, Markdown, or tickets
⇩ findings.sarif
⇩ findings.json
⇩ report.md
⇩ audit-log.jsonl
46 findings ready
COVERAGE
What the agents look for
Whole classes of flaws, judged on whether they are reachable in your code rather than whether they match a pattern.
InjectionSQL, command, LDAP, and template injection traced from input to sink.CWE-77 · 78 · 89
Auth and accessBroken session handling, missing checks, and privilege paths around them.CWE-287 · 862
Crypto misuseWeak algorithms, hardcoded keys, bad randomness, unsafe comparisons.CWE-327 · 330
DeserializationUntrusted objects, XML entity expansion, and unsafe parser configuration.CWE-502 · 611
Path and file handlingTraversal, unsafe uploads, and temporary file races.CWE-22 · 434
Server-side requestsRequests built from user input reaching internal networks.CWE-918
Secrets in codeCredentials, tokens, and keys committed to the repository or its history.CWE-798
Drift and missing fixesMigrations and config that never caught up with the code they protect.CWE-1188
SAMPLE FINDING
What lands in your queue
CRITICAL
Unparameterized query reachable from a public report route
CWE-89 · SQL INJECTION
A report identifier taken straight from the request is interpolated into raw SQL four calls downstream. No sanitizer runs on any path between the controller and the sink, and the route is reachable without authentication when the legacy sharing flag is enabled.
116# ReportQuery.build
117- sql = "SELECT * FROM reports WHERE id = #{opts[:report_id]}"
118+ sql = "SELECT * FROM reports WHERE id = ?"
119+ binds = [opts[:report_id].to_i]
FILEbilling/reports.rb:118
ENTRY POINTGET /reports/:report_id
DATA FLOW4 files, 0 sanitizers
OWNERteam-billing
REVALIDATIONsurvived 1 refutation pass
BUILT FOR SCALE
Size is not the limit
Because the harness works through a queue instead of a prompt, the codebase can be as old and as large as it really is.
4M+Lines in a single run, on one workstation
AnyLanguage and framework, including legacy stacks
OvernightFull sweep, or scoped to a diff in minutes
RepeatableSame run in CI, with results compared to the last one
REQUEST ACCESS
Run it against
your own codebase
Access is granted to enterprise security and platform teams after a short scoping call. We install with your engineers, run the first sweep together, and walk the findings line by line.
- ✓Installed on your hardware, inside your network
- ✓First findings review within the first week
- ✓Your security team keeps every artifact from the run
Questions first? Write to contact@brainerxlabs.com.
FAQ
Questions security teams ask
Does any code or finding leave the machine?+
No. The harness reads a local checkout, keeps its working state on local disk, and writes results to a path you choose. It runs with the network off. The only data that moves is the export you decide to share.
Which model does it run?+
The harness is model agnostic. It can run against local weights on your own hardware, or against an endpoint you host inside your environment. We help you pick based on the accuracy and throughput you need, and the evidence from your own codebase.
How is this different from a SAST scanner?+
A scanner matches patterns and leaves triage to you. The harness uses static analysis only to decide where to look, then an agent investigates each candidate, and a second agent tries to disprove it. What reaches your queue has already survived review, which is why the list is short.
What about false positives?+
The revalidation stage exists for exactly this. Candidates that cannot be shown as reachable, or that are already handled by a framework or sanitizer, are dropped before enrichment. Every surviving finding ships with the data flow that justifies it, so your engineers can check the reasoning rather than trust it.
Can it run in CI?+
Yes. The same binary runs on a build agent, either as a full sweep on a schedule or scoped to the diff on a pull request. Results can be compared against the previous run so only new findings interrupt anyone.
Who reviews the findings?+
Your team does. The harness produces evidence and a suggested fix, and a human decides what to do with it. Nothing is patched automatically, and every run leaves an audit log of what was examined and why.