What autonomous persistence means under authorisation
A red team holds a foothold so that access can be shown to be durable, not momentary. When the thing holding it is a platform and not a person, one question decides whether that is acceptable, and it is not a technical one: under whose authority, and bounded by what. B-52 answers it with a document signed before the run.
Yash K · · Autonomy and its limits · about 10 min
The word itself
Persistence is a foothold held across time
It is the part of an offensive engagement that proves access was durable, and it is the part a customer has the most right to ask questions about.
A foothold that lasts as long as one session proves that a door opened. A foothold that survives a reboot, a session expiry or a credential rotation proves something harder and more useful: that somebody who got in on a Tuesday would still be in on the Friday, and that nothing around that host closed the gap in between. Red teamers call the second one persistence, and it is worked deliberately and not stumbled into: an implant, a scheduled task, a stored credential, a token that outlives the login that issued it. It is also the single action in an offensive engagement that most obviously belongs to the customer to authorise, because unlike a scan or an exploit proof it leaves something behind and keeps it there. On a B-52 engagement it therefore sits behind a written approval, not inside the scope, and the rest of this article is about why those are two different documents.
The same moment, twice
Where an operator would take over, and what happens instead
Reaching a foothold is one problem. Deciding what to leave behind, which host to move to next and when a chain has proved enough is a different one, and it is the half a conventional engagement hands to an operator.
A conventional engagement
- The foothold
- A tester reaches a shell, a session or a working set of credentials on the first host inside the perimeter.
- The decision
- A human operator takes the keyboard. What to install, how long to hold it and how far to move are judged in the moment, against that operator’s reading of the situation and of the scope in front of them.
- The record
- The judgement is reconstructed afterwards from notes and from the report. The authority for it was the engagement letter, read in the moment by the person acting on it.
A fully autonomous B-52 run
- The foothold
- The same. Discovery, testing and chaining run against the authorised scope without checking in, and a foothold is reached in the course of that work.
- The decision
- There is no operator to hand it to. B-52 establishes persistence itself, inside the boundary a written approval has already named. Where no such approval exists, it stops there, proves what it reached and reports.
- The record
- The authority is a document signed before the run, naming what was permitted and carrying the date it was given. Nothing is reconstructed afterwards, because nothing was judged at run time.
Settled in advance
What the authorisation fixes before anything runs
Each of these is a judgement on a conventional engagement and a sentence on this one. None of them is decided by the platform while the run is going.
| The question | What is written down, and when |
|---|---|
| Under whose authority | A named person on your side signs the scope before the engagement begins. In the fully autonomous model there is no operator behind that signature to widen it later, so it is not a formality that precedes the real permissions; it is the permission. |
| Bounded by what | The hosts or the segment inside which persistence and movement past the entry host are permitted, named in their own written approval instead of inferred from the scope. Approving movement inside a named segment authorises it inside that segment; reaching past it is a new decision. |
| The boundary is a place, written down in advance, not a rule the platform applies to a situation it meets. | |
| For how long | For the engagement the approval was given for. It is not a standing permission, it does not travel to the next piece of work, and a second engagement asks again. |
| What it does not carry with it | Live credentials and real customer data sit behind their own gate. So do destructive and state-changing actions against a production system. Holding a foothold releases neither of them, and neither is implied by an approval to hold one. |
Under whose authority
- What is written down, and when
- A named person on your side signs the scope before the engagement begins. In the fully autonomous model there is no operator behind that signature to widen it later, so it is not a formality that precedes the real permissions; it is the permission.
Bounded by what
- What is written down, and when
- The hosts or the segment inside which persistence and movement past the entry host are permitted, named in their own written approval instead of inferred from the scope. Approving movement inside a named segment authorises it inside that segment; reaching past it is a new decision.
The boundary is a place, written down in advance, not a rule the platform applies to a situation it meets.
For how long
- What is written down, and when
- For the engagement the approval was given for. It is not a standing permission, it does not travel to the next piece of work, and a second engagement asks again.
What it does not carry with it
- What is written down, and when
- Live credentials and real customer data sit behind their own gate. So do destructive and state-changing actions against a production system. Holding a foothold releases neither of them, and neither is implied by an approval to hold one.
The order of authority
Four steps, and the human ones are both at the front
Order is most of the argument here. Each step is spent before the next becomes possible, and the steps a person takes come before the run and not during it.
-
Before the run
The scope is authorised and signed
The targets, and the boundary drawn around them. A named person on your side signs it, and in the fully autonomous model no operator follows it into the run.
-
Before the run
The movement gate is released, or it is not
Persistence, implants and movement past the entry host sit behind their own written approval, naming the hosts or the segment it covers and carrying the date it was given. An internal network engagement settles its movement boundary at scoping, precisely so that it is not being decided while a run is going.
-
During the run
B-52 establishes the foothold, and holds it
Inside that boundary, as part of the same run that found the way in. No operator is handed the keyboard for this part, which is exactly what obliges the written boundary to do the work a person would otherwise have done in the moment.
-
After the run
The records outlast the access
The scope authorisation, and the movement approval where one was given: what was asked for, what was permitted, and when. A gate that was raised and never released is worth reading too. It says the run reached a point where it would have gone further and did not.
The whole argument
Agreed before it started, not judged while it ran
One condition decides whether an autonomous system holding access is acceptable at all, and every document above exists to meet it.
An autonomous system holding access inside somebody’s estate is acceptable on one condition: that its limits were settled in advance by the person who owns that estate. So they are settled in advance. The scope authorisation names the targets and the boundary drawn around them. A separate written approval names the hosts or the segment inside which persistence and movement are permitted, and carries the date it was given. Anything past that boundary is a fresh decision, and never an inference the platform is entitled to make on its own. A conventional engagement can afford to leave some of this to be worked out during the run, because there is an operator on the far end who will work it out, in the moment, against their own reading of the scope in front of them. Autonomy removes that reading, and what replaces it has to exist on paper, and has to exist first. That is the trade this model makes, and it is why the scope document carries more weight here than in either of the other two.
Inside and outside
What an approval for persistence covers, and where it stops
An approval is given for a boundary, not for a single action inside it. That cuts both ways, and both directions are set out here.
| State | What it means | What follows |
|---|---|---|
| Inside the named boundary | B-52 establishes and holds persistence itself on the hosts or the segment the approval names, for the engagement the approval was given for. | Proceeds without asking again. |
| A further host inside that boundary | Movement to another host the approval already covers. B-52 does not return for a second signature on each host it reaches inside a boundary you have already drawn. | Proceeds without asking again. |
| Past the named boundary | A host, a segment or an environment the approval does not name, whether or not it looks equivalent to one that is named. Resemblance is not authorisation. | Stops, and asks in writing. |
| Live credentials or real customer data | Using a real account or reading a real person’s records once a path to them has been proved. It is a separate gate with a separate approval, and holding a foothold does not release it. | Stops, and asks in writing. |
| No approval was given at all Terminal | The run does what the scope authorised, reaches the foothold, proves it with the request, the response and the steps that reproduce it, and reports. A gate that was never released is a gate that was never released. | No persistence is established. |
- Authorised in advance, in writing, for a named boundary
- Stops and waits for a further written approval
- Nothing was released, and the run reports what it reached
- TerminalNo state follows this one
Where it is written down
The four pages that carry the mechanism in full
This article covers one gate. These four cover the boundary it belongs to, the delivery model it matters most in, the approvals themselves, and the clauses a scope document has to name.
The autonomy boundary
The boundary line by line: the three delivery models and where the human sits in each, the three actions held for your written approval, and what stands behind a finding in every one of them.
Delivery modelFully autonomous
It is the model this article is written about. Scope is signed off, and nothing more is asked until the report unless a gate like this one comes up. It is chosen at scoping and it can be changed between engagements.
TrustApprovals and the record they leave
What each of the three gates covers, what approving one does and does not authorise, whether a gate can be released mid-run, and what a run does when nobody answers.
ResourceScope and authorisation clauses
The clauses a scope and authorisation has to name, set out on the page and broken down per coverage class. Written for somebody already inside a procurement process.
The turnaround figure
How long a run with nobody in it takes
One turnaround figure is published for B-52. It belongs to the model this article is written about, and this is the measurement behind it.
Turnaround on the fully autonomous model As of 2026-09-15
- A median of one to three business days from scope sign-off to report delivery, observed across engagements run on the fully autonomous model.
- It is a median taken from real runs and not a service level, so individual engagements land on either side of it.
- Where the movement gate is released at scoping instead of mid-run, the run is not waiting on a signature while it is going.
Deliberately excluded
- The expert-verified and human-led models. No turnaround figure exists for either of them, so none is stated.
- Physical, hardware and wireless testing, which are out of scope for B-52 in every coverage class.