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

What agentic penetration testing actually returns

You authorise a scope. B-52 maps the target, works out the test cases that target needs, tries them, and reports only what it could actually exploit. Every finding arrives with the request, the response and the steps to run it again.

Request a Scoping Call Walk through a completed run
One run, end to end

  1. Discovery

    What is there, inside the scope you signed off

  2. Planning

    A mindmap, and the test cases this application needs

  3. Scanning

    Candidates, none of which is a finding yet

  4. Exploitation

    Proved, or dropped. Nothing survives on a guess

  5. Reporting

    The report, and the findings in your dashboard

  6. QA

    A gate that can send the finished report back

QA can send it back to reporting

The sixth phase runs on the finished report. When it sends one back, reporting runs again.

The question buyers arrive with

Is this a scanner with better marketing?

It is a fair question, and for a good deal of what gets sold as agentic testing it is the right one. A scanner sends known payloads and matches known signatures. If that is what runs underneath, calling it an agent changes the marketing and not the output.

The answer is not an adjective. It is the class of defect that comes back. Below is a finding from a run against an Indian co-operative bank’s card portal. Every request in it returns 200. Nothing is malformed, nothing is missing, and no response on its own is anomalous — the defect exists only in the difference between two of them.

Co-operative bank · India

A card-verification endpoint answered differently for issued and unissued numbers

Severity
High
CVSS
7.5
CWE
CWE-204
OWASP
A01:2025

Request

POST /verifyCardNumber.action HTTP/1.1
Host: cards.northfield-bank.example
Content-Type: application/x-www-form-urlencoded

cardNo=4019551234567890

Response

HTTP/1.1 200 OK
Content-Type: application/json

{"code":0}

Code 0 means the number is issued and is an add-on card. An unissued number returns 200 with code 1. Neither response is an error, and no CAPTCHA or rate limit stands in front of either.

Reproduction

  1. Post a card number to the verification endpoint. No authentication is required.
  2. Record the code in the response body. It distinguishes issued, unissued and inactive numbers.
  3. Repeat across a number range. The endpoint answers every time, at any rate.
  4. Feed the issued numbers into the forgotten-password flow, which is where this stops being an information leak.

At the QA gate

Raised from medium to high. An earlier phase rated it on what the endpoint discloses; the QA gate rated it on what the disclosure enables, because the same portal’s password-reset flow accepts the numbers it yields.

There is no payload here and no signature to match. Finding it means understanding what the endpoint is for, noticing that two well-formed answers differ, and knowing which other flow in the same portal accepts what the difference yields. That is the work, and it is the reason the practices below matter more than the word in front of them.

What runs when you start a scan

Where the testing knowledge came from

Security Brigade has been CERT-In empanelled since 2008, and every engagement in that time was worked inside Lemon, the firm’s own assessment platform. The test cases, the vulnerabilities and the threat models stayed with the firm instead of leaving with the auditor who wrote them. The harness was then written to run the practices a senior Security Brigade auditor works through, rather than to run a check list.

The harness

It runs the four practices a Security Brigade auditor runs

It maps the target first
Entry points, roles, and what each role can reach from where it starts. A test set written against the application in front of it, not against a list.
It reads the client-side code
Routes and parameters the interface never links to. An assessment that only follows links stops at the edge of the menu.
It takes flows out of order
Multi-step flows run in the wrong sequence and by the wrong role. That is where business-logic defects live, and it is the work a signature cannot do.
It proves what it reports
A candidate is either exploited or dropped. What reaches you carries the request, the response and the steps to run it again.

What that produced

Measured against our own assessors, on the same engagements

B-52 ran in parallel with Security Brigade’s expert assessment team, on the same targets, and both sets of findings were counted together. The denominator is the combined set: everything either party found, each item counted once.

90–95%

of the combined findings set, reached by B-52

The combined findings set
  • Reached by B-52
  • The range the benchmark returned, drawn rather than rounded
  • Reached by the assessment team and not by the platform

Part of what B-52 reached was absent from the assessment team’s own output on those engagements, which is why the combined set is larger than either party produced alone. That split is stated rather than drawn: it was never measured as a proportion.

Two jobs, one word

“Agentic” points in two directions

This page is about the first meaning: the platform is the agent, and it carries out the assessment. The second meaning is the opposite — your application is the agent, and what needs testing is its prompt handling, its model endpoint, and the tool calls it can be talked into making. B-52 does both, and they are different pieces of work.

If you came here for the second one, AI penetration testing is the page that covers it.

Read next

The parts of this with their own page