## TL;DR
The agent expands scope because nothing checks new targets against the engagement boundary before queueing them. Put an allowlist check in front of every queue insertion: any target outside the authorized scope is rejected, logged, and escalated, never scanned.

```text
(agent queues targets outside the authorized scope; list keeps growing)
```

## Use this when
- The agent's target queue contains hosts, domains, or ranges not in the engagement's scope definition.
- The queue keeps growing the longer the agent runs.

## Not for this skill when
- The new targets are in scope, like subdomains of an authorized domain. That is normal enumeration.
- A human expanded the scope. Human decisions are not agent loops.

## Steps
1. Freeze the queue: stop the agent from launching new scans immediately. Verify: no new scan processes start after the freeze.
2. Diff the queue against the engagement's scope definition line by line. Verify: you have an exact list of out-of-scope entries the agent added.
3. Remove the out-of-scope entries and confirm none were actually scanned: check the scan logs for those targets. Verify: the log shows no completed scans against out-of-scope hosts.
4. Add the guard: every target insertion checks the scope allowlist first, and rejections are logged with the reason. Verify: a test insertion of an out-of-scope host is rejected by the guard.
5. Report the incident to the test lead with the diff and the log evidence. Verify: the lead confirms whether any out-of-scope contact needs disclosure to the client.

## Variant phrasings
### agent scans out of scope
The incident-shaped phrasing.
### recon scope creep loop
The enumeration-shaped phrasing.
### agent adds unauthorized targets to queue
The queue-shaped phrasing.

Compatibility: harness scope-enforcement fix; tool-agnostic.

## Why it happens
Recon agents are rewarded for finding new assets, so "expand the target list" is their favorite move. Without a hard boundary check, subdomain enumeration drifts into neighboring domains, acquisitions, and shared infrastructure that were never authorized.

## Edge cases / pitfalls
- This is the one loop with legal consequences. Treat any out-of-scope scan as an incident first and a bug second.
- Scope definitions with wildcards need careful matching: a wildcard on one domain covers its subdomains but not the sibling domain the agent found next door.
- The guard must run on every insertion path, including retries and "related asset" suggestions, not just the main enumeration loop.
- If out-of-scope hosts were actually scanned, preserve the logs untouched; the incident review needs the unedited evidence.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZI-1xxshsulda4NZeWObiw