recon agent stuck in infinite loop expanding scope beyond authorized range
Stops a recon agent that keeps adding out-of-scope targets while expanding scope on an authorized engagement. Use when the agent's target list grows past the engagement boundary on its own. Not for legitimate in-scope subdomain enumeration.
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.
(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
- Freeze the queue: stop the agent from launching new scans immediately. Verify: no new scan processes start after the freeze.
- 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.
- 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.
- 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.
- 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