Informative Appendix (non-normative)
This appendix maps standard pentesting phases to APTS requirements, helping implementers understand which controls apply at each stage of an autonomous engagement.
Autonomous pentesting engagements commonly follow five phases, consistent with established methodologies (PTES, OWASP WSTG). APTS does not mandate this phase model; the mapping below helps implementers identify requirements relevant at each stage. See Testing Phase Mapping in Cross-Domain Integration for how events in one phase trigger requirements in other domains. Actual engagement structure varies by platform and target environment.
| Phase | Description | Typical Proportion |
|---|---|---|
| Pre-Engagement | Authorization, scope definition, credential provisioning | Before test window |
| Reconnaissance | Target discovery, enumeration, fingerprinting | Varies by engagement |
| Exploitation | Vulnerability testing, exploitation attempts, privilege escalation | Varies by engagement |
| Post-Exploitation | Lateral movement, persistence testing, data access validation | Varies by engagement |
| Reporting & Cleanup | Evidence collection, system restoration, report generation | Varies by engagement |
The pre-engagement phase is the final safety checkpoint before autonomous testing begins. All authorization, scope boundaries, safety mechanisms, and operator qualifications must be verified and locked in place before any network activity occurs. This phase determines whether the engagement can proceed safely and enables rapid incident response if issues arise later.
| Requirement Area | Key Requirements | What Must Be Done |
|---|---|---|
| Rules of Engagement | SE-001 | Ingest the RoE in machine-parseable format (JSON, YAML, XML) and validate all required fields: target list, temporal boundaries, action restrictions, asset criticality, authorization proof, and escalation contacts. System must reject testing if validation fails. |
| Scope definition | SE-002, SE-003, SE-004, SE-005 | Validate all IP ranges using CIDR notation, detecting overlaps and reserved space. Validate domain specifications and handle wildcards explicitly (exact domain only, single-level wildcard, or all subdomains). Enforce temporal boundaries with microsecond precision and account for timezone conversions and DST. Classify assets by criticality and enforce corresponding testing restrictions. |
| Deny lists | SE-009, SE-010 | Configure hard deny lists for production databases, critical infrastructure, PII/PHI datastores, financial systems, control systems, and identity providers. Make deny lists immutable at runtime and evaluate them before scope checking. Log all deny list matches. |
| Credential provisioning | SE-023 | Provision and inventory all testing credentials. Track credential lifecycle (creation, rotation, destruction). Classify discovered secrets per policy and prevent auto-use without approval. |
| Safety configuration | SC-008 | Load threshold configuration in structured, schema-validated format. Include impact level thresholds, approval chains, rate limits, payload constraints, and risk scoring parameters. Validate configuration on startup and reject invalid settings with detailed error messages. |
| Kill switch validation | SC-009, HO-008, HO-009 | Verify all kill switch mechanisms are functional and can halt testing within 5 seconds. Test independent kill switches: operator-initiated local, remote halt by authorized personnel, automatic failsafe on control plane loss. Confirm Phase 2 graceful shutdown completes within 60 seconds. Verify multi-operator handoff authority transfers. |
| Baseline capture | SC-015 | Capture comprehensive system baselines covering file checksums, user/service account inventory, database record counts, configuration snapshots, and running process lists. Store baselines for post-engagement integrity validation. |
| Operator qualification | HO-018 | Confirm all operators are qualified for the engagement role. Document operator certifications, experience, and approval for the assigned autonomy level. Verify availability throughout the engagement window. |
| Approval matrix | HO-004 | Establish and document the Authority Delegation Matrix specifying which personnel can approve which actions at which autonomy levels. Verify no delegation of authority (approvers cannot delegate). Ensure dual control for CVSS >= 9.0 actions. |
| Monitoring setup | SC-010, HO-002 | Deploy real-time monitoring dashboard with activity feed, system health visualization, scope boundaries map, approval queue with SLA tracking, confidence indicators, and incident/anomaly indicators updated every 5 seconds. Enable operator to see real-time testing activity and approve/deny queued actions. |
| Autonomy level | AL-025 | Assess and explicitly document the platform autonomy level for this engagement (L1 Assisted, L2 Supervised, L3 Semi-Autonomous, L4 Autonomous). Verify configuration matches declared level. For L1, confirm single-technique execution and human-directed target selection. For L2+, confirm approval gates are configured per autonomy level. |
| Provider verification | TP-001, TP-012 | Verify AI/ML provider status, vetting, and contractual terms. Confirm data classification and minimization controls. Document which data categories are sent to each provider. Obtain explicit client consent before transmitting classified data. Verify provider SLAs and failover procedures. |
| Audit initialization | AR-001, AR-020 | Initialize audit trail and verify logging infrastructure is operational. Confirm all logs use structured format with high-precision timestamps (millisecond or better), immutable storage, and cryptographic integrity. Verify audit logs are retained per engagement contract minimum 1 year. Test that logs cannot be modified after creation. Confirm the authoritative audit store is isolated from the agent runtime (WORM, external SIEM, or dedicated log service) and that the agent holds no credentials to reach it. |
| Containment architecture | SC-019, SC-020, MR-023, AL-028 | Verify the agent runtime is running inside its declared kernel-enforced sandbox and that the tool and action allowlist is enforced by the external gateway or policy engine (not the model system prompt). For L3 and L4 engagements, confirm the most recent operator-run containment verification (AL-028) passed within the required cadence and review the threat model (MR-023) before start. |
| Foundation model disclosure | TP-021, TP-022 | Confirm the foundation model powering the agent runtime matches the disclosed provider, family, version, release date, and operator customizations in the conformance claim. If the model has changed materially since the last engagement, confirm re-attestation under TP-022 is complete before proceeding. |
Reconnaissance involves discovery and enumeration activities with lower individual impact but high cumulative volume. Rate limiting and scope enforcement are critical because reconnaissance errors can quickly generate massive volumes of traffic or expand scope beyond authorization. DNS rebinding, cloud boundary violations, and manipulation attempts are common during this phase.
| Requirement Area | Key Requirements | What Must Be Done |
|---|---|---|
| Pre-action scope validation | SE-006 | Before every network action (TCP connect, DNS query, HTTP request, API call), validate the target is in scope. Validate resolved IPs match the target FQDN. Validate HTTP redirects before following. Make validation atomic: if validation fails, do not execute the action. Log all validation decisions with context. |
| Rate limiting | SC-004 | Enforce per-host connection limits and rate limiting configurable per impact tier. Implement cascading rate limits at subnet and engagement-wide levels: if subnet traffic approaches limits, proactively reduce per-host limits. If engagement-wide limits are reached, halt all new actions. Monitor and enforce maximum payload sizes per impact tier (default: Informational/Low = 100KB, Medium = 10MB, High = 100MB, Critical = 500MB). |
| Discovery limits | SE-014 | Enforce hard limits on discovery scope: maximum number of hosts to discover, maximum number of ports to scan per host, maximum scan duration. Alert when thresholds approach and halt when limits are reached. Document limits per engagement. |
| Dynamic scope monitoring | SE-007 | Periodically re-resolve all domain targets during the engagement (minimum every 5 minutes). Detect DNS resolution changes (new IPs, removed IPs, CNAME changes). Monitor for new subdomains registered and subdomain discovery explosion. For cloud infrastructure, validate actions remain in authorized accounts, subscriptions, and regions. Pause testing and alert operator if out-of-scope resources detected. Require explicit re-authorization before resuming. |
| DNS rebinding prevention | SE-012 | Before using a resolved IP, validate it matches the target FQDN and is within scope. Detect DNS rebinding attacks where resolution changes between queries. Reject out-of-scope IPs and alert operator. Maintain allowlist of resolved IPs for each domain. |
| Multi-tenant awareness | SE-011 | If testing multi-tenant environments (cloud, SaaS), validate tenant context in all requests. Ensure actions occur only in authorized tenants. Prevent lateral movement to unauthorized tenant data. |
| Impact classification | SC-001 | Classify every reconnaissance action by impact tier (Informational/Low/Medium/High/Critical) before execution. Score each action on CIA (Confidentiality/Integrity/Availability) dimensions. Use minimum CIA dimension score to determine escalation level. Map action to pre-classified impact levels from the action-to-impact mapping document (updated quarterly). |
| Activity logging | AR-001, AR-002 | Log all discovery actions with structured format including timestamp (millisecond precision), action type, target, status code, duration, correlation ID, and decision rationale. Log all scope validation decisions and rejections. Log all rate limit enforcement events. Store logs in append-only, tamper-evident storage. Verify logs cannot be modified after creation. |
| Manipulation resistance | MR-001, MR-003, MR-009 | Treat all target responses as potentially adversarial. Validate and sanitize responses before processing. Detect and reject instruction-like patterns in error messages, configuration files, or API responses. Reject authority claims embedded in target content. Do not modify scope or tool behavior based on target-provided content. Log all attempted manipulations and alert operator. |
| Action-distribution monitoring | SE-026 | Compare the agent's action distribution against declared or historical baselines for this engagement class. Route in-scope but out-of-distribution behavior to the staffed human review queue. Never auto-terminate on this signal alone; termination decisions remain with SC-011 and AL-026. |
The exploitation phase carries the highest risk because each action can cause irreversible harm (data loss, system outage, unauthorized privilege escalation). Approval gates, impact scoring, cumulative risk tracking, and continuous health monitoring are critical because autonomous exploitation can cascade into system-wide failures if unchecked. Every action requires pre-execution impact assessment and post-execution consequence verification.
| Requirement Area | Key Requirements | What Must Be Done |
|---|---|---|
| Approval gates | HO-001, HO-003 | Implement mandatory approval gates per autonomy level. L1: All exploitation attempts, lateral movement, data access require pre-approval. L2: High CVSS (>=7.0), sensitive data access, persistence mechanisms require elevated approval within 15-minute window. L3: Critical actions require senior approval + live operator confirmation within 30-minute window. Default-safe behavior on timeout: DENY the action unless pre-approved. Log all approval decisions with timestamp, approver identity, and rationale. |
| Irreversible action gates | HO-010 | Before executing any irreversible action (data deletion, account creation, configuration change, persistence mechanism), require explicit human approval. Mark action as irreversible and document the rollback procedure. Alert operator that action cannot be automatically undone. |
| Impact scoring | SC-001 | Score every exploitation action on CIA dimensions before execution. Use pre-classified impact mapping to determine impact level. Calculate minimum dimension score to determine escalation requirement. Verify action impact classification is accurate and baseline before execution proceeds. |
| Threshold escalation | SC-006 | Implement escalation workflow where Informational/Low actions execute automatically, Medium actions require standard approval within defined window, High actions require elevated approval within defined window, Critical actions require senior approval + live confirmation. Actions exceeding their timeout are denied by default, not auto-approved. |
| Cumulative risk tracking | SC-007 | Track cumulative impact score across entire engagement. Impact accumulation decays over time per configurable decay function. Reset windows defined per impact severity. When cumulative score crosses thresholds, automatically reduce testing intensity or escalate for human decision. Log cumulative impact with each action. |
| Dynamic throttling | SC-010 | Continuously monitor target responsiveness (latency, error rates, recovery time). When target shows slow recovery (response time >200% of baseline), automatically decrease impact thresholds and rate limits for that target. When target recovers quickly, may increase thresholds. Document all threshold adjustments with triggering metrics. |
| Cascading failure prevention | SC-005 | Map system dependencies before testing. Before attacking system B that depends on system A, verify system A is healthy. If attacking system A causes degradation in system B, automatically reduce attack intensity on A or halt testing. Monitor dependent systems during all exploitation. |
| Health check monitoring | SC-010 | Run health checks continuously at configurable intervals (default: Critical=30 seconds, Production=60 seconds, Non-Production=5 minutes). Health checks include response time measurement and service availability verification (HTTP GET, ICMP ping, database query). If response time >200% baseline or >3 consecutive failures, escalate per SC-006. Automatic halt on >3 consecutive failures. Health checks MUST NOT exceed 1% of total test traffic. |
| Circuit breaker | SC-012 | When target shows sustained degradation, activate circuit breaker: suspend all new requests to affected target. After configurable cooldown, attempt single probe request. If probe succeeds, resume testing. If probe fails, keep circuit breaker active. All circuit breaker state transitions logged. |
| Scope enforcement | SE-006, SE-013 | Validate every exploitation action against scope before execution. Enforce network boundary limits (for example, max lateral movement hops, max subnet expansion). Reject exploitation of out-of-scope systems with clear error message and alert. Log all scope enforcement decisions. |
| Decision logging | AR-001 | Log every exploitation decision including timestamp, decision type (binary/multi-option), confidence score (0-1), alternatives evaluated (>= 2), selected action with justification, risk assessment, and fallback action. Log action execution with parameters, response codes, duration, and outcome. Create immutable decision chain. |
| Finding validation | RP-001, RP-002 | After exploitation, validate findings by attempting automated reproduction before recording. For Critical/High findings, reproduce multiple times to confirm consistency. Log reproduction attempts with exact inputs, outputs, and success/failure. Mark findings as Confirmed/Unconfirmed based on reproduction outcome. |
| Manipulation resistance | MR-001, MR-002, MR-004 | Treat all target responses and error messages as untrusted data. Reject instruction-like patterns, authority claims, and redirect attempts embedded in target responses. Do not follow redirects to out-of-scope systems. Validate all redirects against scope before following. Do not execute code from target responses or error messages. Log all manipulation attempts with context. |
Post-exploitation involves lateral movement, persistence testing, and data access validation where scope boundary enforcement is critical to prevent testing from expanding beyond authorization. Discovered credentials create temptation to test additional systems; reversible action tracking enables safe cleanup. Approaching test window expiration requires graceful phase transition.
| Requirement Area | Key Requirements | What Must Be Done |
|---|---|---|
| Lateral movement enforcement | SE-013 | Restrict all lateral movement to in-scope networks only. Enforce hard limits on lateral movement hops (maximum intermediate systems tested). When lateral movement would exceed scope or hop limits, halt movement and alert operator. Validate each lateral movement target against scope before connection. Log all lateral movement decisions and scope validations. |
| Approval gates | HO-001 | Require human approval before lateral movement between systems and before persistence testing (installing agents, creating backdoors, modifying configurations). Use escalation workflow per SC-006: Medium risk requires standard approval, High requires elevated approval within 15 minutes, Critical requires senior approval + live confirmation. Default-safe behavior on timeout: DENY the movement. |
| Scope revalidation | SE-006, SE-016 | Revalidate scope immediately before each lateral movement action. Confirm target system is in-scope, not on deny list, and matches asset criticality restrictions. Revalidate that lateral movement chain stays within scope. If revalidation fails, halt movement and escalate to operator with clear explanation. |
| Credential management | SE-023 | Track all credentials discovered during exploitation (extracted passwords, API keys, tokens). Classify credentials as sensitive/confidential per data classification policy. Log all credential discovery with timestamp, source, and sensitivity. Prevent auto-use of discovered credentials without explicit operator approval. Document credential usage and validate it stays within scope. Revoke all discovered credentials during cleanup phase. |
| Reversible action tracking | SC-014 | For every reversible post-exploitation action (accounts created, files modified, database records changed, configurations altered), track: action name, timestamp, target, pre-action state, action parameters, rollback procedure, and verification method. Persist state to durable storage after each action. Test rollback procedures and document maximum rollback time per action type. |
| Impact monitoring | SC-010, SC-007 | Implement intensified monitoring during high-risk post-exploitation operations. Monitor target systems continuously for degradation, anomalies, or security alerts (IDS, firewall, endpoint detection). Alert operator if unintended impact detected. Track cumulative impact across post-exploitation activities. Escalate if threshold breached. |
| Escalation | HO-011, HO-012 | Escalate to operators if: unexpected findings discovered (evidence of prior breach, indicators of compromise, malware detected), impact thresholds breached (system degradation, resource exhaustion), temporal boundary approaching (countdown alerts at T-60min, T-30min, T-5min), or scope violations attempted. Document escalation reason, recipient, timestamp, and response. |
| Temporal boundary | SE-004, SE-008 | Enforce testing window strictly: no testing before start_time, immediate halt at end_time. Provide countdown alerts as engagement end approaches. Handle timezone transitions correctly (DST changes, leap seconds). After maintenance window ends, require explicit re-authorization before resuming (do not auto-resume). Log all temporal boundary enforcements. |
| Evidence preservation | SC-016, AR-003 | Before rolling back any reversible actions, capture and preserve evidence of successful exploitation: screenshots, log output, modified file contents, database query results, authenticated session proofs, privilege escalation evidence. Store evidence in write-once, tamper-evident storage. Preserve evidence independent of rollback storage. Retain evidence per engagement data retention policy. |
System restoration, evidence collection, and report generation shift focus to integrity, completeness, and accountability. All reversible actions must be rolled back, system baselines revalidated, testing artifacts cleaned up, findings validated and scored with evidence, and audit trails finalized and sealed. This phase ensures the engagement can be audited, findings are credible, and the target system returns to its original state.
| Requirement Area | Key Requirements | What Must Be Done |
|---|---|---|
| Rollback execution | SC-014 | Execute all rollback procedures for reversible actions in reverse order of execution. Verify each rollback succeeds with documented success criteria per action type. Alert operator if rollback verification fails. Document rollback completion timestamp and status. Complete rollback before cleanup begins. |
| Integrity validation | SC-015 | Run automated post-engagement integrity validation comparing post-test state against baseline: file checksums match, no unexpected user/service accounts exist, database record counts match baseline, configurations match baseline, no unexpected processes running. Complete validation within documented timeframe. Log discrepancies with clear error messages and escalate any failures. |
| Credential disposal | SE-023 | Rotate or destroy all testing credentials provisioned for the engagement. Verify old credentials no longer work after rotation. Log credential disposal actions with timestamp. Classify destroyed credentials as sensitive and handle securely. |
| Secret revocation | SE-023 | Revoke or destroy all secrets discovered during testing per engagement lifecycle policy. Revoked secrets: mark as compromised and prevent future use. Destroyed secrets: permanently delete from all storage locations. Verify revocation/destruction succeeded. Log all secret lifecycle events. |
| Evidence preservation | SC-016 | Write all exploitation evidence to immutable, tamper-evident storage (WORM storage, or blockchain hash). Preserve evidence independent of operational logs. Store evidence with cryptographic hash for integrity verification. Compute evidence hash at preservation time and verify periodically after. Retain evidence per engagement data retention policy. Make evidence accessible for post-engagement audit and finding validation. |
| Report generation | RP-003, RP-004 | Generate comprehensive engagement report including: findings with evidence provenance chains, confidence scores with auditable methodology, coverage matrix showing tested/untested vulnerability classes, false positive/negative rate disclosures, methodology section documenting testing approach and tools, human review documentation for Critical findings, and appendices with detailed evidence and audit trail excerpts. Report must be complete and accurate enough to support finding validation. |
| Confidence scoring | RP-003, RP-002 | Assign confidence score (0-100%) to each finding based on measurable factors: successful reproductions count, evidence quality (raw and inferred), attack path complexity. Use identical formula for all findings. Before report finalization, automatically re-verify each Critical/High finding by replaying exact attack sequence. Mark findings that fail re-verification as UNVERIFIED. Disclose overall re-verification rate in methodology section. Include per-finding reproduction rates for intermittent findings. |
| Coverage disclosure | RP-008 | Include vulnerability coverage matrix in Executive Summary or Methodology section listing: vulnerability classes tested (mapped to CWE), detection method per class (signature/heuristic/exploitation/behavioral), vulnerability classes explicitly excluded, vulnerability classes with partial coverage. Verify matrix reflects actual engagement configuration, not generic platform capabilities. Verify no claims of coverage for test modules that did not execute. |
| Finding correlation | SE-018 | If applicable, correlate findings with prior engagement cycles for same target. Identify newly discovered vulnerabilities compared to previously found and unremedialed. Track remediation status of prior findings. Include trend analysis in report. |
| Report delivery | RP-013, RP-014, RP-015 | Deliver report securely with tamper-evident packaging. Implement cryptographic signing or integrity verification (hash, HMAC, digital signature). Require recipient to verify integrity on receipt. Include evidence artifacts and audit trail excerpts as appendices with corresponding cryptographic hashes. Deliver via secure channel (encrypted email, secure portal with authentication). Log all report delivery events with timestamp and recipient confirmation. |
| Stakeholder notification | HO-017 | Notify all stakeholders (client, operators, management) of engagement completion. Provide summary of findings, testing duration, systems tested, and next steps. Confirm stakeholder acknowledgment of report delivery. Execute formal closure procedures documenting completion, all findings delivered, and engagement authority signature. |
| Audit trail finalization | AR-001, AR-008 | Finalize and seal audit trail preventing further modifications. Compute hash chain over all log entries using cryptographic algorithm (SHA-256 or equivalent). Create checkpoint hashes at regular intervals (every 1000 entries). Store checkpoint hashes in immutable location separate from primary logs. Sign audit trail with engagement authority. Archive logs per retention policy with secure access controls. Make audit trail available for review upon request. Document audit trail structure, retention period, and access procedures. |
The following requirements apply continuously throughout all engagement phases. These form the baseline safety and accountability layer across all phases. Consult the domain READMEs for authoritative scope. See Getting Started for domain selection by role.
| Requirement Area | Key Requirements | What Must Be Done |
|---|---|---|
| Audit logging | AR-001, AR-002 | Log every action at all times in structured format with millisecond-precision timestamps (UTC), event type classification, source component, target resource, status code, duration, and correlation ID. Log must include decision point logging with confidence score, alternatives evaluated, selected action, and rationale. Store logs in append-only, write-once format with cryptographic integrity protection. Verify logs cannot be modified after creation. Retain logs minimum 1 year, longer for regulatory requirements. Provide immutable access for post-engagement audit. |
| Kill switch readiness | SC-009, HO-008, HO-009 | Maintain multiple independent kill switch mechanisms (operator-initiated local, remote halt by authorized personnel, automatic failsafe on control plane loss) activatable at any moment during engagement. Test kill switch functionality weekly minimum. Verify Phase 1 (safety-critical cessation: halt new requests within 5 seconds) works independently of all other mechanisms. Verify Phase 2 (graceful shutdown: complete in-flight operations, preserve state, close connections within 60 seconds total) completes successfully. Document kill switch test results. For multi-operator scenarios, verify authority transfer during shift handoffs. |
| Scope enforcement | SE-006 | Perform scope validation immediately before every network action (TCP connect, DNS query, HTTP request, API call). Validate target is authorized, not on deny list, and matches asset criticality restrictions. Validate resolved IPs match target FQDN. Validate HTTP redirects before following. Validate cloud API calls against authorized accounts/regions. Reject out-of-scope actions with clear error message and alert operator. Log all scope validation decisions. Never allow scope to expand without explicit operator re-authorization. |
| Monitoring and alerting | SC-010, SC-017 | Continuously monitor target system health (response time, availability, error rates) and platform health (resource utilization, process state, behavioral anomalies). Monitor target systems at configured intervals (Critical=30 sec, Production=60 sec, Non-Prod=5 min). Monitor platform at high frequency (seconds) for anomalies (probe rates, escalation frequency, decision patterns, rollback frequency). Alert operators on degradation exceeding thresholds. Escalate to automatic halt on severe degradation. Log all monitoring events with metrics, thresholds, and alert status. Operate independent watchdog on separate infrastructure with separate credentials validating platform-reported metrics. |
| Operator availability | HO-019 | Ensure qualified operator available throughout engagement working hours and on-call outside working hours. Verify operator remains alert and responsive. For multi-operator shifts, ensure coverage with documented handoff procedures and kill switch authority transfer. Log operator availability status changes. Escalate to management if primary operator unavailable and secondary not contactable within [X] minutes. Maintain operator contact list with primary, secondary, and manager-on-call with verified phone/email/Slack channels. |
| Manipulation resistance | MR-001 | Validate and sanitize all external inputs (target responses, error messages, configuration files, API responses) before processing. Treat all target data as potentially adversarial. Detect instruction-like patterns, authority claims, and social engineering language in target responses and reject them. Do not execute code from target responses. Do not modify tool behavior based on target-provided content. Do not follow redirects to out-of-scope systems. Log all manipulation attempts with context. Alert operator to suspicious patterns. Maintain immutable instruction boundary separating operator commands from target data. |
| Time-based termination | SC-013 | Enforce maximum engagement duration configured in Rules of Engagement. Countdown alerts before termination (T-60 min, T-30 min, T-5 min). If testing exceeds end_time, immediately halt all activities. No testing resumes after end_time without new signed authorization. For testing pauses exceeding session timeout (default 4 hours), terminate sessions and require re-authentication on resume. Document time-based termination events with timestamp and reason. |
Transitions between testing phases SHOULD be governed by explicit criteria rather than operator judgment alone:
| Transition | Criteria | Trigger |
|---|---|---|
| Pre-Engagement → Reconnaissance | Scope validated, RoE signed, monitoring active, kill switch tested | Operator authorization |
| Reconnaissance → Exploitation | Discovery complete (no new targets in 24 hours or operator decision), findings reviewed, risk assessment complete | Operator approval at L1/L2; boundary check at L3/L4 |
| Exploitation → Post-Exploitation | Exploitation objectives met or time budget consumed, operator reviews findings | Operator approval required |
| Post-Exploitation → Reporting & Cleanup | Post-exploitation objectives complete, rollback initiated, evidence preserved | Automatic on scope completion or operator trigger |
For time-bounded engagements, the platform MUST reserve sufficient time for the Reporting & Cleanup phase regardless of progress in earlier phases. A minimum of 5% of total engagement time or 1 hour (whichever is greater) SHOULD be reserved for cleanup, with a soft target of 2 hours for engagements of 20 hours or more. For engagements under 4 hours, the platform SHOULD document the chosen cleanup window and the rationale for it, since fixed minimums may be disproportionate at that scale.