"What is the ~50% InjecAgent finding, and what is it NOT?"	"It IS a population BASELINE for un-defended agentic harnesses with no injection defenses — roughly half of agentic tasks fail when a tool output is adversarial. It is NOT a constant of nature, NOT your defended harness's expected rate, and NOT a target to 'get under.' A harness scoring 50% has MEASURED a vulnerability; it has not MANAGED one. The managed version is the defended delta (before/after)."	c2b::sdd-b03::recall
"Distinguish the attack vector InjecAgent measures from direct prompt injection."	"DIRECT injection lives in the user's prompt ('ignore previous instructions') — largely CLOSED in serious harnesses by input sanitization + system-prompt primacy. INDIRECT injection (what InjecAgent measures) lives in DATA the agent reads, dominated by TOOL OUTPUTS — a fetched page, a file comment, a DB row engineered to steer the agent. The agent CANNOT structurally distinguish tool output (data) from instruction (policy) because both arrive as text in the context window."	c2b::sdd-b03::recall
"Name the four roles InjecAgent plays across the two courses, with each role's unit of analysis."	"(1) QUALITY GATE (2A): 'Is my harness injectable?' unit = per-tool score. (2) MEASUREMENT INSTRUMENT (2B): 'Did this defense hold, and by how much?' unit = before/after delta. (3) REGRESSION GATE (both): 'Did this change open a surface?' unit = pass/fail at merge. (4) ENGAGEMENT SCOPER (B12): 'Which chains do I run?' unit = transcript → chain finding. Same code; different question, lens, authorization."	c2b::sdd-b03::recall
"What is the defense-effectiveness delta, and why is it the only honest effectiveness metric?"	"It is the (before, after, configuration) TRIPLE: baseline rate with defenses off, defended rate with defenses on, same task set + pinned model version + same sampling. The delta is the effectiveness claim. 'We added an egress gate and we're at 9%' is NOT a claim without the baseline. If the baseline was 14%, the gate did little; if 48%, it did a lot. NO TRIPLE, NO CLAIM. The config makes the triple reproducible."	c2b::sdd-b03::recall
"Why is reporting a defended number without its baseline an anti-pattern?"	"A 9% defended rate is MEANINGLESS without the pre-defense number. If the baseline was 14%, the defense did almost nothing and 9% is just baseline variance. If the baseline was 50%, the defense is doing serious work. You CANNOT tell from the defended number alone. Cure: every effectiveness claim is a (before, after, configuration) triple — model version, sampling, defense settings pinned so the triple is reproducible."	c2b::sdd-b03::recall
"State the five attack types in the InjecAgent taxonomy and the defense each maps to."	"(1) CREDENTIAL EXFIL → deterministic egress gate + credential quarantine (IronCurtain DD-20). (2) DISALLOWED-TOOL CALL → tool-call policy enforcement + dispatch unique-resolution. (3) SCOPE ESCAPE → scope gate re-checked per action + valid_until enforcement. (4) POLICY OVERRIDE → explicit instruction hierarchy + goal-reaffirmation checkpoints. (5) ACTION REDIRECTION → session-level intent detection (the SDD-B02 control). Different attack types need different defenses — the taxonomy is the prescription."	c2b::sdd-b03::recall
"Why is the attack-type taxonomy mandatory in 2B when it was only a build-on in 2A?"	"In 2A the per-tool score ('web-fetch is 80% injectable') was enough to know WHERE to defend. In 2B a B12 engagement PRESCRIBES defenses, not headlines. A tool failing 60% on credential-exfil needs a deterministic egress gate; one failing 60% on action-redirection needs session-level intent detection. The taxonomy turns a score into a defense prescription — it is the section of the engagement report that says 'here is what is broken, here is the attack type, here is the defense, here is the expected delta.'"	c2b::sdd-b03::recall
"What are the three routine changes that open injection surfaces, caught by the regression gate?"	"(1) NEW TOOL ADDED — a new injection point; did the team wrap its output in the structured-output layer / add it to the egress allowlist? (2) PROMPT EDITED — a wording change can weaken injection resistance (softer scope assertion, more permissive instruction hierarchy); the author won't notice. (3) MODEL SWAPPED — a new model may parse tool outputs more naively; silent provider updates are the worst case. The gate re-runs the benchmark and compares to threshold at every merge."	c2b::sdd-b03::recall
"Why is a measured-but-not-gated injection threshold a documented vulnerability rather than a managed one?"	"A threshold that is measured but not enforced by the gate erodes the moment a deadline arrives — the team raises it 'just this once' and the injection surface reopens silently. The gate turns a measurement into a CONTROL: binary at merge (below threshold = allow, above = block until fixed OR threshold consciously raised with sign-off). Threshold = policy choice (5%? 10%?); ENFORCEMENT = mechanical (the gate runs every merge)."	c2b::sdd-b03::recall
"How is an InjecAgent failure transcript read as a cross-row chain finding?"	"Read through the SDD-B01 (OWASP) lens: the injected tool output = ASI07 (insecure output handling); the agent following it = ASI01 (goal hijacking); the off-task action = ASI05 (tool abuse) or ASI03 (excessive agency). Through SDD-B02: if the off-task action was a compound passing per-step approval individually = ZERO-CLICK HITL BYPASS chain. The benchmark produces raw chain material; the taxonomy produces the finding. B12 ROUTES: credential-exfil → CrabTrap/IronCurtain; action-redirect → Microsoft chains; scope-escape → OWASP ASI03/05."	c2b::sdd-b03::analysis
"Explain why indirect injection via tool outputs is the right surface to measure, vs direct injection."	"Direct injection is largely SOLVED at the harness layer (input sanitization, system-prompt primacy). Indirect via tool outputs is UNSOLVED and STRUCTURAL: the agent MUST read tool outputs to function, so there is no 'just refuse attacker data' option — the attacker's data is indistinguishable from the legitimate data the agent was built to read. A defense that holds under direct injection but folds under indirect injection via tool outputs holds on the test and FAILS in production. The benchmark is the production-realism filter."	c2b::sdd-b03::analysis
"Why do the deterministic defenses produce larger deltas than probabilistic ones under InjecAgent?"	"DETERMINISTIC defenses (structured tool outputs, deterministic egress gates, scope enforcement) deny the injection a place to live and a path out — they move the needle from ~50% toward single digits. PROBABILISTIC defenses (CrabTrap's LLM-as-judge, a sanitization model) produce smaller deltas AND carry their own attack surface (the judge is itself a model, so it is itself injectable — cf SDD-B04). They catch novel patterns the deterministic rules don't enumerate but are the SECOND line, not the first. Defense-in-depth is measurable: deterministic-first harnesses sit well below the baseline; probabilistic-only harnesses sit near it."	c2b::sdd-b03::analysis
"What three variables must be pinned to make an InjecAgent delta reproducible, and why?"	"(1) MODEL VERSION — providers ship silent updates; a finding may not reproduce on the next version. (2) SAMPLING PARAMETERS — jailbreak/injection success is often sampling-dependent (a result at temp 1.0 may not reproduce at temp 0). (3) DEFENSE CONFIGURATION/settings — the exact defenses in force. The delta is only valid if EVERYTHING is constant except the defense under test. A defended number at temp 0.2 against a different model than the baseline is NOISE, not a delta."	c2b::sdd-b03::analysis
"How does InjecAgent scope a B12 engagement faster than jumping to the taxonomies?"	"Run InjecAgent (under authorization per B0), read the per-tool per-attack-type scorecard. The HIGH-SCORE tools are the entry points; the HIGH-SCORE attack types are the chains to construct; the transcripts are the chain recon. From there the engagement branches: credential-exfil → CrabTrap/IronCurtain attacks (SDD-B04/05); action-redirect → Microsoft zero-click chain recon (SDD-B02); scope-escape → OWASP ASI03/05 procedures (SDD-B01). Skipping the benchmark pass = scoping BLIND; you waste time on surfaces the benchmark would deprioritize in minutes."	c2b::sdd-b03::analysis
"A vendor claims 'our product blocks prompt injection.' What evidence do you demand, and in what form?"	"An InjecAgent (or equivalent) (before, after, configuration) TRIPLE: the baseline rate without their product, the defended rate with it, on the SAME task set, SAME pinned model version, SAME sampling — plus the failure transcripts for review. 'Blocks prompt injection' without a measured delta against a named benchmark is a claim with no evidence. If they report only the defended number, the baseline is unknown and the claim is unfalsifiable. Demand the triple and the transcripts."	c2b::sdd-b03::analysis
"State the three measurement-discipline rules carried forward from B0 and made operational in SDD-B03."	"(1) Every defense claim is a (before, after, configuration) triple — no triple, no claim. (2) Every transcript is a SENSITIVE ARTIFACT — an attack roadmap; classify at capture time (Restricted if it contains retrieved data; Destroy-on-Report if it contains working injection recipes); the evidence store enforces the class at capture. (3) Every threshold is a POLICY, enforced by the GATE — a measured-but-not-gated threshold is a documented vulnerability, not a managed one."	c2b::sdd-b03::analysis
"How does SDD-B03 differ from its predecessor SDD-12 (Course 2A), given the benchmark code is identical?"	"The CODE is identical. The DIFFERENCE is role: SDD-12 read InjecAgent as a QUALITY GATE (builder's lens — 'is my harness injectable?', unit = per-tool score, the number is the deliverable). SDD-B03 reads it as a MEASUREMENT INSTRUMENT (red-team's lens — 'did this defense hold and by how much?', unit = before/after delta, the triple is the finding). The stance, authorization (B0), transcript handling, and unit of analysis (chain, not tool) all change. Same benchmark, opposite side of the bridge."	c2b::sdd-b03::analysis
"Why is InjecAgent described as 'the measurement layer for B2's injection defenses'?"	"B2 builds injection defenses (structured outputs, deterministic egress, scope gates, injection-detection models). Every one of them needs an effectiveness measurement — otherwise 'we added a defense' is an opinion. InjecAgent provides the (before, after, configuration) triple that turns each defense into an evidence-backed claim. When SDD-B04 breaks CrabTrap's judge and SDD-B05 breaks IronCurtain's compilation, this benchmark is what says the defense held at X% before the attack and Y% after. It is the instrument, not the defense."	c2b::sdd-b03::analysis
"What makes indirect injection via tool outputs structurally unsolvable at the model level, and where must the defense live?"	"The agent CANNOT structurally distinguish tool output (data) from instruction (policy) because both arrive as TEXT in the context window — there is no reliable marker the model can use to separate them (any marker can be forged by the injection). So the defense CANNOT be 'make the model smarter.' It must be ARCHITECTURAL: treat tool outputs as untrusted data (wrap in a structured layer), enforce structure on outputs (schema'd, not free text), and gate egress deterministically. The defense lives in the HARNESS, not the model."	c2b::sdd-b03::analysis