Skip to main content
B‑52
Run a scan
B-52 · Agentic Penetration Testing Platform

The penetration testing platform your team logs into

In the fully autonomous model, signing off the scope is the last action you take. Everything after it arrives here: what was found, how it was reached, how far the run has got, and whether the fix holds.

Four screens, one login, and each of them is filled by the run rather than assembled by hand afterwards.

The four screens

  1. 01 Findings What was found, how severe it is, and what proved it
  2. 02 Attack chain Which finding made the next one reachable
  3. 03 Test runs Where a run has reached, and how much of its test set has been worked
  4. 04 Remediation Each finding from open through a retest to a verified fix

About the imagery

Every screen shown here is a demo tenant

The captures on this page exist so the screens can be shown. The findings, hosts, applications and identities in them were invented for that purpose.

How to read the captures on this page
  • The tenant is a demonstration tenant. It holds no customer data and no customer target.
  • Every finding, host, application and identity visible in a capture is synthetic.
  • No figure that appears inside an image is a measurement — not a count, not a percentage, not a duration.
  • Figures that are measurements are written into the copy on this site, each with the source it came from.

Screen 01

Findings, at their severity, with what proved them

Every finding carries a reproducible exploit artefact, in all three delivery models. The dashboard is where that artefact sits: opening a finding gets you the exchange that produced it and the steps that run it again, in the same place as the severity and the class it came from.

In the fully autonomous model a finding has also passed an independent automated cross-check before it is reported. The exploit is what makes it checkable by your own engineers; the cross-check is a second gate above that.

Screenshot slot · demo tenant

The findings list: severity, coverage class, and the evidence attached to each finding.

Synthetic data. Nothing visible in this capture is a measurement.

The evidence is not the same object in every class

An Active Directory finding and a mobile finding do not carry the same fields, and a dashboard that pretended otherwise would be showing you empty ones. What stays constant is the rule — the exchange that proved it, and the steps that reproduce it. What that exchange consists of is decided by the class.

What proof consists of, by coverage class
Coverage classWhat the exchange isWhat reproducing it takes
Web and API The request that triggered it and the response that came back, with the parameter, header or body field that carried the payload. The same request against the same endpoint, in the same session state and with the same role.
Mobile applications The location in the decompiled APK or IPA, the runtime protection that had to be handled to reach it — certificate pinning, a RASP control — and the traffic that flowed once it had been. The build the finding was raised against, and the steps in the order they were taken. A finding in a hardened release build is not reproducible against a debug build.
Thick client and desktop What the client wrote to disk or held in memory, or the client-server exchange itself, which on a desktop application is often not HTTP at all. The build, the client state the exchange was taken from, and the protocol trace — there is no URL to paste into a browser.
External and internal network The host, the service and the version that answered, and the exchange that showed the weakness was reachable from where the test stood. The vantage point as well as the payload. The same request sent from a different position on the network is a different test with a different answer.
Active Directory and identity The principal the test held, the object it reached, and the relationship that allowed it — a delegation, a nested group, an access control entry. A path rather than a single call, so the finding carries the steps in order and what each one left behind. Read it alongside the chain the steps belong to.
LLM applications The prompt sequence that was sent and what the application returned, including any tool it called or data it reached on the way. The same sequence in the same order against the same application state, since the conversation preceding a request is part of the request.

What proof consists of, by coverage class

Web and API

What the exchange is
The request that triggered it and the response that came back, with the parameter, header or body field that carried the payload.
What reproducing it takes
The same request against the same endpoint, in the same session state and with the same role.

Mobile applications

What the exchange is
The location in the decompiled APK or IPA, the runtime protection that had to be handled to reach it — certificate pinning, a RASP control — and the traffic that flowed once it had been.
What reproducing it takes
The build the finding was raised against, and the steps in the order they were taken. A finding in a hardened release build is not reproducible against a debug build.

Thick client and desktop

What the exchange is
What the client wrote to disk or held in memory, or the client-server exchange itself, which on a desktop application is often not HTTP at all.
What reproducing it takes
The build, the client state the exchange was taken from, and the protocol trace — there is no URL to paste into a browser.

External and internal network

What the exchange is
The host, the service and the version that answered, and the exchange that showed the weakness was reachable from where the test stood.
What reproducing it takes
The vantage point as well as the payload. The same request sent from a different position on the network is a different test with a different answer.

Active Directory and identity

What the exchange is
The principal the test held, the object it reached, and the relationship that allowed it — a delegation, a nested group, an access control entry.
What reproducing it takes
A path rather than a single call, so the finding carries the steps in order and what each one left behind. Read it alongside the chain the steps belong to.

LLM applications

What the exchange is
The prompt sequence that was sent and what the application returned, including any tool it called or data it reached on the way.
What reproducing it takes
The same sequence in the same order against the same application state, since the conversation preceding a request is part of the request.

Screen 02

The chain, in the order it was walked

A severity sort answers which finding is worst on its own. It does not answer how someone got from the outside to the thing you care about, and that route is usually made of items that each looked survivable.

The chain view holds the findings in sequence, each still carrying its own evidence, so the position a finding occupied is readable at the same time as what it is.

Attack chain

What a chain holds that a findings list cannot

What a step holds
The finding itself, at its own severity, with the exchange that proved it and the steps that reproduce it attached to that step rather than to the chain as a whole.
What the order shows
Which finding made the next one reachable. An item that would sort near the bottom of a severity list is read in the position it actually occupied, which is usually the reason it matters.
Where an approval sits
Persistence, implants and lateral movement past the entry host need your written approval before B-52 takes them. A chain that reaches beyond that host reached there under an approval you had already given.

Screenshot slot · demo tenant

One chain, step by step, with each step keeping the evidence that proved it.

Synthetic data. The chain in this capture was constructed for the demonstration tenant.

Screen 03

Where the run has reached, and what it has covered

Three questions get asked of a test in progress, usually by somebody who has been asked them by somebody else. The screen answers them in that order.

Where has the run reached?
Which of the six phases it is in — discovery, planning, scanning, exploitation, reporting, QA. The last of those can send the finished report back to the phase that produced it, so a run is not finished at reporting.
How much of the scope has been worked?
Planning generates the test cases this particular application needs rather than applying a fixed list to whatever is in front of it. Coverage is progress against that generated set, which is why it is a property of your target and not of our checklist.
Is it waiting on me?
Three actions need your written approval before B-52 takes them: destructive or state-changing actions in production, persistence and lateral movement past the entry host, and anything touching live credentials or real customer data. A run that reaches one of them waits there.

Screenshot slot · demo tenant

Run status: the phase each run is in, and its progress against the test cases planning generated for that target.

Synthetic data. The runs, targets and progress shown are invented for the demonstration tenant and describe no assessment.

Screen 04

Open, fixed, retested, closed on the retest

A report hands you a list. What happens to that list over the following weeks is the part that decides whether the assessment changed anything, and it is the part that normally leaves the platform and lives in a spreadsheet.

  1. Open

    The finding arrives with what it takes to fix it

    Its severity, the exchange that proved it, and the steps that reproduce it. The engineer who picks it up has everything they need to run it again.

  2. With your team

    The fix is yours to make and the finding stays in view while you make it

    Tracking continues while the work is with you, so a finding does not fall out of sight in the gap between a report being delivered and the fix being ready to check.

  3. Retest

    The steps that produced it are run again

    A retest re-runs the reproduction against the changed system. The question it answers is narrow and answerable: does the same sequence still work?

  4. Verified fix

    It closes when the retest cannot reproduce it

    That is the only thing that closes it. A finding marked fixed and never re-tested is an open finding with a tidier label on it.

Screenshot slot · demo tenant

Remediation tracking: each finding from open, through the retest, to a verified fix.

Synthetic data. The findings and their states were invented for the demonstration tenant.

The retest is the same work as the original test, pointed at one thing. That is why it can close a finding: the sequence either still works or it does not.

The screens are filled by the run

Nothing on them is transcribed from a document afterwards. What the platform proved is what you read, in the same form your engineers will use to check it.

How a run produces all of this Evidence in the mobile class