# Teaching Script — Module S00: Legal, Ethics, and Rules of Engagement **Module**: S00 — Legal, Ethics, and Rules of Engagement · **Duration**: ~60 minutes · **Target**: ~7,500 words **Format**: Verbatim transcript. Cues `[SLIDE N]` map to `03-slide-deck.html`. Stage directions in italics. Section breaks `---` mark natural pause points. > This script covers a 60-minute module in three 20-minute sub-sections. For a single-sitting recording, read straight through. For a classroom, pause at each `---` section break. The tone is senior engineer to senior engineer — direct, opinionated, every claim tied to a source or labeled as judgment. Nothing here is legal advice for your specific situation; everything here is the engineering mental model you need before you point an autonomous harness at anything that is not an isolated lab. --- [SLIDE 1 — Title] This is Module S Zero Zero: Legal, Ethics, and Rules of Engagement. Sixty minutes. The first module of Course Two A, Building AI Harnesses for Cybersecurity, and the one module in the entire course that is genuinely non-optional. By the end you will know the three jurisdictional frameworks that govern security testing, the authorization chain that makes your testing legal, what evidence you must keep and what you must destroy, and the four legal risks unique to autonomous harnesses — plus the control for each. I want to be direct about why this module exists. Every other module in this course is about engineering. This one is about not going to prison. The engineering is wasted if the legal layer is wrong. So we do this first. --- [SLIDE 2 — Why this module is non-optional] Course One assumed a cooperative target. The model reads files, calls tools, tool outputs are trusted. Every one of those assumptions breaks in this course. The target is an adversary. Tool outputs may contain injected payloads. The sandbox does not contain the agent — the agent reaches *out* through it to attack something. But before any of that technical inversion, there is a more fundamental one. *point to the callout* 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. Hear that. The authorization is the harness's license to exist. Not a nice-to-have. Not a legal footnote. The thing that separates your work from a felony. Everything else in this course is built on top of a defensible authorization. Get the authorization right, and the engineering is applied rigor on a solid base. Get it wrong, and no amount of engineering sophistication saves you. --- [SLIDE 3 — The inversion table] Here is the inversion table from the course's opening frame. Read down the left column — those are Course One's assumptions. Read down the right — those are the realities of security work. The loop runs until an evidence threshold is met, not until a task is complete. Verification means can I prove it to a client or a court, not did it work. The sandbox contains the agent becomes the agent reaches *out* through the sandbox to attack a target. This module is about the legal dimension of that last row. Everything else flows through S Zero One onward. But you cannot build S Zero One's scope enforcement, or S Zero Two's evidence chain, or S Zero Three's bounded autonomy, without the legal mental model first. So we anchor the legal layer here, and the engineering layer spends the rest of the course realizing it. --- [SLIDE 4 — Three sub-sections] Three sub-sections, twenty minutes each. *point to each* S Zero Zero point one: Authorization and Scope Law. The statutes, the cases, the authorization chain, and the bug bounty contract. S Zero Zero point two: Responsible Disclosure and Evidence Obligations. What you owe the vendor, what evidence you must preserve, and — this is the half most engineers skip — what evidence you must destroy. S Zero Zero point three: Harness-Specific Legal Risks. Where autonomy creates exposure that a human tester never had, and the engineering control for each. Let's go. --- [SLIDE 5 — S00.1 section card: the three frameworks] Sub-section one. Authorization and Scope Law. Three jurisdictional frameworks, because security testing crosses borders by default. A harness in Frankfurt probing a target in Virginia implicates at least two legal regimes at once. You need the mental model for each. *point to the grid* The United States — the Computer Fraud and Abuse Act, eighteen United States Code section ten thirty. The primary federal computer-intrusion statute. It covers accessing a computer without authorization, or exceeding authorized access, and obtaining information. Both civil and criminal liability attach. The United Kingdom — the Computer Misuse Act nineteen ninety, sections one and three. Broader than the post-Van Buren CFAA, and critically, no statutory researcher safe harbor. Good faith is not a defense to section one in the UK. The European Union is often misstated as having a single CFAA equivalent. It does not. It is layered. Directive twenty-thirteen-forty requires member states to criminalize unauthorized access — Germany transposes it into section two-oh-two-a of the Strafgesetzbuch, France into article three-twenty-three-one of the Code pénal. They differ in detail but share the core. Then the GDPR sits on top — and the GDPR is the dominant legal risk in most EU engagements, because a harness that retrieves personal data as a "proof" makes you a data controller for that data, with a penalty ceiling of twenty million euros or four percent of global turnover. That is the single most underestimated legal risk in EU security testing. NIS Two adds incident-reporting obligations. And note the Cyber Resilience Act — the CRA. *point to the orange card* The starter material references it, correctly, as a regime you should know exists. But here is the precision that matters: the CRA imposes product-security obligations on *manufacturers* of products with digital elements. It is not a pentest-authorization statute. Treating it as one is a category error. It is adjacent to this module, not central. The 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, bounded by scope. The statutes differ in how they define unauthorized and in how forgiving they are of good-faith overreach. None of them have a general "I meant well" defense. --- [SLIDE 6 — Van Buren v. United States] Now the case that reshaped the US framework. *Van Buren versus United States*, decided twenty twenty-one. Five ninety-three US three seventy-four. The Supreme Court adopted what commentators call the "gates-down" interpretation of "exceeds authorized access." *point to the callout* The Court held that "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 was a police officer who used his valid credentials to look up a license plate for an improper motive. The Court said that is not a CFAA violation. He was allowed through the gate; what he did behind it was a policy violation, not a crime under section ten thirty a two. Hear what this did and what it did not do. *point to the warn callout* What it did: it narrowed the CFAA. It helped researchers accused of misusing *authorized* access. What it did not do: it did not create a general good-faith defense. And it did not touch the threshold question of authorization itself. Out-of-scope access — a host the scope file never permitted — remains cleanly unprotected. Van Buren offers no shelter there. For a harness builder, the practical consequence is blunt. *point to the small text* Authorization is binary at the gate. Either the scope file permits the target, or the tool call is a potential section ten thirty a two violation. This is why S Zero One implements scope enforcement as a hard-wired gate, not a system-prompt line. The Van Buren decision moved the fence. It did not remove it. --- [SLIDE 7 — The authorization chain] Authorization is not a single document. It is a chain. *point down the chain* Asset owner at the top — the entity that owns the system under test. Program or engagement sponsor — the operator of the bug bounty program or the firm that commissioned the pentest. Program policy or statement of work — defines scope, rules of engagement, safe harbor, evidence rules. Then the scope file — the machine-checkable formalization of all of that. Then the scope enforcement middleware. Then the individual tool call. A break anywhere in this chain voids the legal cover for everything downstream. The cover is only ever created at the top — the asset owner's consent. Everything below is a transmission of that consent, in increasingly specific form, down to the atomic tool call. --- [SLIDE 8 — Three breaks] Three breaks to watch for. *point to each* Break one: sponsor does not equal 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 operator does not warrant owner authorization, the chain is broken. Break two: action outside the rules of engagement. Scope files authorize specific *actions* — passive recon, non-destructive testing, no DoS. A finding obtained by a forbidden action, on an in-scope host, is out of scope in the *legal* sense, not just the program sense. The harness must enforce the RoE, not just the target list. Break three: stale scope. A target in scope on Monday may be decommissioned, sold, or explicitly removed on Wednesday. Bug bounty scopes change. A harness with a stale scope file scans a host that is no longer authorized — and "the scope was current last week" is not a defense. *point to the small text* The scope file must carry a valid-until date and be re-verified before each session. --- [SLIDE 9 — The bug bounty program is 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 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. *point to the table* Scope — the exhaustive in-scope list. Both HackerOne and Bugcrowd, via the Disclose-dot-io standard, require scope to be an exhaustive list of properties, not "anything star-dot-example-dot-com." Exclusions — explicitly excluded assets that override apparent in-scope matches. A harness must check exclusions *after* matching scope, not before. Rules of engagement — the *behavioral* contract. Minimum necessary testing. Stop after validation. No data exfiltration. No DoS. No social engineering. Rate caps. These are distinct from the target list — a harness that enforces only the target list is enforcing half the contract. Safe harbor — conditional, covers in-scope and RoE-compliant only, and does not bind third parties. Disclosure — CVD baseline, often tied to bounty eligibility. Read the policy before you test, not after. --- [SLIDE 10 — S00.2 section card: disclosure] Sub-section two. Responsible Disclosure and Evidence Obligations. What you owe the vendor, and the two-sided evidence question — what you keep, and what you destroy. *point to the left* Coordinated Vulnerability Disclosure, CVD, is the baseline norm. You report the vulnerability privately. You give the vendor a reasonable window to fix it. You coordinate any public disclosure with them. The reference timelines: CERT-CC at Carnegie Mellon has published disclosure guidance for decades — their model is report privately, allow forty-five days as a default coordination window, public disclosure at or after that point if the vendor is unresponsive. The forty-five-day figure is a coordination norm, not a law. But it is the number most programs and mediators treat as the default. Individual programs specify their own — Google Project Zero runs a ninety-day window. The program policy is the contract; honor its timeline over the generic default. *point to the warn callout* Early public disclosure — even on a slow vendor — can void safe harbor and raise trade-secret or misuse claims, even when the initial finding was authorized. The window is the contract. 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. S Zero Two's evidence chain schema includes these fields explicitly. --- [SLIDE 11 — What evidence you must preserve] A 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. *point to the table* The minimum evidence for every finding. Timestamp in UTC — establishes *when*, which is critical for authorization-window disputes. Session or trace ID — correlates the finding to the harness run, and to the scope file in force at the time. Exact request and response — reproducibility; the vendor must be able to replay it. Tool and version — tool-specific false positives are real; the vendor needs to know what produced the finding. CVSS base vector as a draft — severity triage, but automate as a *draft* only, never final; hallucination risk is real here. Reproduction steps — the vendor's QA team must reproduce without you. And the last row, highlighted, because it is the legal anchor. *point* Scope reference — the scope entry that authorized the call that produced the finding. This is the single field that ties your finding to the authorization chain. This is the same append-only, scope-referenced evidence chain you build in S Zero Two. 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. --- [SLIDE 12 — What evidence you must NOT retain] Now the half most engineers skip. *point to the warn callout* The fact that you *can* capture a database dump does not mean you *may* keep it. This is where GDPR exposure lives. *point to the two cards* Personal data. If your exploit proof retrieves real user PII — names, emails, credentials, payment data — you have just become a data controller under GDPR, or touched state breach-notification law in the US. The rule: capture the *minimum* proof that demonstrates the vulnerability. 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, redact the key in the report, securely delete the captured key. Keeping a vault of keys you found on engagements is a target on your back and a breach waiting to happen. *point to the callout at the bottom* Hear the discipline. 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 rules of engagement explicitly forbid exfiltrating real data and require synthetic or redacted proof. Default to not capturing. If you must capture to prove impact, redact at capture time, store the redacted version only. --- [SLIDE 13 — The evidence retention lifecycle] The evidence record has a lifecycle. *point to the three cards* Capture minimum proof. Classify. Then retain or destroy based on the class. Public — no sensitive data — retain indefinitely, this is your portfolio artifact. Redacted — redacted at capture — retain for the engagement window plus a contractual tail. Restricted — real PII or credentials — destroy on report submission or per the engagement contract, whichever is sooner. And the destruction is itself recorded — you keep the record of the deletion, not the deleted data. *point to the small text* The deeper point. An evidence logger that writes everything forever and never destroys is building a compliance time bomb, not an evidence chain. The retention policy is not documentation. It is a control the harness enforces. --- [SLIDE 14 — S00.3 section card: four risks] Sub-section three. Harness-Specific Legal Risks. Four risks unique to autonomous security harnesses. *point to the table* Each one maps to a control that must exist before you point the harness at anything other than an isolated lab. Risk one: DoS-by-scanner. Risk two: out-of-scope tool calls. Risk three: evidence retention. Risk four: agentic escalation. Let's take each. --- [SLIDE 15 — Risk 1: when scanning becomes DoS] This is the question most offensive-harness builders ask too late. *point to the warn callout* There is no bright-line request rate that separates scanning from DoS. The threshold is effect-based. If your scanning materially impairs the target's availability, you are in DoS territory — and the intent requirement is satisfied by *recklessness* in several readings of section ten thirty a five, and under UK Computer Misuse Act section three. A scanner at five requests per second that takes down a fragile target is a DoS. A scanner at five hundred requests per second against a hardened one may be fine. The harness cannot know in advance which is which. So it must *react* to distress. *point to the list* Default to low concurrency — ffuf at thread count ten, not five hundred. Rate-limit below the target's visible tolerance — if the target rate-limits at a hundred requests per second, you scan at twenty. Never be the thing that trips the target's own DoS defenses. Back off on any sign of distress — five-x-x spikes, connection resets, latency degradation. This is a stop condition, not a retry. And respect explicit RoE rate caps — the number lives in the scope file, and the harness enforces it. *point to the small text* The control is a rate-limit and distress-detection middleware that wraps every outbound scanning tool, with the rate cap sourced from the scope file. Its legal function is a section ten thirty a five mitigation. It is not a performance optimization. --- [SLIDE 16 — Risk 2: scope enforcement is a legal control] Risk two. A harness that reasons in natural language will, eventually, propose an action outside scope. The target's robots-dot-txt points at an out-of-scope subdomain. A redirect chains to an excluded third party. 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. *point to the two cards* Scope enforcement is a legal control, not an engineering preference. The distinction matters because of what each implies about liability. On the left, the danger card. If scope is a system-prompt line — "only scan star-dot-target-dot-com" — and the model scans an out-of-scope host anyway because a redirect told it to, *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 section ten thirty a two charge. On the right, the accent card. If scope is 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. *point to the callout* And note the precision here. 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. Both are required. A harness with a great sandbox and no scope enforcement has contained the agent but let it attack the world. --- [SLIDE 17 — Risk 3 + Risk 4 lead-in] Risk three, briefly, because we covered the lifecycle already. The evidence chain is your protection until it becomes your liability. Under-retention: you delete too aggressively and cannot prove a finding when it is disputed. Over-retention: you keep everything forever in a single store, and now you hold a trove of PII and credentials from multiple clients, each with their own regulatory constraints. You have built a breach surface. The control is a retention policy with per-class periods and a documented, enforced destruction step. An evidence logger that writes forever and never destroys is building a time bomb. --- [SLIDE 18 — Risk 4: "the model did it" is not a defense] Risk four. The risk unique to autonomous security harnesses. *point to the warn callout* This is the load-bearing point of the whole module. When an autonomous harness commits a section ten thirty a two violation, there is no manufacturer-versus-operator contest. The operator — you — deployed the tool, configured its scope, pointed it at a target. The harness acted as your instrument. Liability does not transfer to the model. When an autonomous vehicle crashes, the manufacturer-versus-operator liability question is live and contested. When an autonomous *security harness* commits a computer-intrusion violation, there is no analogous contest. Every legal framework treats the operator of an automated tool as responsible for the tool's acts. Full stop. "The model decided to" is not a defense now, and is unlikely to become one. *point to the four green controls* The controls flow from accepting this. Autonomy at Level Three or below in production engagements — propose, approve, execute. The approval gate is a legal control as much as an engineering one. High autonomy, Level Four or Five, is for isolated lab targets, CTFs, benchmark runs — not real programs. Scope enforcement in code, not the system prompt. The legal posture must survive the model ignoring the scope instruction. An audit log that reconstructs every decision — for every tool call, the scope entry that authorized it. This is the authorization-chain-to-the-atom principle from sub-section one, realized as a runtime log. And a kill switch with a bounded blast radius — the harness must be stoppable instantly, and a single run must not reach beyond a single engagement's scope. Cap the concurrency, cap the session, cap the credential scope. --- [SLIDE 19 — The anti-patterns] Here are the anti-patterns, each of which carries a real penalty. *point to the table* Scope in the system prompt — cure is scope enforcement middleware, S Zero One point two. Full database dump as proof — cure is minimum-proof discipline, classify Restricted, destroy. Unbounded evidence store — cure is per-class retention with automated destruction. High-concurrency scan against production — cure is rate-limit and distress middleware sourced from the RoE. And "the model did it" — cure is bounded autonomy, scope in code, approval gates. Notice the pattern. Every anti-pattern is a shortcut. Every cure is a control. The shortcuts feel like engineering efficiency. The controls feel like overhead. In a general harness, the shortcut is usually fine. In a security harness, the shortcut is a legal exposure and the control is the mitigation. This is the inversion that defines the whole course. --- [SLIDE 20 — What you take into S01] So what do you take forward. *point to the win callout* The scope file is the input. The JSON you produce in this module's lab — authorized targets, rules of engagement, exclusions, valid-until — is exactly what S Zero One's scope enforcement middleware loads and checks on every outbound call. You are not producing a document. You are producing the input to a control. *point to the callout* The legal layer becomes the engineering layer. Authorization is binary at the gate. Scope is a hard-wired control. Evidence is an append-only, scope-referenced log. Retention is enforced, not documented. That is the whole module. Next is S Zero One — Security Harness Architecture. The offensive state machine. Scope enforcement built in code. Adversarial tool outputs defended. The legal mental model from this module becomes the engineering architecture in the next. *pause* One last thing. This module is not legal advice for your specific situation. It is the engineering mental model. When you build a real harness for a real engagement, you read the actual program policy, you read the actual statute in your jurisdiction, and — if the engagement is non-trivial — you get an actual lawyer to review your authorization chain. The model is one point six percent of the system. The harness is the other ninety-eight point four. And the legal layer is the foundation the whole harness stands on. Get it right. Then build. --- [End of script]