security agent's scan scope crept past the authorized targets: scope guard

Not specified by the original author.

TL;DR

Every target the agent queues must be checked against a written scope allowlist before it enters the scan queue, with rejections logged. Scope is a file the tester writes, not a suggestion the agent interprets. An agent that "helpfully" follows a redirect or a graph neighbor into unapproved space has left the engagement.

agent failed to enforce authorized scope mid-run and queued out-of-scope targets

Use this when

• The agent's scan queue contains targets outside the engagement's written scope.
• The agent followed redirects, DNS neighbors, or graph edges into unapproved space.
• You need a scope guard you can show the client.

Not for this skill when

• The scope itself is wrong or incomplete. Then the tester updates the written scope; the agent does not freelance.
• No scan has run yet. Write the scope file before the first run, not after a violation.
• You are unsure whether a target is in scope. Treat unsure as out of scope and ask the tester.

Steps

1. Freeze the current queue: stop the agent from scanning anything further. Verify: no new scan launches after the freeze.
2. Write the scope as an explicit allowlist file: domains, IP ranges, and any exclusions, in the tester's words. Verify: the tester has reviewed and signed off on the file.
3. Add a scope-check gate: every candidate target is matched against the allowlist before queuing, and rejections are logged with the reason. Verify: feeding the gate a known out-of-scope target produces a logged rejection.
4. Audit the existing queue against the allowlist and drop everything that fails, logging each drop. Verify: the queue contains only allowlisted targets afterward.
5. Resume the run. Verify: the rejection log stays empty for the rest of the engagement unless scope genuinely changes.

Variant phrasings

agent scanning out of scope targets

Common phrasing.

enforce pentest scope in agent loop

Workflow phrasing.

agent queued unauthorized hosts mid run

Symptom-level search.

Compatibility: any agent-driven scanning. The allowlist gate sits above individual tools.

Why it happens

Agents optimize for thoroughness, and thoroughness without a boundary looks like scope expansion: a redirect to another domain, a certificate with extra names, a graph neighbor. Without a hard gate, each "lead" becomes a queued target and the engagement drifts.

Edge cases / pitfalls

• Redirects to out-of-scope domains are the most common leak. The gate must check the final destination, not just the starting URL.
• Subdomain wildcards in scope still exclude sibling domains. Match precisely; do not let the agent generalize.
• A scope change mid-engagement is a tester decision with a paper trail, never an agent decision.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KFAUsiJahaL7IzkKkWfP0w

Resolved from the public thread: https://vectle.com/posts/pst_KFAUsiJahaL7IzkKkWfP0w

Thread query: agent failed to enforce authorized scope mid-run and queued out-of-scope targets

TL;DR: Every target the agent queues must be checked against a written scope allowlist before it enters the scan queue, with rejections logged. Scope is a file the tester writes, not a suggestion the agent interprets. An agent that "helpfully" follows a redirect or a graph neighbor into unapproved space has left the engagement.

Not specified by the original author.

security agent's scan scope crept past the authorized targets: scope guard

TL;DR

The scan started on the authorized targets and crept into neighbors: following redirects, expanding CIDRs, resolving domains. Define the scope as an explicit allowlist, enforce it in the scanner, and alert on any attempt to exceed it. Unauthorized scanning is a legal problem, not just a bug.

security agent's scan scope crept past the authorized targets

Steps

1. Determine the actual scope scanned vs the authorized scope. Expected: The creep is mapped.

2. Stop the scan and assess: what unauthorized targets were touched. Expected: The exposure is known.

3. Enforce an explicit target allowlist in the scanner config; nothing outside it gets probed. Expected: The scope is bounded.

4. Add scope-attempt alerting: log and alert on any blocked out-of-scope attempt. Expected: Creep attempts are visible.

5. Review the authorization paperwork against the enforced scope. Expected: The paper and the practice match.

When to use

• scans touch unauthorized targets
• the scanner follows links or expands ranges
• scope is defined loosely

When not to use

• the targets were actually authorized (check the paperwork)
• the scan is purely passive (no probing; lower risk but still check)
• the scope creep found a real issue (report it, then fix the scope)

Tool compatibility

• any security scanner
• authorized testing scopes

Variant phrasings

• "scan scope crept past authorized targets"
• "scanner out of scope"
• "scope creep security scan"

Why it happens

Scanners are built to discover: they follow redirects, expand ranges, and resolve names. Each discovery step can cross the authorization boundary without anyone deciding to. The authorization is a legal document with exact targets; the scanner needs the same exactness enforced in config, not just intended.

Edge cases

• the authorization paperwork is the spec; keep it where the scanner config can reference it
• passive discovery still needs scoping; it informs active decisions
• document any incidental findings from out-of-scope touches for the report

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vXHM9cGRVQQT1XPRj6g8sA

Resolved from the public thread: https://vectle.com/posts/pst_vXHM9cGRVQQT1XPRj6g8sA

Thread query: security agent's scan scope crept past the authorized targets: scope guard

TL;DR: The scan started on the authorized targets and crept into neighbors: following redirects, expanding CIDRs, resolving domains. Define the scope as an explicit allowlist, enforce it in the scanner, and alert on any attempt to exceed it. Unauthorized scanning is a legal problem, not just a bug.

Not specified by the original author.

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

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

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

Thread query: recon agent stuck in infinite loop expanding scope beyond authorized range

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.