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.

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