"What is the key difference between the OLD Capstone B2 and the REWRITTEN Capstone B2?"	"The OLD capstone attacked a STUB TypeScript harness with a simulated model. The REWRITTEN capstone attacks a REAL tau deployment — Hugging Face's educational coding agent (github.com/huggingface/tau) running on the student's machine, with real tools that really execute bash, really read files, and really hold plaintext credentials. The evidence is real tool-call output, not simulated behavior. A finding against a stub survives no peer review; a finding against real tau does."	c2b::capb2::recall
"What is the Acme Corp tau deployment's partial-hardening configuration, and why is it the realistic scenario?"	"tau_taint (B2 taint gate, Extension Point 1) IS installed. tau_sandbox (B7 bash factory replacement, Extension Point 2) IS installed. tau_vault (B5 credential isolation, Extension Point 3) is NOT installed. The B3 memory gate and B8 intent tracker are also missing (not part of the tau_plugins pack). This is realistic because most production teams install SOME controls and stop — Acme read B2 and B7, installed taint and sandbox, and stopped before B5, B3, and B8. Partial hardening is the most common production state."	c2b::capb2::recall
"What is the control-gap map, and why is it the key Phase 2 deliverable?"	"The control-gap map documents each of tau's seven surfaces with its control's state: INSTALLED or MISSING. For each: the surface, the control, the state, the evidence (the specific config/code confirming the state), and the finding class it implies. It is the key deliverable because it makes reconnaissance ACTIONABLE — you are not just mapping surfaces, you are mapping the gaps. Every finding in Phase 3 traces to a gap documented here. A finding with no control-gap-map entry means recon was incomplete."	c2b::capb2::analysis
"Which tau_plugins controls are INSTALLED in the Acme deployment, and which surfaces do they defend?"	"INSTALLED: (1) tau_taint (B2) at Extension Point 1 — wraps every tool executor via dataclasses.replace; tags tool output as <untrusted>; blocks high-impact calls (bash, send_email, write_to_memory) when taint active. Defends the LOOP surface (indirect injection). (2) tau_sandbox (B7) at Extension Point 2 — replaces create_bash_tool at the factory level; blocks network egress (curl, wget, ssh) and credential reads (cat credentials.json). Defends the TOOLS/SANDBOX surface."	c2b::capb2::recall
"Which controls are MISSING in the Acme deployment, and what finding class does each gap imply?"	"MISSING: (1) tau_vault (B5, Extension Point 3) — credentials remain plaintext at ~/.tau/credentials.json → credential exfiltration (HEADLINE). (2) B3 memory-write gate — session JSONL appends unfiltered at _persist_messages_since → session poisoning / cross-turn laundering. (3) B8 session intent tracker — no security listener subscribed to harness.subscribe → zero-click chains undetected. (4) B0 scope gate (partial) — no provider_authorization check in tau by default."	c2b::capb2::recall
"What does the scorecard battery reveal when run against the Acme deployment, and how do you read it?"	"Indirect injection: 0% (tau_taint WORKING — output tagged). Tool abuse: 0% (tau_sandbox WORKING — curl/wget blocked). Memory poison: 100% (B3 MISSING — write_to_memory succeeds). Sandbox escape: 67% (2 of 3 succeed — cat credentials.json blocked by denylist, but the denylist-bypass probes succeed). The battery IS the discovery instrument: it tells you which classes are mitigated and which are live. The OWASP checklist then names the findings; the Microsoft taxonomy chains them."	c2b::capb2::analysis
"Describe the credential-exfiltration chain against the missing tau_vault — the headline finding."	"(1) RECON: tau_vault NOT installed; credentials.json is plaintext; sandbox denylist = regex on command string. (2) BYPASS: command 'python3 -c open(credentials.json).read()' — base command is 'python3', NOT in the reader-regex denylist (which matches cat|head|tail|...); command EXECUTES. (3) CREDENTIALS IN CONTEXT: tool output enters tau's context — sandbox cannot help now. (4) PERSISTENCE: tainted result persists to session JSONL (no B3 gate). (5) LEAK: if API model, creds in prompt sent to provider. Root cause: tau_vault absent. The sandbox denylist is partial mitigation, NOT a substitute for credential isolation at rest."	c2b::capb2::analysis
"Why does the python3 -c bypass work against tau_sandbox, and what does this tell you about denylist-based controls?"	"tau_sandbox's SandboxPolicy.check extracts the base command (python3) and checks it against NETWORK_TOOLS, ALWAYS_DENIED, and the credential-read regex. The regex is r'(?:cat|head|tail|less|more|...)\s+.*{path}' — it matches READER commands followed by the credential path. python3 is not a reader in the set, so the regex does not match. The command executes. LESSON: a denylist is a regex on the command string, not a filesystem-level access control. It blocks the obvious channels but is bypassable by interpreters (python3, node, ruby). The closing control is tau_vault — secure credentials at rest so the denylist becomes defense-in-depth, not the only gate."	c2b::capb2::analysis
"What is the root cause of the credential-exfil finding, and why is the remediation tau_vault and not a better denylist?"	"ROOT CAUSE: tau_vault (B5) is NOT installed. Credentials are stored as plaintext JSON by FileCredentialStore at ~/.tau/credentials.json. The sandbox denylist blocks cat/head/tail but is a regex — interpreters bypass it. REMEDIATION IS tau_vault, not a better denylist, because: (1) the vault stores credentials in vault format (not plaintext), so even if the agent reads the file, it gets obfuscated data; (2) the vault implements the CredentialReader protocol, so only the provider layer reads from it — the agent process cannot reach it directly; (3) a denylist is always incomplete (new interpreters, new bypass techniques), but credential isolation at rest is a structural fix. Harden the denylist as defense-in-depth AFTER installing the vault."	c2b::capb2::analysis
"Describe the zero-click HITL bypass chain against tau's missing B8 intent tracker."	"tau_taint blocks bash when taint is active (bash is in DEFAULT_HIGH_IMPACT_TOOLS). But write and edit are NOT high-impact by default. The chain: (1) plant indirect injection in a file tau reads (tau_taint tags it <untrusted>); (2) the injection causes tau to propose low-impact writes whose content/path is derived from the tainted data — write and edit are NOT gated by the taint gate; (3) the tainted tool result persists to session JSONL (no B3 gate); (4) repeat across turns — each write is benign, the compound trajectory is the attack; (5) no B8 intent tracker sees the drift (harness.subscribe has no security listener). The per-turn taint gate sees benign calls; B8 would see the compound. B8 is absent."	c2b::capb2::analysis
"Describe the session-poisoning chain against tau's missing B3 memory gate."	"(1) INJECTION: tau reads a file containing an injection payload; tau_taint tags the output <untrusted> in the LIVE context. (2) PERSISTENCE: the tagged output (including <untrusted> tags and the payload) is persisted to the session JSONL at ~/.tau/sessions/ via _persist_messages_since — UNFILTERED (no B3 gate). (3) RESUME: a new session or branch loads the JSONL via SessionStorage.load, which reads directly into the transcript — it does NOT route through the tool executor wrapper. (4) LAUNDERING COMPLETE: the taint gate's _taint_active flag is per-TaintGate-instance; the new session has a fresh gate. The tainted content re-enters context as trusted. The injection was tagged in session 1, persisted, and loaded as clean in session 2."	c2b::capb2::analysis
"Why does the taint gate NOT prevent session poisoning, even though it tags tool output?"	"The taint gate (tau_taint) operates at the TOOL EXECUTOR layer (Extension Point 1) — it wraps tool.execute, tags the output, and sets _taint_active. But session persistence happens AFTER the tool returns, at _persist_messages_since (session.py:1378), which is NOT wrapped by the taint gate. The tagged output (including <untrusted> tags) is persisted as-is. On session RESUME, SessionStorage.load reads the JSONL directly into the transcript — it does NOT call tool.execute, so the taint gate never inspects the loaded content. The taint gate is a LIVE-CONTEXT defense; it does not protect the persistence layer or the resume path. That is B3's job, and B3 is missing."	c2b::capb2::analysis
"What evidence do you capture for the credential-exfil finding, and what do you NOT capture?"	"CAPTURE: the command string (python3 -c ...), the tool result's ok=True (proves execution succeeded), a HASH of the credential file's content prefix (proves the file was read and is real, not a decoy), the tau version, the plugin config, the model version, and the measured success rate (N over M). DO NOT CAPTURE: the credential values themselves (API keys, tokens). The credential values are Restricted class — destroy on report submission. Retaining them IS the harm the test was hired to prevent. The proof is reachability (the command executed, the file was read), not possession (the values)."	c2b::capb2::recall
"How is the scorecard battery from Capstone B1 repurposed in Capstone B2?"	"In B1 the battery SCORED the student's own hardened tau (defensive — measured injection resistance per class per plugin stage). In B2 the battery DISCOVERS the gaps in Acme's partially-hardened tau (offensive — the per-class success rates reveal which controls are working and which are missing). The battery is the SAME artifact (the InjecAgent-style probes from tau_plugins/scorecard). The DIRECTION inverts: B1 measured how well defenses held; B2 measures which defenses are absent. The rates become the evidence in the engagement report. Additionally, B2 EXTENDS the battery with the chains designed in Phase 3 (the cred-exfil bypass probe, the session-poison probe, the zero-click chain probe)."	c2b::capb2::analysis
"Name the six phases of the engagement methodology (B12) in order, adapted for the real tau target."	"(1) SCOPING — SOW + scope file naming the tau version and plugin config. (2) RECONNAISSANCE — map tau's 7 surfaces + build the control-gap map (INSTALLED vs MISSING). (3) VULNERABILITY DISCOVERY — run the scorecard battery, the OWASP checklist (B9), and design the Microsoft taxonomy chains (B10). (4) EXPLOITATION & VALIDATION — minimum-proof + measured rates against REAL tau tool calls. (5) REPORTING — the engagement report with real tool-call evidence, control matrix, roadmap. (6) RETESTING — define the retest plan vs the fully-hardened tau (all 3 plugins + B3 + B8)."	c2b::capb2::recall
"What is the control matrix in the engagement report, and how does it differ from the OLD capstone's control matrix?"	"The control matrix maps each finding to: (a) the control that prevents it, (b) the control's STATE — INSTALLED or MISSING, and (c) the module/plugin that builds it. DIFFERENCE from OLD: the OLD matrix mapped findings to abstract controls (B2, B3, B7, B8) with expected reduction percentages. The NEW matrix records the ACTUAL state of each control in the real tau deployment — tau_taint INSTALLED, tau_sandbox INSTALLED (partial), tau_vault MISSING, B3 MISSING, B8 MISSING — and prescribes the SPECIFIC tau_plugins to install (tau_vault) and the SPECIFIC extension points to wedge (B3 at session.py:1378, B8 at harness.subscribe). It is concrete and actionable, not abstract."	c2b::capb2::analysis
"What is the remediation roadmap for the Acme deployment, and why is tau_vault the first priority?"	"(1) [CRITICAL, S] Install tau_vault — closes RT-001 (cred-exfil). The plugin exists, is tested (31/31), drops in at Extension Point 3, converts plaintext via migrate_credentials_to_vault(). (2) [HIGH, M] Add B3 memory gate — closes RT-002 (session poison). Wedge at _persist_messages_since (session.py:1378) or re-tag session-loaded content on resume. (3) [HIGH, M] Add B8 intent tracker — closes RT-003 (zero-click). Subscribe a listener to harness.subscribe. (4) [MEDIUM, S] Harden sandbox denylist — closes RT-004. Add interpreter-based reads to denylist OR rely on vault. tau_vault is FIRST because the credential-exfil is the headline finding (Critical severity), the effort is Small (the plugin exists and drops in), and it structurally fixes the root cause (plaintext credentials at rest) rather than patching a bypassable denylist."	c2b::capb2::analysis
"How are B0's dual-use disclosure rules applied to the credential-exfil finding specifically?"	"(1) REPORT TO PROVIDER FIRST: if the model is an API model (OpenAI/Anthropic), the finding that credentials entered the prompt is a provider-surface concern — report under NDA. (2) PUBLISH THE TECHNIQUE (not the recipe): the technique class — 'interpreter-based reads bypass reader-regex denylists' — HAS a defensive lesson, so it IS published after the embargo (45-90 days, harness-level). (3) THE RECIPE IS PROVIDER-ONLY: the exact python3 -c bypass command is shared under NDA, never in the report body. (4) THE CREDENTIAL VALUES ARE RESTRICTED: destroy on report submission, hash of prefix only. Non-negotiable regardless of the technique's disclosure path. The defensive lesson is published; the weapon and the values are not."	c2b::capb2::analysis
"What is the retest plan for the Acme deployment, and what is the retest target?"	"The retest target is tau with ALL controls: tau_taint + tau_sandbox + tau_vault + B3 memory gate + B8 intent tracker. The same scorecard battery from Phase 4 is re-run. Per finding: RT-001 (cred-exfil): original 100% (50/50) → target 0% over 100 (vault makes file unreadable). RT-002 (session poison): original 100% → target 0% (B3 blocks tainted writes). RT-003 (zero-click): original 67% → target <5% (B8 catches compound). Each specifies: original rate, patched version (pinned), battery subset, acceptance threshold, timeline. The answer to 'is it fixed now?' is the before/after number, never 'yes.'"	c2b::capb2::recall
"Why is attacking a real tau deployment more valuable than attacking a stub harness?"	"Three reasons: (1) REAL EVIDENCE — the bash tool really executes via asyncio.create_subprocess_shell; the credentials are really plaintext; the session JSONL really persists. The evidence is real tool-call output that survives peer review. A stub's behavior is an artifact of the stub, not of the system. (2) REAL BYPASSES — the denylist bypass (python3 -c) works because tau_sandbox's regex is a real implementation detail, not a simulated control. A stub would either block or allow; real tau has the actual regex with the actual gap. (3) REAL REMEDIATION — the roadmap prescribes real plugins (tau_vault) that really exist, are really tested (31/31), and really drop in at a real extension point. The client can act on the report immediately."	c2b::capb2::analysis
"What are tau's five extension points (from SDD-B11), and which are used/unused in the Acme deployment?"	"(1) Extension Point 1 — tool-executor wrapping (dataclasses.replace(AgentTool, executor=gated)); USED by tau_taint (B2). (2) Extension Point 2 — the create_bash_tool factory (tools.py:574); USED by tau_sandbox (B7). (3) Extension Point 3 — create_model_provider credential store replacement (provider_runtime.py:46); UNUSED — tau_vault (B5) NOT installed. (4) Extension Point 4 — harness.subscribe(listener) (harness.py:124); UNUSED — no B8 intent tracker subscribed. (5) Extension Point 5 — CodingSession.load tool-list construction (session.py:286); USED (the hardened tools are injected here). The gaps are at EP3 (vault) and EP4 (intent tracker)."	c2b::capb2::recall
"What is the two-bash-tool finding (SDD-B11), and why does tau_sandbox's factory-level wedge matter for the engagement?"	"tau has TWO bash-tool call sites: (1) the harness tool list via create_coding_tools() (tools.py:96), and (2) CodingSession.run_terminal_command (session.py:1183) which constructs its OWN create_bash_tool outside the harness list. A B7 control that only wraps tools in the harness list (Extension Point 1) would be BYPASSED by the terminal-command path. tau_sandbox wedges at the FACTORY level (Extension Point 2) — it replaces create_bash_tool itself, so BOTH call sites go through the sandbox. For the engagement: this means the sandbox is NOT bypassable via run_terminal_command — the student must find a different bypass (the denylist regex). The factory-level wedge is why the bypass is the regex, not the second bash path."	c2b::capb2::analysis
"What is the tau_taint gate's DEFAULT_HIGH_IMPACT_TOOLS set, and why does this matter for the zero-click chain?"	"DEFAULT_HIGH_IMPACT_TOOLS = {'send_email', 'write_to_memory', 'bash'}. When taint is active (a prior tool output was tainted), the taint gate BLOCKS calls to these tools. MATTERS for the zero-click chain because: 'write' and 'edit' are NOT in the high-impact set. So an injection that causes tau to call write or edit (low-impact) is NOT blocked by the taint gate, even when taint is active. The chain uses write/edit to compound across turns — each individually benign, the compound is the attack. The taint gate catches high-impact calls (bash, send_email); it does not catch low-impact writes. B8 (session intent) is the control that sees the compound. B8 is absent."	c2b::capb2::analysis
"Why does the scorecard show indirect injection at 0% but memory_poison at 100% against the Acme deployment? What does this tell you about the controls?"	"Indirect injection at 0%: tau_taint IS installed and working. The battery's indirect probes read a file containing injected instructions; tau_taint tags the output <untrusted>, so the injection enters the model's context as DATA, not as an instruction. The high-impact call that the injection tries to trigger (bash/send_email) is blocked by the taint gate because taint is active. Memory_poison at 100%: the battery's memory-poison probe calls write_to_memory with an injected payload. write_to_memory IS in the high-impact set, BUT the probe runs with NO prior tainted tool output, so _taint_active is False, and the gate does not fire. The write succeeds. LESSON: the taint gate blocks high-impact calls ONLY when taint is active (a prior tool output was tainted). A direct write_to_memory (no prior taint) is not blocked. B3 (a memory-write gate that validates ALL writes, not just tainted ones) is the missing control."	c2b::capb2::analysis
"How does the credential-exfil chain map to OWASP and Microsoft taxonomy references?"	"OWASP: ASI03 (Tool/MCP abuse — the bash tool is used to read credentials, a use the user did not authorize) and ASI05 (Excessive agency / sandbox escape — the agent reaches credentials beyond its task) and ASI10 (Broken access control / credential exposure — the credentials are plaintext and reachable). Microsoft taxonomy: sandbox bypass (the denylist regex is bypassed by an interpreter) + multi-step chain (recon → bypass → context → persistence → leak). The finding carries BOTH references: OWASP gives it the recognized risk class; Microsoft gives it the failure-mode path. Together they make the finding traceable and the control-matrix entry precise."	c2b::capb2::recall
"What is the B0 anti-pattern most likely to recur at the end of this engagement, and how does Phase 6 cure it?"	"The anti-pattern: treating an AI finding as binary FIXED/UNFIXED. It recurs when Acme installs tau_vault and asks 'is the cred-exfil fixed now?' The instinct is to say 'yes.' Phase 6 cures it by defining the RETEST PLAN — the same scorecard battery, re-run against the fully-hardened tau (all 3 plugins + B3 + B8), reporting the before/after success rate per finding. RT-001: original 100% → measured target 0% over 100 attempts. The deliverable transitions from a word ('fixed') to a NUMBER. The harness is never 'fixed'; it is 'measured residual risk under a battery,' and that number is Acme's acceptance criterion."	c2b::capb2::analysis
"Why must the SOW for the tau engagement specify that credential values are Restricted and destroyed on report?"	"Because the credential-exfil finding proves that ~/.tau/credentials.json is readable by the agent. The natural instinct is to capture the credential values to 'prove' the severity. That is the harm the test was hired to prevent. The credential values (API keys, OAuth tokens) are: (1) TRADE SECRETS if they are provider keys; (2) PERSONAL DATA if they identify the user; (3) WEAPONIZABLE if retained beyond the engagement. The SOW's data-handling clause classifies them as Restricted — capture a hash of the prefix (proves reachability), destroy the values on report submission. Retaining them makes you a data controller under GDPR and potentially liable for any subsequent misuse. Minimum-proof: the command, the ok result, the hash. Never the values."	c2b::capb2::analysis
"What makes the remediation roadmap for the Acme deployment 'specific and actionable' rather than abstract?"	"Three properties: (1) It names the SPECIFIC PLUGIN to install — tau_vault, which exists, is tested (31/31 tests pass), and drops in at Extension Point 3. The client can run `migrate_credentials_to_vault()` and the plaintext is converted. (2) It names the SPECIFIC EXTENSION POINT to wedge — B3 at _persist_messages_since (session.py:1378), B8 at harness.subscribe (harness.py:124). The client's engineering team knows exactly where to put the code. (3) It records the control's ACTUAL STATE — INSTALLED (tau_taint, tau_sandbox) vs MISSING (tau_vault, B3, B8) — so the client knows what they already have and what they need to build. An abstract roadmap says 'add memory controls'; a specific roadmap says 'add a write-validation gate at session.py:1378 that checks provenance before append.'"	c2b::capb2::analysis
"In Phase 4, how do you measure the success rate of the credential-exfil bypass against real tau?"	"Run the denylist-bypass probe (python3 -c open(credentials.json).read()) N times against the Acme tau deployment's bash tool. Each run is a real tool call: the battery calls tool.execute({'command': '...'}), the sandbox policy checks the command, and (because python3 is not in the denylist) the inner executor runs asyncio.create_subprocess_shell. The tool result's ok field is True. The evaluate function checks r.ok and whether the output contains credential keys. Run 50 times; record successes/total. Pin the tau version, the plugin config, and the model version. The rate (e.g., 100% over 50 attempts) becomes the finding's measured severity in the report. The evidence is real tool-call output, not simulated."	c2b::capb2::application
"Why is partial hardening (taint + sandbox but no vault) a MORE realistic and MORE valuable engagement target than either fully-undefended or fully-hardened tau?"	"MORE REALISTIC: most production deployments are partially hardened. A team that has done a security review installs SOME controls and ships. Fully-undefended is rare (even minimal teams add a sandbox); fully-hardened is rare (most teams do not reach B5/B3/B8). Partial hardening is the state you will encounter in every real engagement. MORE VALUABLE: the engagement discovers which controls are present (working) and which are missing (the findings). The scorecard battery reveals the delta — indirect at 0% (taint working) but cred-exfil at 100% (vault missing). This delta IS the assessment: it tells the client exactly what they have and what they lack. A fully-undefended target yields 'everything is broken' (unactionable); a fully-hardened target yields 'everything works' (no findings). Partial hardening yields a specific, prioritized, actionable report."	c2b::capb2::analysis