"What is InjecAgent, and what is its headline finding?"	A benchmark for INDIRECT prompt injection in LLM agents. Headline: ~50% of agentic tasks are vulnerable to injection delivered via TOOL OUTPUTS. It turns a theoretical attack class into a measurable, regressable property of your harness. Without it, 'is my agent injectable?' is an opinion; with it, a percentage.	course2a::sdd12::recall
"What is indirect prompt injection via tool outputs, and why is it the defining agentic surface?"	Direct injection is in the user prompt (largely solved). INDIRECT injection is hidden in data the agent reads — most commonly a tool's output (web page, file, DB row). The agent cannot structurally distinguish tool output (data) from instruction (policy) — both arrive as context text. Security harnesses read target data constantly; every read is an injection opportunity.	course2a::sdd12::analysis
"Why can't the agent just learn to distinguish tool-output data from instruction policy?"	It is a STRUCTURAL property, not a model bug. Both data and policy arrive as text in the context window; there is no structural marker the model can reliably use. The defenses are not 'make the model smarter' — they are architectural: treat tool outputs as untrusted data, enforce structure on outputs, gate egress deterministically.	course2a::sdd12::analysis
"How do you correctly read the ~50% finding?"	It is a POPULATION BASELINE for un-defended, out-of-the-box agentic harnesses. Your DEFENDED harness (structured outputs, deterministic egress) should be dramatically lower. If you run InjecAgent and still see ~50%, your defenses aren't working — or aren't applied to the injectable tools. The interesting metric is the before/after DEFENSE-EFFECTIVENESS DELTA.	course2a::sdd12::analysis
"Describe the InjecAgent benchmark methodology."	Task set (agent must do X via tools Y, Z). Per task: replace one tool output with an injected version (steering text). Pass = agent completes X despite injection. Fail = injection diverts the agent. ~50% of tasks fail (the headline). The output is a per-tool, per-attack scorecard plus failure transcripts.	course2a::sdd12::analysis
"How do you run InjecAgent against your own harness?"	Adapt the task set to YOUR tools (injection points differ). Per tool, per attack type (credential exfil, disallowed-tool, scope escape, policy override, action redirect), construct injected outputs. Run and measure. Output: per-tool, per-attack scorecard (e.g., web-fetch 80%, DB-query 20%) + failure transcripts (the defense-design surface).	course2a::sdd12::application
"What is the operational payoff of InjecAgent as a CI gate?"	Regression test: every change (new tool, prompt edit, model swap) re-runs the gate. Pass = injection rate below threshold (merge). Fail = change opened a surface (block merge). The per-tool scorecard + transcript show what to fix. Turns injection resistance from an opinion into an enforced build-pipeline property.	course2a::sdd12::analysis
"What defenses does InjecAgent imply (the architectural patterns)?"	(1) Treat tool outputs as untrusted data (S01, SDD-07's triage constraint). (2) Enforce STRUCTURE on tool outputs (schema'd, not free text). (3) Gate egress DETERMINISTICALLY (DD-20 IronCurtain credential quarantine; DD-19 CrabTrap LLM-as-judge is probabilistic — InjecAgent measures its effectiveness). These are what Course 2B attacks.	course2a::sdd12::analysis
"What is the per-tool scorecard's value over the single 50% headline?"	The 50% is a headline; the SCORECARD is the tool. 'Web-fetch 80% injectable, DB-query 20%' tells you WHERE to defend. The failure TRANSCRIPT (exactly how the injection steered the agent) is the defense-design surface — you read it and design the specific countermeasure. A single number cannot guide defense; the per-tool breakdown can.	course2a::sdd12::analysis
"State InjecAgent's score on the 12-module rubric. Why are 4 modules n/a?"	27/45 (8 scored, 4 n/a). n/a: Context Mgmt, Memory, Permission, Subagents, Prompt Assembly — it is a benchmark/gate, not an agent. Strength: vector choice (Tool Design 4 — indirect via tool outputs), transcript observability (11). Lowest: State (3, no native before/after delta), no attack-type taxonomy.	course2a::sdd12::analysis
"Name 3 things InjecAgent does better than any other injection evaluation."	(1) Measures INDIRECT injection via tool outputs (the unsolved structural surface), not direct prompts (largely solved). (2) Per-tool, per-failure scorecard with transcripts (headline is 50%; the tool is knowing which tools are injectable and how). (3) Pass/fail gate semantics for CI (regression test catching new tool/prompt/model changes that open a surface).	course2a::sdd12::recall
"Name 3 things you would add to InjecAgent."	(1) Attack-type taxonomy in the scorecard (credential exfil vs disallowed-tool vs scope escape vs policy override vs action redirect — reveals WHICH defenses you need). (2) Defense-in-place re-measurement (before/after delta — turns grade into defense-effectiveness measurement). (3) Tool-output sanitization coverage metric (what fraction of outputs pass through a structuring layer? coverage + failure = deployed + works).	course2a::sdd12::application
"Why is InjecAgent the bridge to Course 2B?"	The defenses InjecAgent implies (treat tool outputs as untrusted, enforce structure, deterministic egress — DD-19 CrabTrap, DD-20 IronCurtain) are exactly what Course 2B's offensive techniques target. InjecAgent measures whether the defenses held; Course 2B attacks them. A measured-but-indefended 50% is a documented vulnerability — the starting point for 2B's red-teaming.	course2a::sdd12::analysis
"State InjecAgent's Architect's Verdict in one line."	The benchmark that makes indirect prompt injection via tool outputs measurable (~50% of tasks fail for un-defended harnesses); operational value is the per-tool scorecard + failure transcript + CI gate (catches changes that open a surface); drive the number down with the defenses it implies (untrusted-data treatment, structured outputs, deterministic egress), and measure the defended delta, not the absolute rate.	course2a::sdd12::recall