Course: 2A — Building AI Harnesses for Cybersecurity Module: S00 — Legal, Ethics, and Rules of Engagement Duration: 60 minutes Level: Senior Engineer and above Prerequisites: Course 1 complete (the harness is the other 98.4%; the model is 1.6%)
This module is non-optional. You are building attack tools. The law defines what that means — and an autonomous harness that acts outside authorization acts in your name, with your liability.
After completing this module, you will be able to:
Course 1 taught you to build a harness. It assumed a cooperative target: the model reads files, calls tools, and the tool outputs are trusted. Every one of those assumptions breaks when the target is an adversary and your harness is the weapon.
But before the technical inversion — which starts in S01 — there is a more fundamental inversion. A general harness that calls the wrong file wastes a token. A security harness that hits the wrong host commits a crime. The difference between a bug bounty payout and a federal indictment is not the tool. It is the authorization. The authorization is the harness's license to exist.
This module makes the legal layer explicit. It is the only module in the course where the "anti-patterns" carry criminal penalties, civil liability, and program bans. Get this wrong and no amount of engineering sophistication saves you. Get it right and the rest of the course is applied rigor on top of a defensible foundation.
Three sub-sections, twenty minutes each:
What constitutes authorized testing vs. illegal access — and the chain of permission that makes the difference.
Security testing crosses borders by default. A harness running in a Frankfurt datacenter that probes a target in Virginia implicates at least two legal regimes simultaneously. You need the mental model for each.
The CFAA, 18 U.S.C. § 1030, is the primary US federal statute covering computer intrusion. The provision that matters for security testing is § 1030(a)(2): accessing a computer "without authorization" or "exceed[ing] authorized access" and thereby obtaining information. Both civil and criminal liability attach. Criminal liability under § 1030(a)(5) covers intentional damage (including the damage caused by an over-aggressive scanner).
The key interpretive question — what does "without authorization" mean, and what does "exceeds authorized access" mean — was resolved (partially) by the Supreme Court in Van Buren v. United States, 593 U.S. 374 (2021). The Court adopted what commentators call the "gates-down" interpretation: "exceeds authorized access" means accessing a file, folder, or database you are not authorized to access at all, not accessing an authorized area for an improper purpose. Nathan Van Buren, a police officer who used his valid database credentials to look up a license plate for an improper motive, did not violate the CFAA.
What this means for a security harness builder: Van Buren narrowed the CFAA's reach in a way that helps good-faith researchers accused of accessing data they were permitted to access but for a disfavored reason. It did not create a general "good faith" defense, and it did not touch the threshold question of authorization itself. If you access a system you were never authorized to access — an out-of-scope host, a production database behind the test endpoint — Van Buren offers no shelter. The decision moved the fence; it did not remove it. For a harness, the practical consequence is blunt: authorization is binary at the gate. Either the scope file permits the target, or the tool call is a potential § 1030(a)(2) violation. This is why S01 implements scope enforcement as a hard-wired gate, not a system-prompt line.
The CFAA also covers damage. § 1030(a)(5)(B)–(C) reach reckless and even negligent damage under some readings. An autonomous scanner that takes down a production endpoint — even unintentionally, even "just fuzzing" — can cross from civil to criminal exposure. The "when does scanning become DoS" question (S00.3) lives here.
The UK Computer Misuse Act 1990 (CMA) is the parallel regime, and it is in several respects broader and less researcher-friendly than the post-Van Buren CFAA. Section 1 creates the offence of unauthorised access; section 3 creates the offence of unauthorised acts causing or creating risk of serious damage (added by the Police and Justice Act 2006). Crucially, UK courts have held that "authorisation" is assessed against the owner's expectations, and the CMA has historically been used against security researchers who accessed systems even with arguably good intent — a recurring complaint documented by the UK's reform consultations.
The CMA's relevance to a harness builder: the UK has no statutory researcher safe harbor. Good faith is not a defence to section 1. A harness that reaches a UK-based target needs written authorization from the asset owner — full stop. Bug bounty program terms help, but the CMA's breadth means the authorization chain (below) matters more in the UK than almost anywhere.
The EU picture is often misstated. There is no single "EU CFAA." Instead:
The operational rule across all three regimes is the same: the difference between authorized testing and a crime is the asset owner's consent, evidenced in writing, and bounded by scope. The statutes differ in how they define "unauthorized" and in how forgiving they are of good-faith overreach, but none of them have a general "I meant well" defense. Build the authorization chain first; the harness second.
Authorization is not a single document. It is a chain — a sequence of permissions, each linking to the next, from the asset owner down to the specific tool call your harness is about to execute. A break anywhere in the chain voids the legal cover for everything downstream.
Asset Owner
│ owns the system under test
▼
Program / Engagement Sponsor
│ operates the bug bounty program or commissioned the pentest
│ (is the sponsor authorized by the owner? in bug bounty, usually yes via program terms)
▼
Program Policy / Statement of Work
│ defines scope, rules of engagement, safe harbor, evidence rules
▼
Scope File (machine-checkable)
│ the formalized boundary: in-scope targets, allowed actions, exclusions
▼
Harness Scope Enforcement Layer
│ middleware that intercepts every outbound tool call
▼
Individual Tool Call (nmap scan, HTTP request, ffuf, exploit)
│ the atomic action; legal cover exists only if the full chain above is intact
Three breaks to watch for:
Sponsor ≠ owner. A bug bounty program run by a contractor for a client does not, by itself, authorize testing of the client's infrastructure. Read the program policy for a clear chain-of-authorization clause. If the program operator is not the asset owner and does not explicitly warrant owner authorization, the chain is broken.
Action outside the rules of engagement. Scope files typically authorize specific actions (e.g., "passive recon," "non-destructive testing," "no DoS"). A finding obtained by an action the RoE forbids — even on an in-scope host — is out of scope in the legal sense, not just the program sense. The harness must enforce RoE, not just target scope.
Scope drift across an engagement. A target that was in scope on Monday may be sold, decommissioned, or explicitly removed on Wednesday. Bug bounty scopes change. A harness with a stale scope file will happily scan a host that is no longer authorized — and "the scope was current last week" is not a defense. The scope file must have a valid_until and be re-fetched or re-verified before each session.
When you operate against a bug bounty program (HackerOne, Bugcrowd, a private VDP), the program policy is a contract, not a guideline. It creates reciprocal obligations: the program grants you authorization and safe harbor in exchange for your compliance with the rules of engagement. Breach the RoE and you may breach the contract — losing the safe harbor that was your legal protection.
The clauses that matter, every time:
The lab for this sub-section has you read a real HackerOne and Bugcrowd program policy and formalize the scope boundary as a JSON scope file. This is not busywork — that JSON file is the input to S01's scope enforcement middleware. The contract becomes code becomes a legal control.
What you owe the vendor, what you must keep, and what you must destroy.
Coordinated Vulnerability Disclosure (CVD) is the baseline norm: you report the vulnerability privately, you give the vendor a reasonable window to fix it, and you coordinate any public disclosure with them. The alternative — immediate public disclosure, or "full disclosure" on a fixed timer regardless of fix status — burns goodwill and, in several jurisdictions, invites legal action even when the initial finding was authorized.
The reference timelines:
For a harness, the disclosure timeline is an output the harness must support. A finding record that lacks the disclosure metadata (report date, vendor response, agreed publication date) is incomplete evidence. S02's evidence chain schema includes these fields explicitly.
A security finding without evidence is an opinion. A finding with a reproducible evidence chain is a deliverable — and, if it comes to it, a legal record. The minimum evidence you should preserve for every finding:
| Field | Why |
|---|---|
| Timestamp (UTC, with timezone) | Establishes when the finding was obtained — critical for authorization-window disputes |
| Session ID / trace ID | Correlates the finding to the harness run; ties it to the scope file in force at the time |
| Exact request (HTTP method, URL, headers, body) | Reproducibility — the vendor must be able to replay it |
| Exact response (status, headers, body) | Proof of impact; the response is the vulnerability in many cases |
Tool and version (e.g., nuclei v3.3.0, nmap 7.94) |
Tool-specific false positives are real; the vendor needs to know what produced the finding |
| CVSS base vector (draft) | Severity triage; automate as a draft only, never as final — hallucination risk |
| Reproduction steps (numbered, human-runnable) | The vendor's QA team must reproduce it without you |
| Scope reference (which scope entry authorized this) | The legal anchor — ties the finding to the specific authorization that permitted it |
This is the same "append-only, tamper-evident" evidence chain you build in S02. The point here is the legal function: this record is what you produce if the finding is disputed, if the program asks for clarification, or — worst case — if your authorization is ever questioned. A complete, timestamped, scope-referenced evidence chain is the single best protection against a "you accessed this without permission" accusation.
This is the half most engineers skip, and it is where GDPR exposure lives. The fact that you can capture a database dump does not mean you may keep it.
users table" is the finding; SELECT COUNT(*) FROM users is the proof; SELECT * FROM users is a breach you just committed. Many program RoE explicitly forbid exfiltrating real data and require synthetic or redacted proof.The retention policy (built in the lab) makes this explicit: a per-finding retention class (Public / Redacted / Restricted / Destroy-on-Report), a retention period per class, and a documented destruction step. A harness that auto-writes raw tool output to a permanent evidence store with no classification is building a compliance liability, not an evidence chain.
Safe harbor is the program's promise not to sue you for good-faith research that complies with the RoE. It is conditional and specific:
Read the safe harbor clause before you test, not after. If the program has no clear safe harbor, you are testing on the legal equivalent of a hope and a prayer, and no harness engineering will fix that.
Where autonomy creates exposure a human tester never had — and the control for each.
A human pentester who drifts out of scope gets a warning, a conversation, maybe a program suspension. An autonomous harness that drifts out of scope does so at machine speed, across hundreds of targets, with no internal voice saying "wait, should I be here?" The legal risks below are not hypothetical — each maps to a real control that must exist in the harness before it is pointed at anything other than an isolated lab.
This is the question most offensive-harness builders ask too late. The CFAA criminalizes intentional damage (§ 1030(a)(5)(A)) and reaches reckless and negligent damage in subsections (B)–(C). The UK CMA section 3 reaches "unauthorised acts" that impair operation. A scanner that saturates a target's bandwidth, exhausts its connection pool, or triggers a rate-limit cascade has crossed from "testing" into "impairing operation" — and the intent requirement is satisfied by recklessness in several readings.
There is no bright-line request rate that separates "scanning" from "DoS." The threshold is effect-based, not rate-based: if your scanning materially impairs the target's availability, you are in DoS territory regardless of whether you intended it. That said, operational heuristics reduce risk sharply:
-t 10, not -t 500.The control is a rate-limit + distress-detection middleware that wraps every outbound scanning tool, with the rate cap sourced from the scope file. This is built in S02 and reinforced throughout Pillar 1. The legal framing: this middleware is not a performance optimization, it is a CFAA § 1030(a)(5) mitigation.
A harness that reasons in natural language will, eventually, propose an action outside scope. The target's robots.txt points at a subdomain that's out of scope; a redirect chains to an excluded third party; a discovered IP resolves to infrastructure the program doesn't own. The model has no internal sense of "this is someone else's computer." It has to be told — and the telling must be enforced in code, not in prose.
Scope enforcement is a legal control, not an engineering preference. The distinction matters because of what each implies about liability:
This is why S01.2 implements scope as harness middleware between the agent and every network/filesystem action. Scope enforcement and code-execution sandboxing are two different control planes (scope controls where the agent can reach; the sandbox controls what the agent can do locally), and both are required. A harness with a great sandbox and no scope enforcement has contained the agent but let it attack the world.
The evidence chain is your protection — until it becomes your liability. Two failure modes:
The control is a retention policy with per-class periods and a documented destruction step, applied to the evidence store automatically. Public findings (no sensitive data) can be retained indefinitely as portfolio artifacts. Redacted findings are retained for the engagement window plus a contractual tail. Restricted findings (containing real PII/credentials) are destroyed on report submission or per the engagement contract — whichever is sooner. The harness must enforce this, not just document it. An evidence logger that writes forever and never destroys is building a time bomb.
This is the risk unique to autonomous security harnesses. A human tester who goes out of scope does so one action at a time and can be called back. An autonomous harness operating at Level 3+ autonomy (per the CAI autonomy model covered in S01) can chain dozens of out-of-scope actions in seconds before any human notices.
The liability does not transfer to the model. This is the load-bearing point. When an autonomous vehicle crashes, the question of manufacturer vs. operator liability is live and contested. When an autonomous security harness commits a § 1030(a)(2) violation, there is no analogous contest: the operator — you — deployed the tool, configured its scope, and pointed it at a target. The harness acted as your instrument. "The model decided to" is not a defense now, and is unlikely to become one. Every legal framework treats the operator of an automated tool as responsible for the tool's acts, full stop.
The controls flow from this:
Putting the scope rules in the system prompt and trusting the model to honor them. The model is a reasoner, not an access-control system. Cure: scope enforcement middleware (S01.2) that checks every outbound call against a structured scope file. The system prompt can describe the scope; it must not enforce it.
Capturing SELECT * FROM users to prove a SQL injection, then storing it in the evidence log. Cure: minimum-proof discipline — capture COUNT(*) or a single redacted row; classify the evidence as Restricted; destroy per the retention policy. The proof of the vulnerability is not the data, it is the ability to read the data.
Writing every tool output to a permanent evidence directory with no retention classification. Cure: retention policy with per-class periods and automated destruction. The evidence store is not a data lake.
Running ffuf at -t 500 or nuclei at full concurrency against a production program because "it's in scope." In-scope is not the same as invulnerable. Cure: rate-limit and distress-detection middleware sourced from the RoE; default to low concurrency in production contexts.
Deploying a high-autonomy harness against a real program and treating model decisions as the authorization layer. Cure: autonomy level matched to engagement (Level 2–3 in production); scope enforcement in code; approval gates on impactful actions. The operator is liable.
| Term | Definition |
|---|---|
| CFAA | Computer Fraud and Abuse Act, 18 U.S.C. § 1030 — the primary US federal computer-intrusion statute |
| Van Buren (2021) | Supreme Court case adopting the "gates-down" reading of "exceeds authorized access" — narrowed the CFAA but did not create a good-faith defense |
| CMA | Computer Misuse Act 1990 (UK) — broader than the CFAA; no statutory researcher safe harbor |
| Authorization chain | The unbroken sequence of permissions from asset owner to individual tool call; a break voids downstream cover |
| Scope file | The machine-checkable formalization of authorized targets, allowed actions, and exclusions — the input to scope enforcement |
| Rules of Engagement (RoE) | The behavioral contract: what you may do on in-scope assets, distinct from the target list itself |
| Safe harbor | The program's conditional promise not to pursue legal action against RoE-compliant research |
| CVD | Coordinated Vulnerability Disclosure — private report, vendor fix window, coordinated public release |
| Evidence chain | The append-only, scope-referenced, reproducible record tying a finding to its authorization |
| Retention policy | Per-class evidence retention periods with a documented destruction step |
| Scope enforcement middleware | The harness layer that intercepts outbound calls and checks them against the scope file — a legal control |
| Agentic escalation | The unique risk of autonomous harnesses acting outside authorization at machine speed; liability stays with the operator |
See 07-lab-spec.md. Three labs, one per sub-section: (1) read real HackerOne and Bugcrowd policies and formalize the scope boundary as a JSON scope file; (2) write a CVD timeline template and an evidence retention policy; (3) write a legal disclaimer and authorization checklist that runs before every engagement. The JSON scope file is the input to S01's scope enforcement middleware — the legal layer becomes the engineering layer.
# Module S00 — Legal, Ethics, and Rules of Engagement
**Course**: 2A — Building AI Harnesses for Cybersecurity
**Module**: S00 — Legal, Ethics, and Rules of Engagement
**Duration**: 60 minutes
**Level**: Senior Engineer and above
**Prerequisites**: Course 1 complete (the harness is the other 98.4%; the model is 1.6%)
> *This module is non-optional. You are building attack tools. The law defines what that means — and an autonomous harness that acts outside authorization acts in your name, with your liability.*
---
## Learning Objectives
After completing this module, you will be able to:
1. Distinguish authorized testing from illegal access under the CFAA (US), the Computer Misuse Act (UK), and EU member-state computer-crime regimes — and explain what *Van Buren v. United States* (2021) changed.
2. Trace an unbroken authorization chain from asset owner down to a single harness tool call, and identify the breaks that void your legal cover.
3. Read a bug bounty program policy as a contract: extract scope, safe harbor, rules of engagement, and evidence obligations into a machine-checkable scope file.
4. Write a coordinated disclosure timeline and an evidence retention policy that protects both you and the client — including what you must *not* retain.
5. Explain why scope enforcement is a **legal control**, not an engineering preference, and why a harness that exceeds scope has no "the model did it" defense.
6. Define the four harness-specific legal risks (DoS-by-scanner, out-of-scope tool calls, evidence retention liability, agentic escalation) and the control for each.
---
## Why this module exists
Course 1 taught you to build a harness. It assumed a cooperative target: the model reads files, calls tools, and the tool outputs are trusted. Every one of those assumptions breaks when the target is an adversary and your harness is the weapon.
But before the technical inversion — which starts in S01 — there is a more fundamental inversion. A general harness that calls the wrong file wastes a token. A security harness that hits the wrong host commits a crime. The difference between a bug bounty payout and a federal indictment is not the tool. It is the authorization. **The authorization is the harness's license to exist.**
This module makes the legal layer explicit. It is the only module in the course where the "anti-patterns" carry criminal penalties, civil liability, and program bans. Get this wrong and no amount of engineering sophistication saves you. Get it right and the rest of the course is applied rigor on top of a defensible foundation.
Three sub-sections, twenty minutes each:
- **S00.1 — Authorization and Scope Law.** The statutes, the cases, the authorization chain, and the bug bounty contract.
- **S00.2 — Responsible Disclosure and Evidence Obligations.** What you owe the vendor, what evidence you must preserve, what evidence you must destroy.
- **S00.3 — Harness-Specific Legal Risks.** Where an autonomous harness creates legal exposure that a human tester never had, and the controls for each.
---
# S00.1 — Authorization and Scope Law
*What constitutes authorized testing vs. illegal access — and the chain of permission that makes the difference.*
## The three jurisdictional frameworks
Security testing crosses borders by default. A harness running in a Frankfurt datacenter that probes a target in Virginia implicates at least two legal regimes simultaneously. You need the mental model for each.
### United States — the Computer Fraud and Abuse Act (CFAA)
The CFAA, 18 U.S.C. § 1030, is the primary US federal statute covering computer intrusion. The provision that matters for security testing is § 1030(a)(2): accessing a computer "without authorization" or "exceed[ing] authorized access" and thereby obtaining information. Both civil and criminal liability attach. Criminal liability under § 1030(a)(5) covers intentional *damage* (including the damage caused by an over-aggressive scanner).
The key interpretive question — what does "without authorization" mean, and what does "exceeds authorized access" mean — was resolved (partially) by the Supreme Court in ***Van Buren v. United States*, 593 U.S. 374 (2021)**. The Court adopted what commentators call the **"gates-down"** interpretation: "exceeds authorized access" means accessing a file, folder, or database you are *not authorized to access at all*, not accessing an authorized area for an improper purpose. Nathan Van Buren, a police officer who used his valid database credentials to look up a license plate for an improper motive, did not violate the CFAA.
**What this means for a security harness builder:** *Van Buren* narrowed the CFAA's reach in a way that *helps* good-faith researchers accused of accessing data they were permitted to access but for a disfavored reason. It did **not** create a general "good faith" defense, and it did not touch the threshold question of *authorization itself*. If you access a system you were never authorized to access — an out-of-scope host, a production database behind the test endpoint — *Van Buren* offers no shelter. The decision moved the fence; it did not remove it. For a harness, the practical consequence is blunt: **authorization is binary at the gate**. Either the scope file permits the target, or the tool call is a potential § 1030(a)(2) violation. This is why S01 implements scope enforcement as a hard-wired gate, not a system-prompt line.
The CFAA also covers *damage*. § 1030(a)(5)(B)–(C) reach reckless and even negligent damage under some readings. An autonomous scanner that takes down a production endpoint — even unintentionally, even "just fuzzing" — can cross from civil to criminal exposure. The "when does scanning become DoS" question (S00.3) lives here.
### United Kingdom — the Computer Misuse Act 1990
The UK Computer Misuse Act 1990 (CMA) is the parallel regime, and it is in several respects *broader* and less researcher-friendly than the post-*Van Buren* CFAA. Section 1 creates the offence of **unauthorised access**; section 3 creates the offence of **unauthorised acts** causing or creating risk of serious damage (added by the Police and Justice Act 2006). Crucially, UK courts have held that "authorisation" is assessed against the *owner's* expectations, and the CMA has historically been used against security researchers who accessed systems even with arguably good intent — a recurring complaint documented by the UK's reform consultations.
The CMA's relevance to a harness builder: **the UK has no statutory researcher safe harbor.** Good faith is not a defence to section 1. A harness that reaches a UK-based target needs written authorization from the asset owner — full stop. Bug bounty program terms help, but the CMA's breadth means the authorization chain (below) matters more in the UK than almost anywhere.
### European Union — a layered picture, not a single statute
The EU picture is often misstated. There is no single "EU CFAA." Instead:
- **Directive 2013/40/EU** on attacks against information systems requires member states to criminalize illegal access, illegal system interference, and illegal data interference. Each member state transposes it into national law — Germany's § 202a *Strafgesetzbuch*, France's *Code pénal* art. 323-1, etc. These differ in detail (some require an "intent," some criminalize mere preparation) but share the core: **unauthorized access is a crime, and "unauthorized" tracks the owner's consent.**
- **The GDPR (Regulation 2016/679)** is the bigger risk in most EU engagements. A harness that accesses or exfiltrates personal data during testing — even accidentally, even in scope for the *security* test — triggers Article 5 (lawfulness) and Article 32 (security of processing) questions. If your harness retrieves a customer table as a "proof," you are now a data controller (or processor) for that data. The penalty ceiling is €20M or 4% of global turnover. This is the single most underestimated legal risk in EU security testing.
- **The NIS2 Directive (2022/2555)** imposes security and incident-reporting obligations on "essential and important entities." A pentest harness that triggers an incident at an in-scope entity can collide with those reporting duties.
- **The Cyber Resilience Act (Regulation 2024/2847)** is *adjacent, not central, to this module.* The CRA imposes product-security obligations on *manufacturers* of products with digital elements (vulnerability and incident reporting, security-by-design). It does not itself authorize or criminalize security *testing* by third parties. It appears here because the starter material references it — correctly, as a regime a security harness operator should know exists — but it is not a pentest-authorization statute. Treating it as one is a category error.
**The operational rule across all three regimes is the same:** the difference between authorized testing and a crime is the asset owner's consent, evidenced in writing, and bounded by scope. The statutes differ in how they define "unauthorized" and in how forgiving they are of good-faith overreach, but none of them have a general "I meant well" defense. Build the authorization chain first; the harness second.
## The authorization chain
Authorization is not a single document. It is a **chain** — a sequence of permissions, each linking to the next, from the asset owner down to the specific tool call your harness is about to execute. A break anywhere in the chain voids the legal cover for everything downstream.
```
Asset Owner
│ owns the system under test
▼
Program / Engagement Sponsor
│ operates the bug bounty program or commissioned the pentest
│ (is the sponsor authorized by the owner? in bug bounty, usually yes via program terms)
▼
Program Policy / Statement of Work
│ defines scope, rules of engagement, safe harbor, evidence rules
▼
Scope File (machine-checkable)
│ the formalized boundary: in-scope targets, allowed actions, exclusions
▼
Harness Scope Enforcement Layer
│ middleware that intercepts every outbound tool call
▼
Individual Tool Call (nmap scan, HTTP request, ffuf, exploit)
│ the atomic action; legal cover exists only if the full chain above is intact
```
**Three breaks to watch for:**
1. **Sponsor ≠ owner.** A bug bounty program run by a contractor for a client does not, by itself, authorize testing of the *client's* infrastructure. Read the program policy for a clear chain-of-authorization clause. If the program operator is not the asset owner and does not explicitly warrant owner authorization, the chain is broken.
2. **Action outside the rules of engagement.** Scope files typically authorize specific *actions* (e.g., "passive recon," "non-destructive testing," "no DoS"). A finding obtained by an action the RoE forbids — even on an in-scope host — is out of scope in the legal sense, not just the program sense. The harness must enforce RoE, not just target scope.
3. **Scope drift across an engagement.** A target that was in scope on Monday may be sold, decommissioned, or explicitly removed on Wednesday. Bug bounty scopes change. A harness with a stale scope file will happily scan a host that is no longer authorized — and "the scope was current last week" is not a defense. The scope file must have a `valid_until` and be re-fetched or re-verified before each session.
## The bug bounty program as a contract
When you operate against a bug bounty program (HackerOne, Bugcrowd, a private VDP), the program policy is **a contract**, not a guideline. It creates reciprocal obligations: the program grants you authorization and safe harbor in exchange for your compliance with the rules of engagement. Breach the RoE and you may breach the contract — losing the safe harbor that was your legal protection.
The clauses that matter, every time:
- **Scope / In-Scope Assets.** The exhaustive list of properties for which the organization explicitly provides safe harbor. Both HackerOne's and Bugcrowd's safe-harbor frameworks require scope to be an explicit, exhaustive list — not "anything *.example.com." Disclose.io, the cross-platform standard both platforms reference, formalizes this.
- **Out-of-Scope / Exclusions.** Explicitly excluded assets and asset *types* (third-party SaaS, vendor pages, certain subdomains). These override apparent in-scope matches. A harness must check exclusions *after* matching scope, not before.
- **Rules of Engagement (Behavior).** What you may and may not *do* on in-scope assets. Common clauses: "minimum necessary testing," "stop after validation," "no data exfiltration," "no DoS," "no social engineering," "no automated scanners above X requests/sec." These are *behavioral* constraints, distinct from the target list — and a harness that enforces only the target list is enforcing half the contract.
- **Safe Harbor.** The program's commitment not to pursue legal action against good-faith research that complies with the RoE. Safe harbor is *conditional*. Read the conditions. Some safe harbors are "clearance" style (HackerOne's framework, extended to cover AI-system research); some are narrower. None protect out-of-scope or RoE-violating conduct.
- **Disclosure Policy.** Who controls publication, on what timeline, and what pre-publication review the vendor requires. Coordinated Vulnerability Disclosure (CVD) is the baseline expectation; Microsoft, OpenAI, and others tie bounty eligibility to adherence to CVD.
**The lab for this sub-section** has you read a real HackerOne and Bugcrowd program policy and formalize the scope boundary as a JSON scope file. This is not busywork — that JSON file is the input to S01's scope enforcement middleware. The contract becomes code becomes a legal control.
---
# S00.2 — Responsible Disclosure and Evidence Obligations
*What you owe the vendor, what you must keep, and what you must destroy.*
## Coordinated Vulnerability Disclosure
Coordinated Vulnerability Disclosure (CVD) is the baseline norm: you report the vulnerability privately, you give the vendor a reasonable window to fix it, and you coordinate any public disclosure with them. The alternative — immediate public disclosure, or "full disclosure" on a fixed timer regardless of fix status — burns goodwill and, in several jurisdictions, invites legal action even when the initial finding was authorized.
The reference timelines:
- **CERT/CC coordination.** The CERT Coordination Center at Carnegie Mellon has published disclosure guidance for decades. Their model: report to the vendor, allow 45 days as a default coordination window, with public disclosure at or after that point if the vendor is unresponsive. The 45-day figure is a *coordination* norm, not a law — but it is the number most programs and mediators treat as the default.
- **Vendor timelines.** Individual programs specify their own. Some commit to 90-day fix windows (Google Project Zero's well-known policy); some are faster, some slower. The program policy is the contract; honor its timeline over the generic default.
- **Public disclosure.** Most programs require vendor sign-off before public disclosure, or a defined waiting period. Disclosing before the window closes — even if the vendor is slow — can void safe harbor and, in edge cases, raise claims under trade-secret or computer-misuse law.
For a harness, the disclosure timeline is an *output* the harness must support. A finding record that lacks the disclosure metadata (report date, vendor response, agreed publication date) is incomplete evidence. S02's evidence chain schema includes these fields explicitly.
## What evidence you must preserve
A security finding without evidence is an opinion. A finding *with* a reproducible evidence chain is a deliverable — and, if it comes to it, a legal record. The minimum evidence you should preserve for every finding:
| Field | Why |
| --- | --- |
| **Timestamp** (UTC, with timezone) | Establishes *when* the finding was obtained — critical for authorization-window disputes |
| **Session ID / trace ID** | Correlates the finding to the harness run; ties it to the scope file in force at the time |
| **Exact request** (HTTP method, URL, headers, body) | Reproducibility — the vendor must be able to replay it |
| **Exact response** (status, headers, body) | Proof of impact; the response *is* the vulnerability in many cases |
| **Tool and version** (e.g., `nuclei v3.3.0`, `nmap 7.94`) | Tool-specific false positives are real; the vendor needs to know what produced the finding |
| **CVSS base vector** (draft) | Severity triage; automate as a *draft* only, never as final — hallucination risk |
| **Reproduction steps** (numbered, human-runnable) | The vendor's QA team must reproduce it without you |
| **Scope reference** (which scope entry authorized this) | The legal anchor — ties the finding to the specific authorization that permitted it |
This is the same "append-only, tamper-evident" evidence chain you build in S02. The point here is the *legal* function: this record is what you produce if the finding is disputed, if the program asks for clarification, or — worst case — if your authorization is ever questioned. A complete, timestamped, scope-referenced evidence chain is the single best protection against a "you accessed this without permission" accusation.
## What evidence you must NOT retain
This is the half most engineers skip, and it is where GDPR exposure lives. **The fact that you *can* capture a database dump does not mean you *may* keep it.**
- **Personal data.** If your exploit proof retrieves real user PII — names, emails, credentials, payment data — you have just become a data controller (GDPR) or touched state breach-notification law (US, per-state). The rule: capture the *minimum* proof that demonstrates the vulnerability. For a SQL injection, "I can read the `users` table" is the finding; `SELECT COUNT(*) FROM users` is the proof; `SELECT * FROM users` is a breach you just committed. Many program RoE explicitly forbid exfiltrating real data and require synthetic or redacted proof.
- **Credentials and secrets.** If you find exposed credentials or API keys, *do not* retain them in your evidence store beyond the minimum needed to report. Report the exposure ("I found a valid AWS access key at this location"), redact the key in the report, and securely delete the captured key. Keeping a vault of "keys I found on engagements" is a target on your back and a breach waiting to happen.
- **Customer data of any kind.** Default to not capturing. If you must capture to prove impact, redact at capture time, store the redacted version only, and document the redaction in the evidence record.
The retention policy (built in the lab) makes this explicit: a per-finding retention class (Public / Redacted / Restricted / Destroy-on-Report), a retention period per class, and a documented destruction step. A harness that auto-writes raw tool output to a permanent evidence store with no classification is building a compliance liability, not an evidence chain.
## Safe harbor — reading the fine print
Safe harbor is the program's promise not to sue you for good-faith research that complies with the RoE. It is **conditional and specific**:
- **It covers in-scope assets only.** Out-of-scope testing is unprotected, period.
- **It covers RoE-compliant behavior only.** A safe harbor that says "good-faith security testing" and an RoE that says "no DoS" means a DoS — even an accidental one — may fall outside the safe harbor.
- **It does not cover third-party claims.** If your testing of an in-scope asset incidentally affects a third party (a shared-infrastructure provider, a customer on the same SaaS), the program's safe harbor does not bind that third party. They can still sue or report you.
- **It does not cover data mishandling.** Exfiltrating and retaining PII is not "security testing" — it is a separate act that the safe harbor was never written to protect.
Read the safe harbor clause before you test, not after. If the program has no clear safe harbor, you are testing on the legal equivalent of a hope and a prayer, and no harness engineering will fix that.
---
# S00.3 — Harness-Specific Legal Risks
*Where autonomy creates exposure a human tester never had — and the control for each.*
A human pentester who drifts out of scope gets a warning, a conversation, maybe a program suspension. An autonomous harness that drifts out of scope does so at machine speed, across hundreds of targets, with no internal voice saying "wait, should I be here?" The legal risks below are not hypothetical — each maps to a real control that must exist in the harness before it is pointed at anything other than an isolated lab.
## Risk 1 — Automated scanning at scale: when does a harness become a DoS?
This is the question most offensive-harness builders ask too late. The CFAA criminalizes intentional damage (§ 1030(a)(5)(A)) and reaches reckless and negligent damage in subsections (B)–(C). The UK CMA section 3 reaches "unauthorised acts" that impair operation. A scanner that saturates a target's bandwidth, exhausts its connection pool, or triggers a rate-limit cascade has crossed from "testing" into "impairing operation" — and the intent requirement is satisfied by *recklessness* in several readings.
**There is no bright-line request rate that separates "scanning" from "DoS."** The threshold is effect-based, not rate-based: if your scanning materially impairs the target's availability, you are in DoS territory regardless of whether you intended it. That said, operational heuristics reduce risk sharply:
- **Default to low concurrency.** A handful of parallel connections, not hundreds. ffuf at `-t 10`, not `-t 500`.
- **Rate-limit below the target's visible tolerance.** If the target rate-limits at 100 req/s, scan at 20. You should never be the thing that trips the target's own DoS defenses.
- **Back off on any sign of distress.** 5xx spikes, connection resets, response-time degradation. The harness must *react* to distress, not power through it. This is a stop condition, not a retry.
- **Respect explicit RoE rate caps.** Programs that specify "no more than X requests/sec" mean it. The scope/RoE file must carry the number, and the harness must enforce it.
The control is a **rate-limit + distress-detection middleware** that wraps every outbound scanning tool, with the rate cap sourced from the scope file. This is built in S02 and reinforced throughout Pillar 1. The legal framing: this middleware is not a performance optimization, it is a CFAA § 1030(a)(5) mitigation.
## Risk 2 — Out-of-scope tool calls: scope enforcement as a legal control
A harness that reasons in natural language will, eventually, propose an action outside scope. The target's `robots.txt` points at a subdomain that's out of scope; a redirect chains to an excluded third party; a discovered IP resolves to infrastructure the program doesn't own. The model has no internal sense of "this is someone else's computer." It has to be told — and the telling must be enforced in code, not in prose.
**Scope enforcement is a legal control, not an engineering preference.** The distinction matters because of what each implies about liability:
- If scope is a system-prompt line ("only scan *.target.com"), and the model scans an out-of-scope host anyway (because a redirect told it to, or because it reasoned that the host "looked related"), *you* are liable. You deployed a tool that made authorization decisions by asking the model nicely. No court will accept "the LLM got confused" as a defense to a § 1030(a)(2) charge.
- If scope is a hard-wired middleware that intercepts every outbound network call and checks it against a structured scope file before permitting it, the harness *cannot* act outside scope regardless of model behavior. The legal exposure collapses to "did the scope file authorize this?" — which is an auditable, binary question.
This is why S01.2 implements scope as harness middleware between the agent and every network/filesystem action. Scope enforcement and code-execution sandboxing are **two different control planes** (scope controls *where* the agent can reach; the sandbox controls *what* the agent can do locally), and both are required. A harness with a great sandbox and no scope enforcement has contained the agent but let it attack the world.
## Risk 3 — Evidence retention: who owns the log, and for how long?
The evidence chain is your protection — until it becomes your liability. Two failure modes:
- **Under-retention.** You delete evidence too aggressively and can no longer prove a finding when the program disputes it, or when a client needs the record for their own compliance (SOC 2, ISO 27001 evidence). The retention period must match the *engagement contract*, not your own convenience.
- **Over-retention.** You keep everything, forever, in a single evidence store. Now you hold a trove of PII, credentials, and proprietary data from multiple clients — each with their own contractual and regulatory constraints on where that data may live and how long it may be kept. You have built yourself a breach surface and a compliance violation.
The control is a **retention policy with per-class periods and a documented destruction step**, applied to the evidence store automatically. Public findings (no sensitive data) can be retained indefinitely as portfolio artifacts. Redacted findings are retained for the engagement window plus a contractual tail. Restricted findings (containing real PII/credentials) are destroyed on report submission or per the engagement contract — whichever is sooner. The harness must *enforce* this, not just document it. An evidence logger that writes forever and never destroys is building a time bomb.
## Risk 4 — Agentic escalation: if the harness acts beyond authorization, who is liable?
This is the risk unique to autonomous security harnesses. A human tester who goes out of scope does so one action at a time and can be called back. An autonomous harness operating at Level 3+ autonomy (per the CAI autonomy model covered in S01) can chain dozens of out-of-scope actions in seconds before any human notices.
**The liability does not transfer to the model.** This is the load-bearing point. When an autonomous vehicle crashes, the question of manufacturer vs. operator liability is live and contested. When an autonomous security harness commits a § 1030(a)(2) violation, there is no analogous contest: the operator — you — deployed the tool, configured its scope, and pointed it at a target. The harness acted as your instrument. "The model decided to" is not a defense now, and is unlikely to become one. Every legal framework treats the operator of an automated tool as responsible for the tool's acts, full stop.
The controls flow from this:
- **Autonomy level matched to engagement.** High autonomy (Level 4–5) is appropriate for isolated lab targets, CTFs, and benchmark runs. Production engagements against real programs sit at Level 2–3 — propose, approve, execute — for exactly this reason. The approval gate is a legal control as much as an engineering one.
- **Scope enforcement that does not depend on the model's compliance.** See Risk 2. The harness's legal posture must survive the model ignoring the scope instruction.
- **An audit log that reconstructs every decision.** If the harness is ever questioned, the log must show, for every tool call, the scope entry that authorized it. This is the "authorization chain to the atom" principle from S00.1, realized as a runtime log.
- **A kill switch and a bounded blast radius.** The harness must be stoppable instantly, and a single harness run must not be able to reach beyond a single engagement's scope. Cap the concurrency, cap the session, cap the credential scope.
---
## Anti-Patterns
### The "scope in the system prompt"
Putting the scope rules in the system prompt and trusting the model to honor them. The model is a reasoner, not an access-control system. Cure: scope enforcement middleware (S01.2) that checks every outbound call against a structured scope file. The system prompt can *describe* the scope; it must not *enforce* it.
### The full database dump as proof
Capturing `SELECT * FROM users` to prove a SQL injection, then storing it in the evidence log. Cure: minimum-proof discipline — capture `COUNT(*)` or a single redacted row; classify the evidence as Restricted; destroy per the retention policy. The proof of the vulnerability is not the data, it is the *ability to read* the data.
### The unbounded evidence store
Writing every tool output to a permanent evidence directory with no retention classification. Cure: retention policy with per-class periods and automated destruction. The evidence store is not a data lake.
### The high-concurrency scan against production
Running ffuf at `-t 500` or nuclei at full concurrency against a production program because "it's in scope." In-scope is not the same as invulnerable. Cure: rate-limit and distress-detection middleware sourced from the RoE; default to low concurrency in production contexts.
### "The model did it"
Deploying a high-autonomy harness against a real program and treating model decisions as the authorization layer. Cure: autonomy level matched to engagement (Level 2–3 in production); scope enforcement in code; approval gates on impactful actions. The operator is liable.
---
## Key Terms
| Term | Definition |
| --- | --- |
| **CFAA** | Computer Fraud and Abuse Act, 18 U.S.C. § 1030 — the primary US federal computer-intrusion statute |
| ***Van Buren* (2021)** | Supreme Court case adopting the "gates-down" reading of "exceeds authorized access" — narrowed the CFAA but did not create a good-faith defense |
| **CMA** | Computer Misuse Act 1990 (UK) — broader than the CFAA; no statutory researcher safe harbor |
| **Authorization chain** | The unbroken sequence of permissions from asset owner to individual tool call; a break voids downstream cover |
| **Scope file** | The machine-checkable formalization of authorized targets, allowed actions, and exclusions — the input to scope enforcement |
| **Rules of Engagement (RoE)** | The *behavioral* contract: what you may do on in-scope assets, distinct from the target list itself |
| **Safe harbor** | The program's conditional promise not to pursue legal action against RoE-compliant research |
| **CVD** | Coordinated Vulnerability Disclosure — private report, vendor fix window, coordinated public release |
| **Evidence chain** | The append-only, scope-referenced, reproducible record tying a finding to its authorization |
| **Retention policy** | Per-class evidence retention periods with a documented destruction step |
| **Scope enforcement middleware** | The harness layer that intercepts outbound calls and checks them against the scope file — a legal control |
| **Agentic escalation** | The unique risk of autonomous harnesses acting outside authorization at machine speed; liability stays with the operator |
---
## Lab Exercise
See `07-lab-spec.md`. Three labs, one per sub-section: (1) read real HackerOne and Bugcrowd policies and formalize the scope boundary as a JSON scope file; (2) write a CVD timeline template and an evidence retention policy; (3) write a legal disclaimer and authorization checklist that runs before every engagement. The JSON scope file is the input to S01's scope enforcement middleware — the legal layer becomes the engineering layer.
---
## References
1. **18 U.S.C. § 1030** — Computer Fraud and Abuse Act. The primary US federal computer-intrusion statute. § 1030(a)(2) (access); § 1030(a)(5) (damage).
2. ***Van Buren v. United States*, 593 U.S. 374 (2021)** — Supreme Court "gates-down" interpretation of "exceeds authorized access." Narrowed the CFAA; did not create a good-faith defense.
3. **Computer Misuse Act 1990 (UK)** — ss. 1, 3 (as amended). Broader than the post-*Van Buren* CFAA; no statutory researcher safe harbor.
4. **Directive 2013/40/EU** — EU directive on attacks against information systems; transposed into member-state law (e.g., DE § 202a StGB, FR Code pénal art. 323-1).
5. **Regulation (EU) 2016/679 (GDPR)** — personal-data processing rules; the dominant legal risk in EU security testing. Art. 5 (lawfulness), Art. 32 (security).
6. **Regulation (EU) 2024/2847 (Cyber Resilience Act)** — product-security obligations on manufacturers of products with digital elements. Adjacent to this module, not a pentest-authorization statute.
7. **CERT/CC** — Coordination norms for vulnerability disclosure; the 45-day default coordination window.
8. **HackerOne Safe Harbor framework** — authorization framework for good-faith security research, extended to AI systems.
9. **Bugcrowd / Disclose.io** — cross-platform safe-harbor and disclosure standard; scope as an exhaustive in-scope list.
10. **Google Project Zero** — 90-day disclosure policy reference.
11. **CAI (Cybersecurity AI), Alias Robotics** — autonomy-level model referenced in Risk 4; covered in depth in S01 and SDD-01.