## 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.

```text
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