The Case for Human-in-the-Loop Exploitation

There is a real temptation, once recon and detection are automated, to keep going and automate confirmation too. Resist it. This is exactly the point in an engagement where slowing down protects everyone involved.

Detection and exploitation are not the same risk

Detection reads. It sends requests designed to reveal information without meaningfully changing anything on the target. Exploitation, even in its most careful, "confirmation only" form, sends a payload specifically designed to trigger a real effect. The blast radius of a mistake is categorically different between the two.

What a good approval gate actually shows

An approval step is only as useful as what it puts in front of the person approving it. A vague "confirm this SQL injection finding?" prompt is close to worthless. A useful one shows the exact request that will be sent, the exact payload, and for a tool like Metasploit, the exact module and the exact restricted payload family it is allowed to use. The person approving should be looking at the literal action about to happen, not a summary of it.

Restrict what is even offered as an option

The strongest version of this control does not just ask for approval, it narrows what can be approved in the first place. Restricting exploitation to non-destructive, single-shot actions, a boolean comparison for SQL injection, a safe command-execution payload rather than an interactive shell for a tool like Metasploit, means even an approved action carries less risk than an unrestricted one would.

Re-check at execution time, not just at proposal time

An approval can sit pending for a while. Scope can change, or an engagement's authorized window can close, in the gap between when something was proposed and when it is actually approved and executed. Re-verifying scope and timing at the moment of execution, not just when the proposal was first created, closes that window rather than assuming nothing changed.

Log the decision, not just the action

Who approved an action, and when, belongs in the audit trail just as much as what the action actually did. That pairing, a specific person's decision tied to a specific technical action, is what turns an audit log from an activity feed into something a client's security team or auditor can actually rely on. More on that in tamper-evident audit logs.