Every finding I have ever thrown away for being out of scope hurt less than one out-of-scope request would have. That is the trade. You read the boundary carefully once, or you spend the rest of an engagement explaining to a program manager why you touched something you were never allowed to touch.

Scope is not the boring part before the real work. Scope is the work. A vulnerability outside the authorized boundary is not a bug bounty finding — it is unauthorized access to someone else’s system. The severity does not save you. The impact does not save you. The only thing that keeps the work on the right side of the line is a scope document you actually read.

What “in scope” actually constrains

A rules-of-engagement document is not one list. It is at least four, and they interact:

  • Assets. Which domains, IP ranges, apps, and API hosts you may test. This is the one everyone reads.
  • Vulnerability classes. Some programs explicitly exclude entire categories — no DoS, no social engineering, no physical, no automated scanning above a rate.
  • Techniques and limits. Rate caps, no destructive actions, no accessing other users’ data, no persistence, no lateral movement.
  • Data handling. What you may access if you find a hole, what you must stop at, and what you must never exfiltrate or store.

The mistake is treating the first list as the whole contract. The asset list tells you where. The other three tell you how far. You can be squarely on an in-scope host and still blow the engagement by dumping a production table to prove an injection you already proved with a single benign row.

The out-of-scope traps that catch people

Most scope violations are not reckless. They are drift. You start inside the boundary and follow a redirect, a link, a subdomain, a third-party widget — and you are outside without noticing.

  • Wildcard subdomains that aren’t yours. *.target.com sounds generous until one subdomain is a hosted service run by a vendor whose own program forbids testing.
  • Shared infrastructure. A load balancer, a CDN, an auth provider. The vulnerability lives in the target’s config; the box lives with someone who never authorized you.
  • Redirect chains. You test an in-scope endpoint, it 302s you to a login on a domain that is not in scope, and you keep going on autopilot.
  • Acquired companies. newco.com is owned by the target now, but the program scope was written before the acquisition and never lists it. Owned is not the same as authorized.
  • Staging and internal hosts you discovered. Finding internal-dev.target.com in a certificate transparency log does not put it in scope. Discovery is not permission.

The pattern in all of these: the target relates to the asset, so it feels authorized. Feeling authorized is worthless. The document authorizes you, and only for what it names.

The rule I run on

Before a single request goes to a new asset, it has to clear three checks:

  1. Is this exact asset named or clearly covered by a wildcard the program owns? If I have to construct an argument for why it counts, it does not count.
  2. Is the technique I am about to use permitted? Rate, class, destructiveness — all inside the stated limits.
  3. If this works, do I have a safe stopping point that proves impact without touching real user data or breaking anything?

If any answer is “not sure,” the request does not go out. The asset goes on a list, and the list becomes a question for whoever owns the scope. Ambiguity is not a green light. Ambiguity is a blocker, and a blocker is a result — you record it and ask, you do not resolve it in your own favor because you want the finding.

Why this is stricter when the work is automated

When a human is driving, drift is slow. You notice the domain changed in the address bar. You feel the hesitation before you paste a payload into something unfamiliar.

An automated workflow feels none of that. A recon script that follows every discovered host, a fuzzer pointed at a resolved wildcard, an agent chaining requests — none of them hesitate at the boundary unless the boundary is coded in. So the discipline moves earlier. The scope has to be an explicit allowlist the automation checks against, not a PDF a human read once and hoped the tools would respect. Passive-by-default, named assets only, and no active technique against anything the allowlist does not contain. The machine does exactly what you told it, at scale, including the parts you did not mean.

The unglamorous conclusion

Good scope discipline looks like nothing happening. No violation, no awkward email, no closed account, no engagement lost. The findings you skip because they sit an inch outside the line never show up in a report, so no one sees the ones you got right.

That invisibility is the job. The best security researchers are not the ones who test the most surface. They are the ones who never once tested surface they were not allowed to. Read the scope twice. When it is unclear, stop and ask. The boundary is the whole game.