Phases

A run works through seven phases in a fixed order: pre-engagement, intelligence, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting. The order is a list in the agent, and advancing means moving one place along it. There is no branch that skips a phase and none that goes back.

The agent decides when a phase is over. It calls a phase_complete tool with a one-line summary, and in the six model-driven phases that call is what advances the run. Two places advance it without the agent: pre-engagement, which needs no model call, and the threat-modeling step cap. Both are described below. Every artifact and every finding records the phase it was produced in.

How a phase boundary works¶

At each boundary the agent's conversation is cleared. What crosses into the next phase is the list of one-line phase summaries and the findings recorded so far, both of which are pasted into the next phase's opening message. Individual commands, their output and the agent's reasoning do not cross.

The system prompt is rebuilt for every step and carries the targets and the scope on each one.

1. Pre-engagement¶

Renders the rules-of-engagement document from the engagement's targets, scope, rules, framework and credentials, and checks the in-scope and out-of-scope lists for overlap. No model is called. The phase advances on the first step of the run, which is why the console pipeline shows six stages rather than seven — see Running an engagement.

If the two scope lists overlap, rendering raises and the run does not leave this phase. When a run fails describes what the operator sees.

2. Intelligence¶

Passive information gathering. The prompt tells the agent not to send packets to in-scope targets in this phase and lists the tools it may use: whois, dig, host, theHarvester, sublist3r, certificate-transparency queries over curl and public DNS resolvers. It names nmap, nikto, gobuster and sqlmap as tools to leave for later. The goals are OSINT on the targets, subdomain and related-domain enumeration, and the versions of public-facing software visible from a single passive request.

The prompt asks for findings from this phase to be tagged network_scanning, for purely informational ones to be filed at severity info, and for the phase to end once the public attack surface is clear.

The prompt is an instruction, not a control. Nothing in the scope guard distinguishes a passive command from an active one; it checks the command's target against the scope lists and the tool name against the actions you denied.

3. Threat modeling¶

The prompt tells the agent not to run scanning tools in this phase. It turns the intelligence into a structured model: an asset inventory, a list of threat actors, a ranked list of attack paths annotated with ATT&CK tactic ids, and a list of concrete hypotheses to test next. It records that model with a record_threat_model call and then completes the phase.

This phase has a step cap, threat_model_max_steps, which defaults to 10. The cap is enforced by the run loop rather than by the model: when the count is reached the loop appends the summary threat_modeling: step cap reached, advancing, clears the conversation and advances. No other phase has a cap of its own.

4. Vulnerability analysis¶

Active probing. The prompt directs nmap version scans against in-scope IPs, CVE matching against the versions found, and, for HTTP services, the OWASP WSTG checklist by category — information gathering, configuration, identity, authentication, authorization, session management, input validation, error handling and cryptography. It also asks for configuration checks: default credentials, exposed admin panels, verbose errors.

Findings recorded here are expected to carry ATT&CK technique ids, a NIST test category, WSTG ids for web and API targets, and structured evidence. They are filed with status unverified — observed, not yet proven exploitable.

5. Exploitation¶

The agent attempts the unverified findings. A working exploit becomes an update_finding call setting status to verified with the exploit evidence attached; one that does not work becomes not_exploitable or false_positive. The prompt asks it to update existing findings rather than file duplicates, and to raise CVSS where the exploit demonstrates worse impact than the original finding suggested. New findings discovered during exploitation are allowed and need the same tags as any other.

6. Post-exploitation¶

For findings that produced access: privilege escalation, what other in-scope hosts are reachable, what data can be read, and whether persistence would be possible. The prompt asks the agent to document a persistence route rather than plant one. Each escalation step is a new finding chained back to the initial-access finding through related_finding_ids, which is what produces the attack chain in the report.

7. Reporting¶

The prompt tells the agent to run no active tools here. It re-reads its own findings against the NIST SP 800-115 deliverable checklist: ATT&CK ids present and valid, NIST test category set, at least one evidence entry with non-empty content, CVSS score and vector for severity medium and above, WSTG ids on HTTP and API findings, and a status that matches what was demonstrated. Gaps are fixed with update_finding; the prompt tells it to append evidence rather than edit what is already recorded.

The final phase_complete summary carries counts by severity, the top three critical findings, an overall risk posture and which threat-model attack paths were proven feasible.

After this phase the run is marked complete, the agent emits its results payload, and the container exits. What the server does with that payload is covered in Lifecycle.