Open Source · MCP · SAST · DAST

IntelligenceDesigned To Evolve

Build applications that reason, adapt and collaborate using a modular AI platform designed for production.

An autonomous security engineer for the software you just built.

Get Started How it works

14 Routes mapped*

5 Tool families*

4 Verification checks*

7 Stage security loop*

Assessment threadRepository → Environment → Assessment → Evidence

*Hero signals are illustrative product values, not verified operating measurements. Everywhere else on this site, evidence is shown as evidence — with its source.

01 The gap

Security is still the last thing that happens to software.

Modern teams ship faster than any security review cycle. Findings arrive after the release, stripped of context, and someone has to reconstruct a decision that was made weeks ago. BreachLabs moves the assessment into the loop that produced the code.

Before

Scanners produce lists.

A tool reports a pattern. There is no source line, no runtime observation, and no attempt to prove the issue is reachable. Triage becomes guesswork.

Instead

Investigation produces evidence.

BreachLabs correlates source context, runtime behaviour, and related signals, then states what it can and cannot prove.

The operating principle

Deterministic tools do the measuring. The agent does the reasoning. Evidence connects the two, and nothing is called verified until a targeted check confirms it.

Detectiondeterministic tooling

Interpretationagent reasoning

Confirmationtargeted verification

Resolutionretest against the patch

02 The security loop

Build. Discover. Test. Investigate. Verify. Fix. Retest.

Seven stages, each with an explicit output. The loop is the product: an assessment is not a report at the end, it is a sequence of measured steps.

01
BUILD
An application is created, modified, or handed over for assessment.
02
DISCOVER
Routes, forms, API endpoints, authentication flows, and entry points are enumerated.
03
TEST
Static analysis, dependency review, secret detection, and dynamic checks run as deterministic tools.
04
INVESTIGATE
The agent reads the surrounding source, correlates runtime observations, and explains what each signal means.
05
VERIFY
A targeted check attempts reproduction. Findings stay unconfirmed unless the check succeeds.
06
FIX
Remediation is generated for the specific code path, with the reason it resolves the issue.
07
RETEST
The same assessment runs again against the changed application to confirm resolution.

03 Reconnaissance

You cannot assess an attack surface you have not mapped.

Before a single check runs, BreachLabs enumerates what the application actually exposes — then treats that map as the scope for every measurement that follows.

Discovered surface

recon — breachlabs-demo

01routes → 14 discovered
02search · GET /search?q= · unvalidated input
03comments · POST /comments · reflected output
04profile · GET /api/profile?id= · object reference
05auth · 1 session flow · cookie scope observed
06assets · 37 static files

Illustrative recon output. Real assessments record the same fields from the running application.

Surface counters

Routes discovered14

Forms3

API endpoints9

Auth flows1

Static assets37

Scope

Every subsequent test is scoped to the discovered surface. Nothing is probed outside the authorised target.

04 Deterministic tooling

AI does not replace the tools. It makes the tools useful together.

Each tool family answers one question precisely. The agent's job is to connect the answers — not to invent them.

SAST

Source patterns

Dependencies

Known-vulnerable versions

Secrets

Committed credentials

DAST

Runtime behaviour

Browser

Client-side state

Result

Signals

Raw, deterministic, reproducible. A signal is a fact about the code or the running application — not yet a claim about risk.

Correlation

Evidence graph

Signals are linked to the source location, the request that reached it, and any related observations.

Output

Findings

A finding carries severity, confidence, the affected surface, and the evidence behind it.

05 AI investigation

A signal becomes evidence when someone can explain it.

The agent opens the source around the reported location, traces how the value reaches it, and records the reasoning next to the observation it came from.

Step 1 — Source context

Read the file around the reported line and identify how the untrusted value is constructed and used.

Step 2 — Reachability

Correlate the source location with the route that reached it during the running assessment.

Step 3 — Confidence

State confidence honestly: source-confirmed evidence does not automatically become a verified exploit.

Reasoning trace

investigate — BL-DEMO-001

01signal: tainted input reaches query construction
02open search.py:38 ±15
03query = "… WHERE name = '" + term + "'"
04term ← request.args.get("q") — unvalidated
05route GET /search?q= reached during assessment
06related signal: missing parameterisation at 3 sites
07confidence → SOURCE + ROUTE CONFIRMED
08next → targeted verification required

Investigation raises confidence and adds context. It does not by itself promote a finding to VERIFIED.

06 Verification

Evidence before certainty.

Verification is a targeted attempt to reproduce the specific claim. If the attempt fails, the finding is reported as unconfirmed rather than quietly kept.

DETECTED

A tool reported something.

Deterministic output exists, but reachability and impact are not yet established.

INVESTIGATING

The agent is correlating.

Source context and runtime observations are being linked to determine whether the claim holds.

VERIFIED UNCONFIRMED

The attempt resolved it either way.

A successful reproduction is verified. A failed one is unconfirmed — and said out loud.

No silent certainty. Automated assessment can miss issues and can misread context. A clean report is not proof that an application is secure.

07 Evidence-backed finding

One finding, shown in full.

This is the unit of output. Not a count, not a score — a claim with its source, its reachability, its confidence, and its remediation.

BL-0142 Verified Report

VERIFIED

Sensitive data exposure on profile endpoint

The profile endpoint returns fields the requesting session is not authorised to read.

SeverityHIGH

ConfidenceVERIFIED

Affected SurfaceGET /api/profile

app/api/profile.py:64 source

GET /api/profile?id=2 → 200 with owner fields runtime

session scope: user_id not enforced on lookup auth

related: 2 endpoints share the lookup helper related

Reproduction succeeded using a second authenticated session. The response contained fields belonging to a different account.

Retested after fix · resolved BreachLabs Provenance Chain ✓

Why this is verified

A probe reconstructed the request from a second session and compared the response to the authorised view. The difference was reproducible, so the finding moved from investigating to verified.

Remediation

Enforce session identity on lookup and drop fields the caller is not entitled to, rather than filtering them in the response layer.

1- row = db.get_profile(request.args["id"])
2+ row = db.get_profile(session.user_id)
3+ return serialise(row, allow=SESSION_FIELDS)

08 Fix and retest

The loop only closes if someone proves it closed.

After a change, the assessment runs again and the finding is re-evaluated against the new behaviour. Resolution is a measurement, not an assertion.

Stage 1

Remediation

The fix is described for the specific code path, with the reason it removes the condition rather than the symptom.

Stage 2

Patch applied

The change lands in the application, or in the tracked change set for the assessed branch.

Stage 3

Retest

The verification probe repeats. Passing the retest is the evidence that the finding is resolved.

Retest result

retest — BL-0142

01before · session B received owner fields → exposed
02after  · session B received own record only
03probe result → no cross-account data returned
04RETEST: PASS — finding resolved

VERIFIED RESOLVED

Current MVP scope: BreachLabs explains and prepares remediation and re-runs verification against the changed application. Fully automated patching of arbitrary codebases is a roadmap capability, not a claim made today.

09 The report

The output is a document you can act on.

Findings are ordered by severity, each with its evidence and remediation. Coverage and limitations are stated alongside the results, so the report can be read honestly.

Report anatomy

Scopetarget · commit · environment

Coveragewhat was tested

Findingsseverity · confidence · evidence

Remediationper finding

Retestbefore · after · result

Limitationsstated explicitly

Preview

report.md — breachlabs-demo

01# Security assessment — breachlabs-demo
02## Summary
033 findings · 2 verified · 1 investigating
04## BL-DEMO-001 — SQL injection in search parameter
05severity high · confidence verified · GET /search?q=
06### Evidence · source · runtime · related
07### Remediation · parameterise the query
08## Limitations · stated explicitly

Give every application its own security engineer.

Build faster. Validate earlier. Ship with evidence you can point at.

Install BreachLabs Explore the architecture