{ "module": "B1 — Threat Model of Agentic Systems", "course": "2B — Securing & Attacking Harnesses and LLMs", "version": "1.0.0", "duration_minutes": 35, "total_questions": 15, "bloom_distribution": { "target": "20% recall / 40% application / 40% analysis-design", "actual": { "recall": 3, "application": 6, "analysis": 6 } }, "passing_score_percent": 70, "questions": [ { "id": "Q01", "bloom": "recall", "type": "multiple_choice", "prompt": "How many distinct attack surfaces does an agentic system expose, and what fraction of them are harness-layer vs model-layer?", "options": [ "Three surfaces, all model-layer.", "Seven surfaces: six are harness-layer (the 98.4%) and one — the provider — is model-layer (the 1.6%).", "Ten surfaces matching the OWASP ASI Top 10, all harness-layer.", "One surface — 'the agent' — which is entirely model-layer." ], "answer_index": 1, "rationale": "The seven surfaces are the loop, tools, memory, provider, identity, sandbox, and inter-agent edges. Six are harness-layer (98.4%); only the provider is model-layer (1.6%). This is why testing only the model (jailbreaks, leakage) covers 1.6% and leaves 98.4% exposed — the framing that recurs through the course." }, { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "What does STRIDE-for-agents add to the original Microsoft STRIDE framework, and why is the addition necessary?", "options": [ "It adds 'Repudiation' — which STRIDE originally lacked.", "It adds a seventh category, Goal Subversion, because an agent can be perfectly authenticated, untampered, and auditable yet still do the wrong thing because its objective was hijacked. This has no STRIDE analogue.", "It removes Elevation of Privilege as irrelevant to agents.", "It replaces all six categories with the OWASP ASI Top 10." ], "answer_index": 1, "rationale": "STRIDE was built for client-server systems. Agents introduce goal hijacking (ASI01): a compromised objective means the agent runs correctly toward the wrong goal. The agent is not spoofed, tampered, or escalated — its goal was subverted. Goal Subversion is the agent-specific seventh category, mapping to the loop and inter-agent edges. It gives defenders a per-surface checklist including this new failure mode." }, { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "What is the sleeper attack (memory poisoning, ASI04), and why does it defeat per-session detection?", "options": [ "A single prompt that crashes the agent's session, causing a denial of service.", "In session 1 the attacker injects a payload the agent persists to memory; in session 2 a different legitimate user retrieves and acts on the poisoned memory. The delay between write and activation crosses the session boundary, so the write looks benign in session 1 and the activation looks like normal retrieval in session 2.", "An attacker steals the agent's memory database in one query.", "The agent hallucinates a fact and persists it within a single turn." ], "answer_index": 1, "rationale": "The sleeper attack exploits memory persistence across sessions. The poison is written in session 1 (looks benign) and activated in session 2 (looks like normal retrieval). Per-session detection misses it because no single session contains both the malicious write and the harmful action. The defense is harness-managed writes, signed entries with provenance, retrieval-time untrusted-tagging, and TTL decay (B3)." }, { "id": "Q04", "bloom": "application", "type": "multiple_choice", "prompt": "You are reviewing an agent that calls fetch_url and inserts the return value directly into the context window with no tagging. Which surface and ASI risk does this expose, and what is the measured prevalence?", "options": [ "Surface 3 (memory), ASI04 — rare in practice.", "Surface 2 (tools), ASI01 indirect injection via tool output. The InjecAgent benchmark measured ~50% of agentic tasks vulnerable to exactly this. The untagged tool return value is attacker-controlled content the model treats as instruction.", "Surface 4 (provider), ASI02 — a leakage risk.", "Surface 6 (sandbox), ASI07 — an escape risk." ], "answer_index": 1, "rationale": "The tool output boundary (surface 2) is where return values flow into the context window. An untagged return from fetch_url is an indirect-injection vector — the most common and most dangerous vector per Course 1 Module 11. InjecAgent measured ~50% of agentic tasks vulnerable. The fix is output sanitization and untrusted-tagging on every tool return, plus MCP identity verification (B4)." }, { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "An agent's code-execution tool runs under a service account with a broad S3 read/write role because 'it was convenient to provision.' A prompt injection causes the agent to run code that lists and exfiltrates the bucket. Which two surfaces and ASI risks combined to make this a host/credential-scope-wide incident rather than a contained finding?", "options": [ "Surface 1 (loop) ASI01 alone — the injection is the sole cause.", "Surface 6 (sandbox, ASI07 escape) and surface 5 (identity, ASI03 excessive agency). Even if the sandbox held, the over-scoped S3 credential meant tool abuse (ASI05) reached the entire bucket. The excessive agency (ASI03) amplified a contained tool-abuse finding into a credential-scope-wide incident.", "Surface 4 (provider) ASI02 and surface 3 (memory) ASI04.", "Surface 7 (inter-agent edges) ASI06 alone." ], "answer_index": 1, "rationale": "Two surfaces failed. The code-execution tool needed a sandbox (surface 6) that confines agent-executed code; and the identity (surface 5) needed least-privilege scoping. The over-scoped S3 credential (ASI03 excessive agency) meant that even a contained tool-abuse (ASI05) reached the entire bucket. Excessive agency amplifies tool abuse: a scoped credential would have contained the exfiltration to non-sensitive paths. Defense: hardened sandbox (B7) AND least-privilege credentials (B5)." }, { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "Your agent mesh has a supervisor delegating to three workers via plain JSON messages over a shared queue, with no authentication. An attacker injects a message that appears to come from the supervisor instructing a worker to dump its credential store. Which surface, ASI risk, and blast radius apply?", "options": [ "Surface 1 (loop), ASI01, session-wide blast radius.", "Surface 7 (inter-agent edges), ASI08 (spoofing / supply-chain-style trust failure). Because messages are unauthenticated, the worker cannot verify the sender. Blast radius is mesh-wide — the forged supervisor message could redirect any worker, and a compromised worker's unverified output cascades to all peers (ASI06).", "Surface 3 (memory), ASI04, cross-session blast radius.", "Surface 2 (tools), ASI05, tool-scope-wide blast radius." ], "answer_index": 1, "rationale": "Inter-agent edges (surface 7) fail when messages are unauthenticated. The forged supervisor message is ASI08-adjacent spoofing (the Microsoft taxonomy calls this inter-agent trust escalation). The blast radius is mesh-wide — the worst case on the surface map — because implicit trust means a compromise propagates to all peers via cascade (ASI06). Defense: HMAC-signed messages per edge, replay protection, per-agent identity isolation, output verification at every edge (B6)." }, { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "A deployed agent sends its full retrieved context (which includes customer PII) to a shared provider API for inference. The provider logs all inputs and, on the default tier, may train on them. Which surface and which two risks apply?", "options": [ "Surface 2 (tools) only — it is a tool-output problem.", "Surface 4 (the provider). Risk 1: information disclosure (ASI02-adjacent) — customer PII is in a third-party log store the deployer does not control. Risk 2: test/production-data contamination — the deployer's data may end up in a future model if the provider trains on inputs. Defense: treat the provider as an untrusted boundary, DLP on outbound context, opt out of training, self-host for high-sensitivity.", "Surface 6 (sandbox) — the provider is a sandbox issue.", "Surface 5 (identity) — the provider is an identity issue." ], "answer_index": 1, "rationale": "The provider (surface 4) is a trust boundary because the model is a third party: opaque, shared, updated without deployer control, and its logs/training pipeline are provider-controlled. Sending PII in context puts it in a third-party log store (information disclosure). If the provider trains on inputs, the deployer's data contaminates a future model. B0 established the deployer cannot authorize what the provider controls; here the security dimension mirrors it — the deployer cannot secure what the provider controls. Defense: minimize outbound context, DLP, pin model version, self-host." }, { "id": "Q08", "bloom": "application", "type": "multiple_choice", "prompt": "You are prioritizing remediation across the seven surfaces of a deployed agent. Following the blast-radius principle from the module, which three surfaces should you fix FIRST and why?", "options": [ "The loop, tools, and memory — because they are the most commonly attacked.", "The provider, the loop, and tools — because they are the 1.6% / 98.4% split.", "The sandbox, identity, and inter-agent edges — because their worst case is containment failure (host-wide, credential-scope-wide, mesh-wide respectively). A contained compromise is a finding; an uncontained one is an incident. Prioritize containment-failure surfaces over single-session compromise (the loop).", "Memory, the provider, and the loop — in alphabetical order." ], "answer_index": 2, "rationale": "The blast-radius principle: prioritize surfaces whose worst case is containment failure. Sandbox escape reaches the host (host-wide). Excessive agency reaches everything the credential permits (credential-scope-wide). Inter-agent cascade reaches every node (mesh-wide). These are uncontained — an incident. The loop's worst case (session-wide, if halted) is contained — a finding. Fix the containment-failure surfaces first, then the single-session surfaces." }, { "id": "Q09", "bloom": "application", "type": "multiple_choice", "prompt": "Your agent retrieves a 'fact' from its long-term memory store and immediately acts on it as ground truth. The memory store was written by the agent itself in a prior session based on user input. What is the trust-boundary error and the correct posture?", "options": [ "No error — agent-written memory is trusted by definition.", "The error is treating retrieved memory as trusted fact when it may be attacker-authored (memory poisoning, ASI04). The correct posture: every retrieved byte is untrusted until tagged and verified. The harness must manage writes (agent proposes, harness decides what to persist — never let the model write raw memory), sign entries with provenance, tag retrieved content as untrusted data, and apply TTL/decay so poisoned entries do not live forever.", "The error is using long-term memory at all — all memory should be ephemeral.", "The error is a sandbox issue — memory should be sandboxed." ], "answer_index": 1, "rationale": "Retrieved memory may be attacker-authored (the user in session 1 was the attacker) or contaminated. Treating it as ground truth means the agent acts on poisoned data. The correct posture is the B3 defense: harness-managed writes (the model never writes raw memory), signed entries with provenance, retrieval-time untrusted-tagging (mark every retrieved fact as data, not instruction), and TTL/decay. Course 1 Module 4.3 (harness-managed writes) is the precursor." }, { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "CrabTrap (DD-19) is an LLM-as-judge egress filter on the tools surface. An attacker crafts a tool output that is obfuscated and split across two fetch_url calls, each reading as benign to the judge model, but combining into an injection once in the context window. Which two CrabTrap failure modes does this exploit simultaneously?", "options": [ "Compilation fidelity and V8 isolate escape.", "Escalation fatigue and resource exhaustion.", "(1) The judge is a model — probabilistic defense against probabilistic attack; the obfuscation defeats the judge's per-call classification. (2) The response-side gap — the inbound tool return value enters the context window unfiltered even if the outbound request was checked. The multi-step assembly exploits the per-call (not session-level) nature of the judge.", "Credential quarantine and identity spoofing." ], "answer_index": 2, "rationale": "CrabTrap's failures: the judge is a model (injection can fool it, especially with obfuscation/encoding), and the response-side gap (inbound returns historically unfiltered). The multi-step assembly additionally exploits that the judge runs per-call, not session-level — each fetch_url looks benign in isolation, the attack emerges from the sequence (the zero-click bypass chain pattern). This is why probabilistic egress filtering alone is insufficient — B2 adds instruction isolation and session-level intent tracking." }, { "id": "Q11", "bloom": "analysis", "type": "multiple_choice", "prompt": "IronCurtain (DD-20) compiles natural-language policies into deterministic rules using a build-time LLM, then enforces them deterministically. An attacker is able to influence the policy text during the build step, causing the compiled rule to permit an action the intended policy forbids. The deterministic enforcer then faithfully permits it. What does this illustrate about deterministic enforcement, and what is the lesson?", "options": [ "Deterministic enforcement is useless — replace it with a judge model.", "Compilation fidelity attack: determinism AMPLIFIES a poisoned compile. The enforcer is faithful to the compiled rule, but the compiled rule does not match the intended policy. The lesson: the compilation step is itself an attack surface (the build-time LLM consumes untrusted context), and a deterministic enforcer cannot detect that it is enforcing the wrong rule. The build pipeline needs the same trust-boundary discipline as the runtime.", "The policy text should never be in natural language — use only code.", "IronCurtain is immune because it is deterministic." ], "answer_index": 1, "rationale": "This is the compilation fidelity attack (SDD-B05). Determinism is a strength at runtime (no probabilistic bypass) but a weakness at compile time: if the compile is poisoned, the enforcer faithfully enforces the wrong rule and there is no probabilistic 'second opinion' to catch it. The build-time LLM consumes context (including possibly attacker-influenced policy text) and is itself an attack surface. The lesson: the compilation pipeline needs trust-boundary discipline — signed policy inputs, isolated build context, verification of compiled-against-intended rules." }, { "id": "Q12", "bloom": "analysis", "type": "multiple_choice", "prompt": "A multi-agent system uses ZeroClaw's (DD-16) HMAC tool receipts for inter-agent message authentication, but the signing keys are ephemeral (in-memory only, not persisted). Describe the specific gap this leaves and which attacks it fails to prevent.", "options": [ "No gap — ephemeral keys are more secure because they rotate constantly.", "The gap: messages signed in session 1 CANNOT be verified in session 2, and a restart invalidates the signing key. This fails to prevent (a) the sleeper attack (ASI04) where a poisoned message persisted to memory is retrieved in a later session and cannot be verified, and (b) replay across restarts. Durable, rotated signing keys (or asymmetric signatures for cross-domain trust) are needed. HMAC alone, with ephemeral keys, authenticates within a session but not across the boundaries where the sleeper and cascade attacks operate.", "The gap is that HMAC is the wrong algorithm — use AES instead.", "The gap is that ZeroClaw has no sandbox." ], "answer_index": 1, "rationale": "ZeroClaw's HMAC receipts are the right primitive but ephemeral keys are an open gap flagged in Course 1. Inter-agent edges (surface 7) need authentication that survives session boundaries because the sleeper attack (memory poisoning, ASI04) and cascade (ASI06) operate across sessions. Ephemeral keys authenticate within a session only. B6 must close this with durable, rotated keys (or asymmetric signatures for cross-domain trust), plus replay protection (nonces/timestamps) and per-agent identity isolation." }, { "id": "Q13", "bloom": "analysis", "type": "multiple_choice", "prompt": "An attacker floods an IronCurtain-protected agent's human-approval queue with 50 benign-looking high-impact action requests, then slips one malicious request into the middle. The human, fatigued, approves it to clear the backlog. Which Microsoft failure-mode taxonomy finding does this embody, and why does the per-step approval model fail here?", "options": [ "Resource exhaustion (ASI09) — the queue was flooded.", "The zero-click HITL bypass chain: a single external input triggers a multi-step chain where each individual step passes approval, but the compound intent is malicious. Per-step approvals fail because no single step is the attack — the attack is the sequence/trajectory. Escalation fatigue is the mechanism that gets the malicious step approved. The fix is session-level intent detection that evaluates the compound trajectory, not just each action.", "Goal hijacking (ASI01) — the agent's objective was rewritten.", "Sandbox escape (ASI07) — the approval queue was bypassed." ], "answer_index": 1, "rationale": "This is escalation fatigue enabling a zero-click HITL bypass chain — the Microsoft taxonomy's central finding. Per-step approvals evaluate each action in isolation; the attack is the compound trajectory. Escalation fatigue is the social-engineering mechanism that exploits the per-step model's weakness: flood the queue until the human stops evaluating carefully. The fix is session-level intent detection (evaluating the compound trajectory), not just per-step gates. This is why B8 (observability) and B6 (inter-agent trust) both address session-level intent." }, { "id": "Q14", "bloom": "analysis", "type": "multiple_choice", "prompt": "You are building the JSON threat model for a sample agent per the B1 lab. The agent has: a code-execution tool, a vector memory store with customer PII, an OpenAI model API, a service account with broad DB access, a Docker container sandbox, and two peer agents it exchanges plain-text messages with. Map each component to its surface and state the blast radius if that surface is compromised.", "options": [ "All components are 'the agent' — one surface, one blast radius.", "(1) Code-exec tool → surface 2 (tools), tool-scope-wide. (2) Vector store with PII → surface 3 (memory), cross-session/cross-user. (3) OpenAI API → surface 4 (provider), cross-tenant if shared. (4) Service account with broad DB access → surface 5 (identity), credential-scope-wide. (5) Docker sandbox → surface 6 (sandbox), host-wide. (6) Peer agents with plain-text messages → surface 7 (inter-agent edges), mesh-wide. The reasoning loop tying them together → surface 1, session-wide if halted.", "Only the OpenAI API is a surface; the rest are infrastructure.", "Only the Docker sandbox is a surface; the rest are config." ], "answer_index": 1, "rationale": "Each component maps to a distinct surface with a distinct blast radius. The value of the JSON threat model is making this explicit: the broad-DB-access service account (credential-scope-wide) and the plain-text peer messages (mesh-wide) are the highest-blast-radius components and should be prioritized for least-privilege scoping and message authentication respectively. Treating 'the agent' as one surface misses six of seven and cannot prioritize remediation." }, { "id": "Q15", "bloom": "analysis", "type": "multiple_choice", "prompt": "A defender says: 'We deployed CrabTrap on the tools surface and IronCurtain on the identity and sandbox surfaces. The agent is secured.' Using the seven-surface map, explain why this claim is false and what is still exposed.", "options": [ "The claim is correct — CrabTrap and IronCurtain cover everything.", "The claim is false. CrabTrap (tools/surface 2) and IronCurtain (identity/surface 5, sandbox/surface 6) cover three of seven surfaces. Still exposed: surface 1 (the loop — no instruction isolation or session-level intent tracking), surface 3 (memory — no harness-managed writes or retrieval tagging, so the sleeper attack is open), surface 4 (the provider — no DLP on outbound context, so PII/credentials may leak to provider logs), and surface 7 (inter-agent edges — no signed messages, so forged messages and cascade are open). Defense in depth requires all seven surfaces, each with its own control and red-team test.", "The claim is false because CrabTrap and IronCurtain are both probabilistic.", "The claim is false because IronCurtain covers everything CrabTrap does." ], "answer_index": 1, "rationale": "The seven-surface map's core lesson: a defense on one surface does not protect the others. CrabTrap (surface 2) and IronCurtain (surfaces 5, 6) cover three surfaces. The loop (surface 1), memory (surface 3), provider (surface 4), and inter-agent edges (surface 7) remain undefended — each with a canonical attack (goal hijacking, sleeper/ASI04, prompt leakage/ASI02, forged messages/ASI06) that the deployed defenses do not touch. This is the thesis of B2–B12: defense in depth across ALL seven surfaces, each with its own module, control, and red-team test." } ] }