**Focus:** Plan hat for the post-exploitation unit. From the established foothold (referenced from the upstream `ACCESS-LOG.md`), map what's reachable — lateral targets visible from this position, privilege-escalation paths, data accessible to the access level achieved — WITHOUT exfiltrating, modifying, or installing persistent state. The job is to draw the attack-graph an actual attacker would walk, not to walk it destructively. Reference frame: MITRE ATT&CK post-exploitation tactics (lateral-movement, privilege-escalation, discovery, credential-access) as a vocabulary, not a checklist.

You produce the unit body's **access-graph section** — a documented map of reachable surfaces, scoped strictly to read-only / observation-class techniques.

## Process

### 1. Confirm post-exploitation authorization

Post-exploitation often has its own ROE clause distinct from exploitation. Confirm:

- [ ] Post-exploitation analysis is in scope for this engagement
- [ ] Lateral exploration is permitted from this foothold (some engagements grant exploitation authority but not lateral-movement authority)
- [ ] Which classes of follow-on are permitted: read-only enumeration (typically yes), credential-access from accessible stores (typically gated), persistence installation (typically NO)
- [ ] Data-handling rules — what may you observe and document, what may you NOT capture even for proof

If anything is ambiguous, surface the question in the body and stop. Post-exploitation slips are how engagements end badly.

### 2. Map from the foothold outward

Starting from the access level established in exploitation, walk the standard post-exploitation axes:

- **Discovery** — what hosts, services, users, processes, and shares are visible from this position?
- **Lateral targets** — which of those are reachable from here without additional credentials?
- **Privilege-escalation paths** — what mechanisms (writable system files, sudoer rules, service-account chains, kernel-class issues if relevant, configuration weaknesses) could move from this access level to a higher one?
- **Credential-access surfaces** — what credential stores are observable from this access level (visible config files, environment variables, in-memory secrets if observation-class techniques apply)? Note presence, do not capture values.
- **Data-access surfaces** — what data is reachable from this access level? Note category, classification, and accessibility, do not capture content.

For each axis, distinguish **observed** (you actually saw it from this position) from **inferred** (you have a reason to believe it's reachable but haven't observed it).

### 3. Strict observation discipline

The line between observation and exfiltration is the hardest line in this stage. Hard rules:

- Listing a database table that contains customer data: observation
- Running a query that returns customer rows and recording the rows: exfiltration — DO NOT
- Noting that `aws_access_key_id` appears in `~/.aws/credentials`: observation
- Copying the credential value to the unit body: exfiltration — DO NOT
- Noting that a shell on host A could SSH to host B because the key file exists: observation
- Actually SSHing to host B: lateral movement, separate authorization required

Where the line is ambiguous, default to observation-only and surface the question in `## Open Questions`.

### 4. Body structure

```
## Access Graph

### Starting position
- Access level: <role / context>
- Host: <target>
- Citation: <ACCESS-LOG.md path / step id from exploitation unit>

### Discovery (observed)
- Hosts: <list with discovery technique>
- Services: <list>
- Users / contexts: <list>

### Lateral targets reachable from this position
| Target | Reachability evidence | Credentials required | Observed / Inferred |
|--------|----------------------|----------------------|---------------------|

### Privilege-escalation paths
| Mechanism | Evidence | Resulting access level | Observed / Inferred |
|-----------|----------|-----------------------|---------------------|

### Credential-access surfaces
| Store | Location | Observed credentials present? | Values captured? (must be NO) |
|-------|----------|------------------------------|-------------------------------|

### Data-access surfaces
| Store / dataset | Category | Classification | Accessibility from this position |
|-----------------|----------|----------------|-----------------------------------|

### Artifacts created during analysis
- <artifact> — <cleanup procedure>

### Open questions
<ambiguous lines, asks for ROE clarification, paths whose authorization was unclear>
```

## Anti-patterns (RFC 2119)

- The agent **MUST NOT** actually exfiltrate sensitive data instead of documenting its accessibility
- The agent **MUST NOT** attempt lateral movement outside the authorized scope
- The agent **MUST NOT** install persistent backdoors, scheduled tasks, or modified system configurations
- The agent **MUST NOT** fail to document the exact path taken at each step for reproducibility
- The agent **MUST** clean up artifacts (shells, temporary files, observation tooling) created during analysis, and confirm cleanup by observation
- The agent **MUST NOT** cause service disruption while exploring post-exploitation paths
- The agent **MUST** distinguish observed from inferred — inferred paths belong in the graph but cannot be reported as proven
- The agent **MUST NOT** capture actual credential values, customer data values, or any sensitive content — record presence and accessibility, not value
- The agent **MUST NOT** chain into a follow-on access (e.g., SSH from host A to host B) without explicit ROE authorization for that step — each chain step is its own scope check
