---
name: authorized-hunter-fieldwork
description: Turn one authorized target into a living surface map, ranked evidence-backed hypotheses, and minimal reproducible findings.
---

# Authorized hunter fieldwork

Use this skill only on assets the operator owns or has explicit permission to test.

## Required inputs

- Program or engagement name
- Current scope URL and retrieval time
- In-scope assets and explicit exclusions
- Rate, account, data-handling, and testing restrictions
- Available controlled accounts and roles
- Stop conditions

If scope or authorization is ambiguous, stop and ask for the current program brief.

## Durable artifacts

Maintain these records throughout the hunt:

1. Surface map: live hosts, ports, endpoints, parameters, JavaScript, APIs, identities, trust boundaries, and technology evidence.
2. Lead ledger: one record per hypothesis, including reachability, business impact, chain potential, evidence strength, owner, next discriminator, and status.
3. Dead-end ledger: tested assumptions and decisive negative evidence.
4. Evidence packet: timestamped requests, responses, screenshots, controls, roles, identifiers, and redaction notes.

## Procedure

### 1. Compile the authorization boundary

- Normalize targets without broadening wildcards.
- Record explicit exclusions next to overlapping in-scope patterns.
- Attach the source URL and retrieval time to every scope decision.
- Define a stop condition before each active test.

### 2. Fingerprint before prioritizing

Use low-impact evidence to identify frameworks, language, CDN, WAF, authentication method, API style, cloud, JavaScript libraries, and deployment shape. Rank test classes from observed technology, not from a generic checklist.

### 3. Read the client as an attack-surface map

Extract endpoints, parameter names, GraphQL operations, postMessage handlers, DOM sinks, storage usage, feature flags, source maps, internal hostnames, and third-party trust edges. Do not publish or retain secrets that are unnecessary for proof.

### 4. Write falsifiable hypotheses

Each lead must contain:

```yaml
id: lead-001
observation: concrete behavior or code path
hypothesis: one testable security claim
preconditions: []
reachability: 1-5
business_impact: 1-5
chain_potential: 1-5
evidence_strength: 1-5
cheapest_discriminator: one low-impact test
negative_control: expected safe comparison
stop_condition: explicit boundary
owner: one agent or hunter
status: queued | testing | supported | rejected | reported
```

### 5. Vary one thing

Keep method, body, headers, identity, timing, and environment stable except for the variable under test. Compare against a known-safe control. Reject leads when a cheaper explanation fits the evidence.

### 6. Expand around supported primitives

For a supported lead, map only plausible paths whose prerequisites can be tested safely. Examples include:

- Object read to cross-tenant enumeration to protected action
- Stored browser injection to privileged viewer execution
- Server-side fetch to trusted metadata access to temporary credentials
- Weak recovery state to session creation to protected account change
- CI token exposure to project secret access to controlled pipeline modification

Label every untested edge as a hypothesis. Do not report a chain as proven when only the first primitive is reproduced.

### 7. Produce a minimal report

Separate:

- Observed facts
- Reproduced capability
- Demonstrated impact
- Inferred but untested escalation
- Negative controls and rejected confounders

Use only controlled data in the proof. Redact tokens and personal data. Link the exact live scope policy.

## Completion gate

The skill is complete when every active lead is supported, rejected, or handed off with an owner and decisive next test, and every supported finding has a reproducible evidence packet within scope.