"What is the central legal difference between a traditional pentest (2A) and an AI red-team (2B)?"	"In 2A, the target is infrastructure (servers, apps, contracts) under ONE owner. In 2B, the target is an AI SYSTEM and the 'asset owner' SPLITS into the PROVIDER (built the model, owns weights, sets ToS) and the DEPLOYER (runs the agent, owns data). The deployer CANNOT authorize violation of the provider's terms — that gap is the most common AI red-team legal mistake."	c2b::b0::recall
"Name the three jurisdictional frameworks for traditional computer-crime (inherited from 2A S00) and what each covers."	"(1) US CFAA (18 U.S.C. § 1030): § 1030(a)(2) access without/exceeding authorization; § 1030(a)(5) damage. (2) UK Computer Misuse Act 1990: s.1 unauthorised access, s.3 unauthorised acts — broader than post-Van Buren CFAA, no statutory researcher safe harbor. (3) EU: Directive 2013/40/EU (transposed nationally) + GDPR (personal data, the dominant EU risk) + NIS2 (incident reporting)."	c2b::b0::recall
"What did Van Buren v. United States (2021) decide, and what did it NOT do?"	"Adopted the 'gates-down' reading: 'exceeds authorized access' means accessing a file/folder/database you are NOT authorized to access AT ALL — not accessing an authorized area for an improper purpose. It NARROWED the CFAA (helps researchers accused of accessing permitted data for a disfavored reason) but did NOT create a general good-faith defense and did NOT touch the threshold question of authorization itself."	c2b::b0::recall
"Is a prompt injection 'access' under the CFAA?"	"UNSETTLED — no case law as of 2026. A plausible CFAA theory exists for the ATTACKER who injects a payload that causes unauthorized access, but a weak theory for a red-teamer testing their own employer's system with authorization. Practical rule: test only systems you own or are explicitly authorized to red-team. The authorization chain is your protection, not the novelty of the legal theory."	c2b::b0::recall
"Are model weights a trade secret, and what is the implication for a red-team?"	"YES, when the provider has taken reasonable steps to keep them secret. Exfiltrating weights to prove extractability is trade-secret misappropriation under the DTSA (18 U.S.C. § 1836) and EU Trade Secrets Directive (2016/943). The 'I did it to prove the vuln' defense is weaker than for SQLi because the weight file IS the protected asset and copying it IS the harm — there's no COUNT(*) equivalent. CONTROL: never exfiltrate weights to prove extractability; prove the PATH (reach N bytes), capture a HASH, report."	c2b::b0::recall
"How does DMCA § 1201 apply to AI red-teaming?"	"§ 1201 makes circumventing a 'technological measure that effectively controls access to a protected work' a crime, INDEPENDENT of any CFAA question. A model behind an API key, rate limiter, watermark, or output filter is behind such a measure. Bypassing it to reach the model may be a § 1201 violation. The Library of Congress triennial exemptions (17 C.F.R. § 201.40) include a narrow security-testing exemption that does NOT clearly cover AI models. RULE: if a test bypasses a model access control you don't own, get explicit written ToS/§ 1201 waiver or don't run it."	c2b::b0::recall
"Name three AI-specific legal regimes that have NO pentest analogue."	"(1) EU AI Act (Reg 2024/1689): prohibits some uses (Art 5), governs high-risk (Title III) and GPAI (Title VIII); a finding may be a legal non-compliance, not just a bug. (2) US EO 14110 + OMB M-24-10: AI incident-reporting duties; a red-team finding may be a reportable event. (3) State bot/deepfake/disclosure laws (CA AB 2013, SB 942, TX): touch red-team activity that generates realistic synthetic content."	c2b::b0::recall
"What is the dual-use dilemma unique to AI red teaming?"	"A successful jailbreak is SIMULTANEOUSLY (a) a security finding — a safety control failed, report it (CVD tradition) — AND (b) a misuse recipe — a copy-paste-usable prompt that bypasses refusal. The same artifact is both. Traditional security has dual-use problems but the gap between 'research' and 'offensive capability' is narrower for a jailbreak (literally usable by a non-technical attacker). This has no analogue in 2A."	c2b::b0::recall
"State the four disclosure principles that resolve the dual-use dilemma."	"(1) Report to the provider FIRST, always, before any publication. (2) Publish EXISTENCE and SEVERITY, not the RECIPE, by default. (3) Time-bound the embargo but make it LONGER than 90 days (~180 days for model-level findings — RLHF/retraining is measured in months, not weeks). (4) Decline to publish pure-misuse-enabling content with NO defensive lesson (provider-only disclosure) — this diverges from 'publish everything.'"	c2b::b0::recall
"What is the minimum-evidence field set for an AI security finding, and which field is most important?"	"Timestamp (UTC); MODEL VERSION/CHECKPOINT (the single most important — providers ship silent updates, a finding may not reproduce on the next version); exact prompt/payload; exact output; temperature/sampling params (jailbreak success is often sampling-dependent); success rate (N attempts/M successes — InjecAgent-style measurement); system prompt/config in force; scope reference (legal anchor)."	c2b::b0::recall
"What evidence must an AI red-team NOT retain, and why?"	"(1) PERSONAL DATA in retrieved context — you become a data controller (GDPR); capture minimum proof (one redacted row / count). (2) MODEL WEIGHTS & SYSTEM PROMPTS — trade secrets; capture a hash/byte-count, never the file. (3) WORKING JAILBREAK PROMPTS beyond the engagement — a misuse-enabling dataset; destroy on report, never carry cross-client."	c2b::b0::recall
"State the five AI-specific legal/ethical risks and the control for each."	"(1) WEIGHT EXFILTRATION → minimum-proof discipline (path+hash+bytecount, never file). (2) DUAL-USE PUBLICATION → 4 disclosure principles codified in RoE before testing. (3) THIRD-PARTY MODEL HARM (sweeps degrade shared infra) → rate-aware testing, dedicated/preview tier or local model. (4) PROVIDER ToS CONFLICT (deployer can't authorize provider violation) → provider_authorization check as precondition. (5) TEST-DATA CONTAMINATION (test traffic becomes training data) → opt out of training, test on frozen checkpoints."	c2b::b0::recall
"Why must an AI red-team RoE carry a dual-use clause that a traditional pentest SOW does not?"	"A traditional SOW covers scope and behavior. An AI red-team will, with high probability, discover a jailbreak that could enable misuse. Without a dual-use clause, the RoE FAILS at exactly the moment a serious finding appears — there's no agreed rule for whether to publish, share with provider, or suppress. The decision (publish existence vs recipe, embargo length, provider-only) must be made in the contract BEFORE testing, not in the moment."	c2b::b0::recall
"What is the deployer-vs-provider split, and why is it the most important concept in AI red-team authorization?"	"The 'asset owner' splits into the PROVIDER (built the model, owns weights, sets API ToS) and the DEPLOYER (runs the agent, owns the data). They are often different entities. The deployer can authorize testing of THEIR system but CANNOT authorize violation of the PROVIDER's terms. This is the link in the authorization chain where most AI red-team legal mistakes happen — a test that relies on deployer authorization alone and proceeds to jailbreak/extract from a model whose ToS forbids it has committed a ToS breach (a contested but live CFAA theory post-Van Buren)."	c2b::b0::recall
"Distinguish weight-extraction proof (allowed) from weight theft (the harm)."	"ALLOWED: reach the weight store (prove the path), read N bytes, compute a HASH of a small shard, log path+bytecount+hash, STOP — never save the shard. The finding is REACHABILITY. FORBIDDEN (the harm): download/save the full weights — this is trade-secret misappropriation (DTSA/EU TSD), the very harm the test was hired to prevent. The asymmetry: the same vulnerability can be proven with a hash OR committed as a 40GB theft. The harness must enforce the green path."	c2b::b0::recall
"Why is a single successful jailbreak a weak finding, and what is the standard?"	"Jailbreak success is often sampling-dependent and stochastic. A single success out of one attempt is weak evidence. The standard is a SUCCESS RATE over N attempts (InjecAgent-style measurement — cf. SDD-B03): '60% success over 100 attempts' is a strong finding; '1 success in 1 attempt' is an anecdote. Always report N/M, and the sampling parameters (temperature) that affect reproducibility."	c2b::b0::recall
"What is the provider_authorization field in an AI red-team scope file, and what does it enforce?"	"A per-TECHNIQUE field the red-team harness checks before any provider-surface action (weight read, jailbreak, system-prompt extraction). It must be one of: (a) provider ToS explicitly permits the technique; (b) a provider-issued waiver/preview enrollment is on file; (c) the model is self-hosted/open-weights and the deployer owns it. If none hold, the harness BLOCKS the technique. This is the AI analogue of 2A's 'scope enforcement is a legal control' — the deployer's authorization does not extend to provider-controlled surfaces."	c2b::b0::analysis
"A client asks you to red-team their production agent that calls an OpenAI model, including jailbreak attempts. OpenAI's AUP prohibits jailbreaking. What is the correct action?"	"You CANNOT proceed on the deployer's authorization alone — the deployer cannot authorize violation of OpenAI's terms. Options: (1) Stay within what OpenAI's terms permit (test the harness, the tools, the memory — NOT the model's refusal). (2) Enroll in OpenAI's official red-team/preview program (which waives the AUP for authorized research). (3) Obtain a separate provider waiver. Read the provider ToS BEFORE scoping and build the provider_authorization check into the harness gate."	c2b::b0::analysis
"Why does the CVD coordination window need to be longer (~180 days) for AI model-level findings than the traditional 90 days?"	"The 90-day default (Google Project Zero) is calibrated to software patches measured in WEEKS. AI mitigations for model-level jailbreaks are measured in MONTHS — a guardrail update is partial; a real fix is a retraining/RLHF round or a model-version bump. Reporting 'fixed/unfixed' is also wrong for AI — the right metric is measured RESIDUAL RISK (injection success rate before/after). 180 days reflects the actual fix cadence; harness-level fixes can stay on the 45-90 day track."	c2b::b0::analysis
"You find a 5-query jailbreak against a frontier model that works 60% of the time. Draft the responsible-disclosure decision."	"(1) Report to the provider FIRST (private report + the working prompt under NDA), before any external communication. (2) Do NOT publish the recipe in a public advisory — publish existence + severity + the residual-risk measurement (60% over N attempts). (3) Since it's model-level, set a ≥180-day embargo. (4) Evaluate defensive lesson: if the finding reveals a new technique class, publish the TECHNIQUE (not the prompt) after the window; if it's pure misuse with no architectural insight, withhold publication (provider-only). The decision was made in the RoE before testing, not now."	c2b::b0::analysis
"Design the provider_authorization_check() function the red-team harness runs before every provider-surface technique. What are its inputs and outputs?"	"INPUTS: the technique (e.g. 'jailbreak', 'weight_read', 'system_prompt_extract'), the target model id, and the engagement scope file. It looks up the scope file's provider_authorization entry for (technique, model) and checks: (a) does the provider ToS permit it? (b) is a waiver/preview enrollment on file and unexpired? (c) is the model self-hosted/open-weights owned by the deployer? OUTPUT: ALLOW or BLOCK with a reason. If BLOCK, the harness refuses to execute the technique. This is the engineering realization of 'the deployer cannot authorize what the provider forbids.'"	c2b::b0::analysis