The last human action in this model is an authorisation. After it, B-52 discovers, plans, tests, exploits, reports and puts its own report through a QA gate that can send it back.
Security teams take this model to cover the estate in the months between deep engagements. They already run manual penetration tests, and the gap between them is what they are buying.
After the authorisation
The sequence below is the whole engagement. Read step four carefully: it is the gate this model puts where a person would otherwise be reading.
The last human action
What is in scope, what is out, and which classes are being run. This is where a person exercises judgement in this model, and it is worth spending the time on for that reason.
Then the run
Discovery, planning, scanning, exploitation, reporting, QA. Scanning produces candidates; exploitation either proves one or drops it, so nothing arrives in the report on a scanner’s say-so.
What survives
The request, the response and the steps to reproduce it. A finding your engineers cannot reproduce is a ticket rather than a result, so a candidate that cannot be proved does not become one.
The extra gate
This model adds a separate automated check that every finding passes before it is reported. The exploit is what makes a finding verifiable; the cross-check sits on top of it.
What arrives
Severity, evidence, the attack chain in the order it was built, and remediation tracked through to a retest. Observed median from sign-off to delivery is one to three business days.
Every finding on every B-52 engagement arrives with a working exploit attached — the request that triggered it, what came back, and how to run it again. That is what makes a finding checkable by your own engineers, and it does not depend on the delivery model.
The cross-check is what this model adds because there is no auditor reading the output before you do. It runs after the exploit has already been produced, against the finding the exploit proved.
Deliberately excluded
Where the run stops
Autonomy in this model means nobody at Security Brigade acts after sign-off. Three classes of action still stop and wait on you, in this model exactly as in the other two, and the run picks up again from where it paused.
Once persistence has been approved for a scope, B-52 establishes it. There is no handover to a human operator for that step, because the step is in the platform as well.
Everything above those three gates runs without asking. What sits at them waits until you have said yes in writing.
Before you scope one
| What buyers ask about this model | The answer |
|---|---|
| How long does it take? | The observed median from scope sign-off to report delivery is one to three business days. |
| Who confirms a finding is real? | The platform does. Every finding carries a reproducible exploit artefact, and in this model each one also passes an independent automated cross-check before it is reported. |
| Is anything left out of scope compared with the other models? | No. All eleven coverage classes run here exactly as they run elsewhere. The delivery model changes where the human sits and nothing about what is looked at. |
| Can Security Brigade sign this for a regulated filing? | No — there is no empanelled auditor in the engagement, and that involvement is what produces the signature. Take the expert-verified or human-led model where a filing is the destination. |
| Does anything still stop the run? | Three actions do, and each of them waits on your written approval. They are set out in the band above. |
Common questions about the fully autonomous model, answered
How long does it take?
Who confirms a finding is real?
Is anything left out of scope compared with the other models?
Can Security Brigade sign this for a regulated filing?
Does anything still stop the run?
Coverage is the same in all three. Move only if the destination of the report requires somebody at Security Brigade to have been in the engagement.