{ "module": "B11 — Governance and Compliance", "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": "What is the governance gap that Module B11 exists to close?", "options": [ "There are no technical controls for AI agents, so governance must substitute for them.", "Technical security (B2–B8) is necessary but not sufficient for enterprise adoption. CISOs, governance councils, and boards release budget and approval against frameworks (NIST AI RMF, ISO 42001, EU AI Act), not against a working guardrail. An agent with strong controls but no AI BOM/audit trail/policy-as-code layer will not clear enterprise governance — and one with weaker controls but a complete governance stack will ship first.", "Governance frameworks have replaced technical security as the primary defense for AI agents.", "The governance gap is purely a legal problem with no engineering component." ], "answer_index": 1, "rationale": "This is the module's central thesis. Technical security wins the engineering review; governance wins the enterprise review — they are not the same activity. The budget and board attention follow the governance layer (the AI BOM, audit trail, and RMF mapping). B11 teaches the second activity because an agent that passes engineering but fails governance does not ship." }, { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "Name the four core functions of the NIST AI RMF (AI 100-1).", "options": [ "Identify, Protect, Detect, Respond (the NIST CSF functions).", "Govern, Map, Measure, Manage — operating as a continuous loop, not a linear pipeline.", "Plan, Do, Check, Act (the Deming cycle).", "Assess, Authorize, Monitor, Remediate." ], "answer_index": 1, "rationale": "The NIST AI RMF's four core functions are Govern (culture, policy, accountability — the foundation), Map (context, use, risk surface), Measure (test, evaluate, verify), and Manage (mitigate, respond, remediate). They form a continuous loop: Govern sits underneath as the foundation; Map→Measure→Manage operate on top; residual risk exceeding tolerance goes back to Map (re-scope) or Govern (re-policy)." }, { "id": "Q03", "bloom": "recall", "type": "multiple_choice", "prompt": "What is an AI BOM (AI Bill of Materials), and what distinguishes it from a traditional SBOM?", "options": [ "It is identical to an SBOM; the name changed for marketing reasons.", "It is the SBOM concept extended to AI — an inventory of the model, training data sources, tools/MCP servers, dependencies, config, and external services. A traditional SBOM lists software packages but misses the model version, training data provenance, and MCP tools — exactly the components an AI attacker targets.", "It is only the model card, containing model metadata.", "It is a legal contract between model provider and deployer." ], "answer_index": 1, "rationale": "The AI BOM extends the SBOM with six component classes: 3 AI-specific (model with provider/checkpoint/license, training data with sources/provenance/PII status, system prompt & config with versions/hashes) and 3 SBOM-surface (tools/MCP servers, frameworks/SDKs, external services). An SBOM that misses the model version cannot resolve model-version disputes; one that misses the tools cannot trace a malicious MCP server. An agent without an AI BOM cannot be audited." }, { "id": "Q04", "bloom": "application", "type": "multiple_choice", "prompt": "An agent has a 4% prompt-injection success rate, no AI BOM, and no audit trail. An enterprise governance review is scheduled. What is the likely outcome, and why?", "options": [ "It passes easily — the 4% rate is strong technical evidence of security.", "It fails or is blocked. A governance review is not a re-test of technical controls; it requests EVIDENCE that controls map to the RMF functions and that the mapping is documented. Without an AI BOM the supply chain is invisible; without an audit trail the controls cannot be evidenced as ENFORCED (only as documented). An agent with weaker controls but a complete governance stack would ship first.", "It passes if the engineering team writes a memo explaining the 4% rate.", "It passes conditionally, pending a re-test in 90 days." ], "answer_index": 1, "rationale": "This is the governance gap in action. A working guardrail (the 4% rate) is a Measure output, but a governance review also needs Govern (policy, named owner), Map (AI BOM), and Manage (audit trail evidencing enforcement). The budget and board attention follow the governance layer. An agent that clears governance with weaker controls ships first — this is why B11 exists." }, { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "Map the Course 2B technical controls to the NIST AI RMF. Which mapping is correct?", "options": [ "Govern = B2 injection defense; Map = B3 tools; Measure = B8 observability; Manage = B9 OWASP.", "Govern → policy-as-code layer (B11.3) and scope file/provider_authorization (B0); Map → threat model (B1) and AI BOM (B11.2); Measure → injection success rates (B2), OWASP scores (B9), Microsoft taxonomy findings (B10); Manage → tool governance (B3), sandbox (B6), observability (B8), incident response (B0).", "Govern = B0 legal; Map = B1 threat model; Measure = B10 Microsoft; Manage = B12 assessment.", "All four functions map to B8 observability." ], "answer_index": 1, "rationale": "Govern (who owns the risk, what policy applies) is answered by the policy-as-code layer and the scope file's provider_authorization field. Map (what is the system, what can go wrong) is answered by the threat model and the AI BOM. Measure (have we tested, residual risk) is answered by the measured injection rates, OWASP scores, and taxonomy findings. Manage (controls deployed, response) is answered by tool governance, sandboxing, observability, and incident response. This table is the bridge between technical controls and the framework." }, { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "A client's governance policy states: 'No agent may access production data without human approval; high-risk tool calls require a second reviewer.' You must implement this as policy-as-code. Which design is correct?", "options": [ "Add the policy text to the agent's system prompt and rely on the model to follow it.", "Compile it to two PolicyRules enforced in the harness execution path: P-001 matches (surface == 'production_data') and returns ESCALATE; P-002 matches (risk_tier == 'high') and returns ESCALATE. The engine sits OUTSIDE the agent process (governance beneath the agent, DD-09), uses default-deny for unmatched actions, and emits an audit entry for every evaluation.", "Implement it as a tool the agent calls before risky actions, named check_policy.", "Store the policy in a wiki and require engineers to review it during code review." ], "answer_index": 1, "rationale": "Policy-as-code requires: (1) compilation to deterministic rules (DD-20 IronCurtain — the LLM is build-time, enforcement is if/then at runtime); (2) enforcement in the harness execution path, NOT the agent process (DD-09 NemoClaw — the agent cannot reach the engine to disable it); (3) default-deny for unmatched actions; (4) audit entry on every evaluation. Options A, C, and D all place enforcement within the agent's reach (prompt, tool, or wiki) — a prompt injection can bypass or disable all three." }, { "id": "Q07", "bloom": "application", "type": "multiple_choice", "prompt": "You are auditing an agent's evidence store. The 'audit trail' is the same log file the engineering observability dashboard uses, sampled at 1% of events for performance. Will this satisfy a compliance review under the EU AI Act (Article 12) or HIPAA (§ 164.312(b))?", "options": [ "Yes — any logging satisfies the requirement.", "No. Both Article 12 and the HIPAA audit-control standard require logs that EXIST, are COMPLETE (not sampled), and are RETAINED for a defined period. A 1%-sampled observability log is useful for engineering and useless for compliance. The audit trail must be a separate, complete, append-only, tamper-evident system. Observability (B8, sampled) and audit (B11.2, complete) are different systems serving different audiences.", "Yes, if the sampling is statistically significant.", "Only if the 1% sample includes all error events." ], "answer_index": 1, "rationale": "The distinction between observability (B8) and audit trail (B11.2) is load-bearing. Observability is an engineering capability for diagnosis (sampling is acceptable). The audit trail is compliance EVIDENCE proving controls are enforced — it must be complete, append-only, and retained. A regulator reconstructing an incident needs the full record of decisions, tool calls, approvals, model versions, and policy evaluations; a 1% sample cannot reconstruct what the agent did. EU AI Act Art 12 and HIPAA both require completeness." }, { "id": "Q08", "bloom": "application", "type": "multiple_choice", "prompt": "A startup maintains its AI BOM in a Confluence wiki page. The engineering team adds a new MCP server and forgets to update the wiki. What is the governance consequence, and what is the fix?", "options": [ "No consequence — the wiki is sufficient if it is mostly accurate.", "The AI BOM has drifted from reality: the agent now depends on an MCP server invisible to the auditor (and to B4 supply-chain response and B10 capability-disclosure recon). A vulnerability in that server cannot be traced to this agent. The fix: GENERATE the AI BOM from the running system (read the tool list from the harness registry, model version from the API, deps from SBOM tooling) — the generator, not the wiki, is the source of truth. A wiki and reality drift; the auditor reads reality.", "The fix is to add a weekly reminder to update the wiki.", "The fix is to require two engineers to sign off on wiki edits." ], "answer_index": 1, "rationale": "An AI BOM maintained by hand drifts the moment a dependency is updated or a tool is added. The wiki is a derivative; the running system is the source of truth. The generator reads model version, tool registry, dependencies, config, and external services from the actual deployment and emits machine-readable JSON. This is why the B11 lab builds a generator, not a template." }, { "id": "Q09", "bloom": "application", "type": "multiple_choice", "prompt": "Why should a policy engine use default-deny (an action no rule matches is DENIED) rather than default-allow?", "options": [ "Default-allow is more user-friendly and should be preferred.", "Default-deny ensures the failure mode of a missing policy is SAFETY, not openness. With default-allow, a missing rule becomes a permission — an attacker who finds an action class no policy covers gets it for free. Default-deny blocks unmatched actions AND emits an audit entry ('no policy matched; default-deny'), surfacing the gap so a rule gets added. The loop closes because the gap is observable.", "Default-deny is required by law under the EU AI Act.", "Default-allow and default-deny are equivalent; the choice is stylistic." ], "answer_index": 1, "rationale": "Default-deny is the safety-preserving design. The failure mode of a missing policy is that the action is blocked (safe) and logged (visible), prompting a rule addition. Default-allow's failure mode is that the action proceeds (unsafe) silently (invisible). The audit entry for the default-deny case is itself valuable evidence — it makes the governance system self-improving by surfacing uncovered action classes." }, { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "Contrast DD-20 IronCurtain and DD-09 NemoClaw as policy-as-code references. What does each contribute, and why are both needed?", "options": [ "They are competing products; choose one based on language preference.", "IronCurtain contributes DETERMINISTIC POLICY COMPILATION: plain-English constitution.md → offline LLM compiles → deterministic JSON rules → zero LLM at runtime (enforcement is pure if/then). NemoClaw contributes ARCHITECTURAL PLACEMENT: governance BENEATH the agent — enforcement in the harness execution path where the agent cannot reach it. Both are needed: IronCurtain makes the policy machine-certain; NemoClaw makes the enforcement survive agent compromise. Policy-as-code inside the agent process is policy-as-code a prompt injection turns off.", "IronCurtain provides the LLM judge at runtime; NemoClaw provides the sandbox.", "Both are sandboxing tools unrelated to policy-as-code." ], "answer_index": 1, "rationale": "The two references address different halves of the problem. IronCurtain (DD-20) solves HOW policy is expressed and enforced — human-readable policy compiled to deterministic rules, with the LLM used only at build time so runtime enforcement is certain. NemoClaw (DD-09) solves WHERE enforcement lives — in the execution path between agent and world, not inside the agent process, so a compromised agent cannot disable it. The synthesis (B11.3): plain-English policy (Govern), compiled deterministically (IronCurtain), enforced beneath the agent (NemoClaw), with an audit entry per evaluation." }, { "id": "Q11", "bloom": "analysis", "type": "multiple_choice", "prompt": "An enterprise must satisfy ISO/IEC 42001, the NIST AI RMF, the EU AI Act, and HIPAA for its healthcare AI agent. Is this four separate governance efforts, or one coherent program? Justify.", "options": [ "Four entirely separate efforts with no overlap — staff four teams.", "Largely one coherent program. The RMF is the default framework to map to; ISO 42001 is the certifiable standard INTEROPERABLE with the RMF (an RMF-aligned program is most of the way to 42001); the EU AI Act's engineering requirements (Annex IV documentation ≈ AI BOM, Art 12 logging ≈ audit trail, Art 14 oversight ≈ HITL control) are 'the RMF made mandatory'; HIPAA is a sector rule layered on top (the audit trail must also satisfy § 164.312(b)). The AI BOM and audit trail (B11.2) are the two artifacts ALL of them ask for first.", "Only the EU AI Act matters; the others are optional.", "Only HIPAA matters in healthcare; ignore the AI-specific frameworks." ], "answer_index": 1, "rationale": "The frameworks interoperate. The RMF is voluntary but the de facto US standard. 42001 is the certifiable version, designed to interoperate with the RMF. The EU AI Act's engineering requirements map onto RMF artifacts (Annex IV ≈ AI BOM + risk assessment; Art 12 ≈ audit trail; Art 14 ≈ HITL). Sector frameworks (HIPAA, FedRAMP, SOX) layer on top. Building the AI BOM and the audit trail (B11.2) plus the RMF mapping satisfies the common core; sector rules add specific requirements. This is why B11 leads with the AI BOM and audit trail as the two universal artifacts." }, { "id": "Q12", "bloom": "analysis", "type": "multiple_choice", "prompt": "A red-team discovers that an agent's policy engine was implemented as a system-prompt instruction ('Always ask for approval before production data access') rather than as an interceptor in the execution path. What is the vulnerability, and what is the required architectural fix?", "options": [ "No vulnerability — system-prompt instructions are reliable enforcement.", "The enforcement is INSIDE THE AGENT'S REACH. A prompt injection can override, ignore, or manipulate the instruction — the agent follows its context, and the context is attacker-controllable. The fix (DD-09 NemoClaw): move enforcement to the harness execution path — an interceptor every tool call and model call passes through, BETWEEN agent and world, where the agent cannot reach it. The agent proposes actions; the engine evaluates them before execution; the agent never sees the engine's internals. Combine with DD-20 IronCurtain deterministic compilation so enforcement is if/then, not LLM judgment.", "The fix is to make the system prompt longer and more emphatic.", "The fix is to add a second system-prompt instruction reinforcing the first." ], "answer_index": 1, "rationale": "This is the governance-beneath-the-agent principle (DD-09). Enforcement inside the agent's reach (system prompt, agent-callable tool) is enforcement a compromise disables. The architectural fix is placement: the policy engine must sit in the execution path where the agent cannot reach it. Combined with IronCurtain's deterministic compilation (so the LLM is build-time only, not a runtime judge), this yields enforcement that is both machine-certain and tamper-resistant. The agent's compliance is not the control layer; the harness's enforcement is." }, { "id": "Q13", "bloom": "analysis", "type": "multiple_choice", "prompt": "Distinguish 'governance theater' from real NIST AI RMF mapping. What single test separates them?", "options": [ "Whether the mapping document is over 50 pages long.", "Whether the mapping is EVIDENCE-BACKED. Governance theater is a spreadsheet mapping controls to Govern/Map/Measure/Manage with no underlying artifacts — a Map claim with no AI BOM, a Measure claim with no test result, a Manage claim with no audit-trail entry. Real mapping points to ARTIFACTS: every Map claim references a generated AI BOM; every Measure claim references a measured success rate over N (not an assertion); every Manage claim references a logged policy evaluation with a timestamp and model version. The test: does each mapping cell point to an artifact a regulator could read, or to a claim?", "Whether the organization has hired a Big Four consulting firm.", "Whether the RMF is mentioned in the annual report." ], "answer_index": 1, "rationale": "The distinction is artifacts vs. claims. A spreadsheet that says 'we cover Measure via our red-teaming' without a measured residual risk (a success rate over N, an OWASP score) is a claim. One that references 'InjecAgent run 2026-06-15: 4% injection success over 500 attempts against claude-opus-4-1-20260605, logged in audit trail entries AT-7841–AT-8340' is an artifact. Auditors read artifacts. This is why the AI BOM (generated, not wiki) and the audit trail (complete, not sampled) are the load-bearing artifacts — they convert claims into evidence." }, { "id": "Q14", "bloom": "analysis", "type": "multiple_choice", "prompt": "Design the audit-trail store for tamper-evidence and compliance. Which set of properties is required?", "options": [ "Mutable (so errors can be corrected), sampled (for performance), and retained for 30 days.", "Append-only (no entry modified or deleted once written); hash-chained (each entry includes a hash of the previous, so tampering breaks the chain); complete (every event class logged for every action, not sampled); retained per policy (a defined period — e.g., 6 years for HIPAA); and separate from the observability system (B8 sampled for engineering; this store complete for compliance). A tamper-evident, complete, retained trail is what EU AI Act Art 12 and HIPAA § 164.312(b) require.", "Stored in the same log file as application logs for convenience.", "Encrypted at rest but with no integrity protection." ], "answer_index": 1, "rationale": "The required properties: append-only (an audit trail you can edit is not an audit trail — it is a draft); hash-chained or Merkle-structured (tamper-evidence: a break in the chain is detectable); complete (sampled logs cannot reconstruct an incident); retained per policy (retention is itself a compliance requirement, and destruction is logged); and separated from observability (which serves engineering, may sample, and has different retention). The lab builds a hash-chained append-only writer implementing these properties." }, { "id": "Q15", "bloom": "analysis", "type": "multiple_choice", "prompt": "Construct the full governance-to-engineering bridge for a policy: 'No agent may call an external email API without a logged, time-stamped human approval valid for 10 minutes.' Specify the four lifecycle stages and where each artifact lives.", "options": [ "Write the policy in a wiki; engineers read it; the model follows it; nothing is logged.", "(1) POLICY (Govern, wiki/constitution): the policy text, owned by the AI governance lead. (2) CONTROL (B11.3, harness execution path): a PolicyRule matching (tool == 'send_email' AND surface == 'external_api') returning ESCALATE, plus an approval-state check (approval.approver != None AND now - approval.timestamp < 600s). (3) TEST (Measure, B9/B10): propose send_email without approval → assert DENY; with 9-min-old approval → assert ALLOW; with 11-min-old approval → assert DENY (freshness window). (4) AUDIT (Manage, B11.2): every evaluation emits {policy_id, action, decision, reason, approver_id, approval_age_seconds, timestamp, model_version} to the append-only, hash-chained trail. The engine is beneath the agent (DD-09); the rule is deterministic (DD-20).", "Put the policy in the system prompt and hope the agent complies.", "Have the CISO approve each email manually, with no code." ], "answer_index": 1, "rationale": "This is the complete bridge: policy (Govern) → control (compiled rule with approval-state and freshness check) → test (three cases covering no-approval, valid-window, and expired-window) → audit (entry capturing the decision AND the approval metadata). Note the freshness window (10 min) is enforced in the control, tested explicitly, and evidenced in the audit entry (approval_age_seconds). The engine sits in the execution path (NemoClaw) and the rule is deterministic if/then (IronCurtain). Every stage produces an artifact; the loop is operable." } ] }