Course: Course 2B — Securing & Attacking Harnesses and LLMs
Module: B11 — Governance and Compliance
Duration: ~35 minutes (spoken at ~140 wpm)
Format: Verbatim transcript with [SLIDE N] cues. Read aloud or use as speaker notes.
[SLIDE 1 — Title]
Welcome to Module B11. Governance and Compliance. You have spent nine modules building controls. You can attack and defend an agent at a level most teams cannot. None of that ships the agent. A CISO does not approve production deployment because a guardrail works. A board does not allocate next year's budget because a red-team found the right gaps. They approve, sign, and allocate against frameworks — NIST AI RMF, ISO 42001, the EU AI Act's conformity obligations — because those are the instruments their auditors, regulators, and insurers read. The working guardrail is necessary. The framework mapping is what makes it fundable, approvable, and defensible. This is the gap the Perplexity conversation flagged as a depth upgrade: technical security wins the engineering review; governance and compliance win the enterprise review. They are not the same activity. This module teaches you to build the second one.
[SLIDE 2 — The governance gap]
Here is the gap made concrete. An agent with a four-percent injection success rate and no AI BOM, no audit trail, and no policy-as-code layer will not clear an enterprise governance review. And here is the uncomfortable part — an agent that clears the review with weaker technical controls but a complete governance stack will ship first. The budget and the board attention follow the governance layer. The working control and the documented mapping are both required, and they are produced by different activities. This module is the second activity.
[SLIDE 3 — B11.1 The governance frameworks]
Sub-section one. The governance frameworks. NIST AI RMF is the center, and the landscape around it.
[SLIDE 4 — NIST AI RMF four core functions]
The NIST AI Risk Management Framework — AI 100-1, published January 2023. It is voluntary. It carries no penalties. And yet it has become the de facto US AI governance standard for exactly the reason this module exists: it is the framework CISOs, governance councils, and federal agencies map their programs against, because it is the one regulators and insurers read.
The framework is organized into four core functions — Govern, Map, Measure, Manage — that form a continuous loop, not a linear pipeline. Govern is the foundation: who owns AI risk, what policies exist, how risk tolerance is documented. Map establishes context: the use case, the data, the tools, the blast radius. Measure quantifies risk: testing, evaluation, red-teaming, the injection success rates and OWASP scores you have been producing. Manage allocates resources to the risks Map found and Measure quantified: the deployed controls and the incident-response capability.
Here is the table that bridges this module to the rest of the course. Govern is answered by the policy-as-code layer from B11.3 and the scope file from B0. Map is answered by the threat model from B1 and the AI BOM from B11.2. Measure is answered by your injection rates from B2, your OWASP checklist scores from B9, your Microsoft taxonomy findings from B10. Manage is answered by tool governance from B3, sandboxing from B6, observability from B8. The controls you built map onto the four functions. A governance review is not a re-test of those controls — it is a request for evidence that they map to the four functions and that the mapping is documented.
[SLIDE 5 — Voluntary in law, mandatory in practice]
Why does a voluntary framework become mandatory? Three reasons. One: OMB M-24-10 requires US federal agencies to implement the RMF for AI the government uses, and vendors selling to those agencies inherit the requirement. Two: insurers underwriting AI liability policies ask for RMF alignment. Three: enterprise governance councils map their AI programs against it because it is the framework their auditors read. Voluntary in law, mandatory in practice.
[SLIDE 6 — The compliance frameworks landscape]
NIST AI RMF is the center, but the landscape is plural. ISO 42001 is the certifiable AI management system standard — the ISO 9001 equivalent for AI. Where the RMF is a voluntary framework, 42001 is a certifiable standard, and some enterprises and regulators treat certification as a procurement requirement. 42001 and the RMF are designed to interoperate; an RMF-aligned program is most of the way to 42001.
The EU AI Act is the regulation with teeth. B0 covered the law; here we cover the compliance engineering. Annex IV reads like an AI BOM plus a risk assessment. Article 12 reads like an audit-trail spec. Article 14 reads like a human-in-the-loop control. The AI Act is the RMF made mandatory.
Then the sector frameworks. Healthcare AI inherits HIPAA — the agent that reads PHI must satisfy the Security Rule's audit-control standard. Government AI inherits FedRAMP. Financial AI inherits SOX and model-risk management. The framework does not replace the sector rule; it layers on top.
And the live 2026 reference: the Cloud Security Alliance's research notes mapping NIST's AI Agent Standards Initiative — CAISI, announced February 2026 — onto enterprise governance obligations. The CSA compliance-mapping notes published March and April 2026 are the source to cite when an enterprise asks what the agent-specific governance standard is. Two artifacts all of these frameworks ask for first: the AI BOM and the audit trail. That is the next sub-section.
[SLIDE 7 — B11.2 The AI BOM and the audit trail]
Sub-section two. The two artifacts a regulator asks for first — the AI BOM and the audit trail.
[SLIDE 8 — The AI BOM]
The AI BOM. The Software Bill of Materials is established practice for traditional software — a machine-readable inventory of every component, dependency, and version in a build. The AI BOM extends the SBOM to AI systems. An agent is not just software. It is software plus a model plus training data plus tools plus prompts plus external services. An SBOM that lists the Python packages but not the model version, the training data sources, or the MCP servers is an SBOM that misses the components an AI attacker actually targets.
The AI BOM contains six component classes. Three are AI-specific extensions over a traditional SBOM: the model — provider, id, checkpoint, modality, license; the training data — datasets, sources, provenance, PII status; the system prompt and config — prompt version, config hash, guardrail versions. Three are the SBOM surface extended for agents: tools and MCP servers, frameworks and SDKs, and external services. The model version is the single most important field — a finding against one checkpoint may not reproduce on the next, as B0 established.
An agent without an AI BOM cannot be audited. A vulnerability in a dependency cannot be traced to the agents that include it. A model-version dispute cannot be resolved. A compliance assertion about training-data licensing cannot be evidenced. A change cannot be governed without a version history. The AI BOM is the precondition for every other governance artifact. Generate it from the running system, not from a wiki — a wiki and reality drift, and the auditor reads reality.
[SLIDE 9 — The audit trail]
If the AI BOM is the static inventory, the audit trail is the dynamic evidence — the record of what the agent actually did, when, and with what authorization. The audit trail is the artifact that proves controls are enforced, not just documented.
Six event classes must be logged. Agent decisions, with timestamp, agent id, model version, decision, and rationale. Tool calls, with tool name, redacted arguments, result class, outcome. Approvals, with approval id, approver, policy reference, decision. Model version, sampled at decision time — the B0 minimum-evidence requirement extended to every decision, not just findings. Policy evaluations, with policy id, action evaluated, decision, and reason. And data access, with surface, data class, and record count — counts, not content, applying B0 retention discipline.
Here is the load-bearing point. A control documented in a policy is a control the auditor assumes exists. A control evidenced in an audit trail is a control the auditor can verify. The gap between "we have a policy" and "we can prove the policy fired" is the gap between passing and failing a governance review. And the audit trail must be complete, not sampled. An observability dashboard that logs one percent of events is useful for engineering and useless for compliance. EU AI Act Article 12 and HIPAA's audit-control standard both require the logs to exist, be complete, and be retained. The audit trail is not optional and it is not best-effort.
[SLIDE 10 — B11.3 Policy-as-code]
Sub-section three. Policy-as-code — the governance-to-engineering bridge.
[SLIDE 11 — The policy → control → test → audit loop]
A governance policy written in a document is a statement of intent. It does nothing at runtime. The policy "no agent may access production data without human approval" sitting in a wiki has no effect on the agent's behavior — the agent will access production data whenever its tools permit, whether a human approved it or not. Policy-as-code closes the gap. The lifecycle has four stages. Policy, written in plain English, owned by a named role — a Govern output. Control, the policy compiled to an enforceable rule. Test, a B9 or B10 test that verifies the control fires. Audit, the entry emitted by the control's evaluation at runtime. The four stages form a loop, not a pipeline. A policy change propagates all the way around. A test failure propagates back to a control fix. The loop is the governance system operating. A static policy document is the loop frozen at stage one.
[SLIDE 12 — Two reference implementations]
This pattern has two production references in Course 1's deep dives. IronCurtain, DD-20, contributes deterministic policy compilation. You write policy in plain English in a constitution file. An offline LLM pipeline compiles it to deterministic JSON rules. At runtime, enforcement is pure if-then evaluation — zero LLM at runtime. The LLM is a build-time tool; the enforcement is machine-certain. That is the architecturally pure policy-as-code pattern.
NemoClaw, DD-09, contributes the architectural placement. NeMo Guardrails sit between the agent and the world, where the agent cannot reach them to disable them. This is the load-bearing principle: if the agent can reach the enforcement layer, a compromised agent can disable it. Policy-as-code that lives inside the agent's process is policy-as-code that a prompt injection can turn off. Policy-as-code that lives in the harness execution path — the interceptor every tool call and model call passes through — is policy-as-code that survives agent compromise.
The synthesis: write policy in plain English, Govern-owned; compile to deterministic rules, IronCurtain; enforce in the harness execution path, not the agent process, NemoClaw; emit an audit-trail entry for every evaluation. That is the bridge, end to end.
[SLIDE 13 — The policy-as-code engine]
The engine takes an action the agent proposes, evaluates it against the policy, and produces a decision plus an audit-trail entry. Three things to notice. First, default-deny. An action no rule matches is denied, not allowed. The failure mode of a missing policy is safety, not openness. Second, the audit entry is emitted for every evaluation, including the default-deny — the evidence that the policy fired, or that no policy matched, is captured. Third, redaction is policy-aware. The production-data surface logs argument keys, not argument values, applying B0 retention discipline at the audit layer. The lab has you extend this engine: add an approval-state check, add the AI BOM as a policy input, and wire the audit entries to a tamper-evident store.
[SLIDE 14 — The load-bearing principle]
The load-bearing principle. Technical security wins the engineering review. Governance wins the enterprise review. The agent with a four-percent injection rate and no governance layer does not ship. The agent with weaker controls and a complete AI BOM, audit trail, and policy-as-code engine ships first. The budget and the board attention follow the governance layer. Build it.
[SLIDE 14 — Lab and what's next]
The lab has you build the three governance artifacts: an AI BOM generator that reads a sample agent; the policy-as-code engine with default-deny and redaction; an audit-trail writer with append-only semantics and hash-chaining for tamper-evidence. No GPU, about sixty to seventy-five minutes. Next: B12, Harness Security Assessments as a Service. B12 packages the governance layer from this module with the red-team methodologies from B9 and B10 into a single deliverable engagement. The AI BOM, the audit trail, and the RMF mapping become the product. Let's build it.
# Teaching Script — Module B11: Governance and Compliance **Course**: Course 2B — Securing & Attacking Harnesses and LLMs **Module**: B11 — Governance and Compliance **Duration**: ~35 minutes (spoken at ~140 wpm) **Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes. --- [SLIDE 1 — Title] Welcome to Module B11. Governance and Compliance. You have spent nine modules building controls. You can attack and defend an agent at a level most teams cannot. None of that ships the agent. A CISO does not approve production deployment because a guardrail works. A board does not allocate next year's budget because a red-team found the right gaps. They approve, sign, and allocate against frameworks — NIST AI RMF, ISO 42001, the EU AI Act's conformity obligations — because those are the instruments their auditors, regulators, and insurers read. The working guardrail is necessary. The framework mapping is what makes it fundable, approvable, and defensible. This is the gap the Perplexity conversation flagged as a depth upgrade: technical security wins the engineering review; governance and compliance win the enterprise review. They are not the same activity. This module teaches you to build the second one. [SLIDE 2 — The governance gap] Here is the gap made concrete. An agent with a four-percent injection success rate and no AI BOM, no audit trail, and no policy-as-code layer will not clear an enterprise governance review. And here is the uncomfortable part — an agent that clears the review with weaker technical controls but a complete governance stack will ship first. The budget and the board attention follow the governance layer. The working control and the documented mapping are both required, and they are produced by different activities. This module is the second activity. [SLIDE 3 — B11.1 The governance frameworks] Sub-section one. The governance frameworks. NIST AI RMF is the center, and the landscape around it. [SLIDE 4 — NIST AI RMF four core functions] The NIST AI Risk Management Framework — AI 100-1, published January 2023. It is voluntary. It carries no penalties. And yet it has become the de facto US AI governance standard for exactly the reason this module exists: it is the framework CISOs, governance councils, and federal agencies map their programs against, because it is the one regulators and insurers read. The framework is organized into four core functions — Govern, Map, Measure, Manage — that form a continuous loop, not a linear pipeline. Govern is the foundation: who owns AI risk, what policies exist, how risk tolerance is documented. Map establishes context: the use case, the data, the tools, the blast radius. Measure quantifies risk: testing, evaluation, red-teaming, the injection success rates and OWASP scores you have been producing. Manage allocates resources to the risks Map found and Measure quantified: the deployed controls and the incident-response capability. Here is the table that bridges this module to the rest of the course. Govern is answered by the policy-as-code layer from B11.3 and the scope file from B0. Map is answered by the threat model from B1 and the AI BOM from B11.2. Measure is answered by your injection rates from B2, your OWASP checklist scores from B9, your Microsoft taxonomy findings from B10. Manage is answered by tool governance from B3, sandboxing from B6, observability from B8. The controls you built map onto the four functions. A governance review is not a re-test of those controls — it is a request for evidence that they map to the four functions and that the mapping is documented. [SLIDE 5 — Voluntary in law, mandatory in practice] Why does a voluntary framework become mandatory? Three reasons. One: OMB M-24-10 requires US federal agencies to implement the RMF for AI the government uses, and vendors selling to those agencies inherit the requirement. Two: insurers underwriting AI liability policies ask for RMF alignment. Three: enterprise governance councils map their AI programs against it because it is the framework their auditors read. Voluntary in law, mandatory in practice. [SLIDE 6 — The compliance frameworks landscape] NIST AI RMF is the center, but the landscape is plural. ISO 42001 is the certifiable AI management system standard — the ISO 9001 equivalent for AI. Where the RMF is a voluntary framework, 42001 is a certifiable standard, and some enterprises and regulators treat certification as a procurement requirement. 42001 and the RMF are designed to interoperate; an RMF-aligned program is most of the way to 42001. The EU AI Act is the regulation with teeth. B0 covered the law; here we cover the compliance engineering. Annex IV reads like an AI BOM plus a risk assessment. Article 12 reads like an audit-trail spec. Article 14 reads like a human-in-the-loop control. The AI Act is the RMF made mandatory. Then the sector frameworks. Healthcare AI inherits HIPAA — the agent that reads PHI must satisfy the Security Rule's audit-control standard. Government AI inherits FedRAMP. Financial AI inherits SOX and model-risk management. The framework does not replace the sector rule; it layers on top. And the live 2026 reference: the Cloud Security Alliance's research notes mapping NIST's AI Agent Standards Initiative — CAISI, announced February 2026 — onto enterprise governance obligations. The CSA compliance-mapping notes published March and April 2026 are the source to cite when an enterprise asks what the agent-specific governance standard is. Two artifacts all of these frameworks ask for first: the AI BOM and the audit trail. That is the next sub-section. [SLIDE 7 — B11.2 The AI BOM and the audit trail] Sub-section two. The two artifacts a regulator asks for first — the AI BOM and the audit trail. [SLIDE 8 — The AI BOM] The AI BOM. The Software Bill of Materials is established practice for traditional software — a machine-readable inventory of every component, dependency, and version in a build. The AI BOM extends the SBOM to AI systems. An agent is not just software. It is software plus a model plus training data plus tools plus prompts plus external services. An SBOM that lists the Python packages but not the model version, the training data sources, or the MCP servers is an SBOM that misses the components an AI attacker actually targets. The AI BOM contains six component classes. Three are AI-specific extensions over a traditional SBOM: the model — provider, id, checkpoint, modality, license; the training data — datasets, sources, provenance, PII status; the system prompt and config — prompt version, config hash, guardrail versions. Three are the SBOM surface extended for agents: tools and MCP servers, frameworks and SDKs, and external services. The model version is the single most important field — a finding against one checkpoint may not reproduce on the next, as B0 established. An agent without an AI BOM cannot be audited. A vulnerability in a dependency cannot be traced to the agents that include it. A model-version dispute cannot be resolved. A compliance assertion about training-data licensing cannot be evidenced. A change cannot be governed without a version history. The AI BOM is the precondition for every other governance artifact. Generate it from the running system, not from a wiki — a wiki and reality drift, and the auditor reads reality. [SLIDE 9 — The audit trail] If the AI BOM is the static inventory, the audit trail is the dynamic evidence — the record of what the agent actually did, when, and with what authorization. The audit trail is the artifact that proves controls are enforced, not just documented. Six event classes must be logged. Agent decisions, with timestamp, agent id, model version, decision, and rationale. Tool calls, with tool name, redacted arguments, result class, outcome. Approvals, with approval id, approver, policy reference, decision. Model version, sampled at decision time — the B0 minimum-evidence requirement extended to every decision, not just findings. Policy evaluations, with policy id, action evaluated, decision, and reason. And data access, with surface, data class, and record count — counts, not content, applying B0 retention discipline. Here is the load-bearing point. A control documented in a policy is a control the auditor assumes exists. A control evidenced in an audit trail is a control the auditor can verify. The gap between "we have a policy" and "we can prove the policy fired" is the gap between passing and failing a governance review. And the audit trail must be complete, not sampled. An observability dashboard that logs one percent of events is useful for engineering and useless for compliance. EU AI Act Article 12 and HIPAA's audit-control standard both require the logs to exist, be complete, and be retained. The audit trail is not optional and it is not best-effort. [SLIDE 10 — B11.3 Policy-as-code] Sub-section three. Policy-as-code — the governance-to-engineering bridge. [SLIDE 11 — The policy → control → test → audit loop] A governance policy written in a document is a statement of intent. It does nothing at runtime. The policy "no agent may access production data without human approval" sitting in a wiki has no effect on the agent's behavior — the agent will access production data whenever its tools permit, whether a human approved it or not. Policy-as-code closes the gap. The lifecycle has four stages. Policy, written in plain English, owned by a named role — a Govern output. Control, the policy compiled to an enforceable rule. Test, a B9 or B10 test that verifies the control fires. Audit, the entry emitted by the control's evaluation at runtime. The four stages form a loop, not a pipeline. A policy change propagates all the way around. A test failure propagates back to a control fix. The loop is the governance system operating. A static policy document is the loop frozen at stage one. [SLIDE 12 — Two reference implementations] This pattern has two production references in Course 1's deep dives. IronCurtain, DD-20, contributes deterministic policy compilation. You write policy in plain English in a constitution file. An offline LLM pipeline compiles it to deterministic JSON rules. At runtime, enforcement is pure if-then evaluation — zero LLM at runtime. The LLM is a build-time tool; the enforcement is machine-certain. That is the architecturally pure policy-as-code pattern. NemoClaw, DD-09, contributes the architectural placement. NeMo Guardrails sit between the agent and the world, where the agent cannot reach them to disable them. This is the load-bearing principle: if the agent can reach the enforcement layer, a compromised agent can disable it. Policy-as-code that lives inside the agent's process is policy-as-code that a prompt injection can turn off. Policy-as-code that lives in the harness execution path — the interceptor every tool call and model call passes through — is policy-as-code that survives agent compromise. The synthesis: write policy in plain English, Govern-owned; compile to deterministic rules, IronCurtain; enforce in the harness execution path, not the agent process, NemoClaw; emit an audit-trail entry for every evaluation. That is the bridge, end to end. [SLIDE 13 — The policy-as-code engine] The engine takes an action the agent proposes, evaluates it against the policy, and produces a decision plus an audit-trail entry. Three things to notice. First, default-deny. An action no rule matches is denied, not allowed. The failure mode of a missing policy is safety, not openness. Second, the audit entry is emitted for every evaluation, including the default-deny — the evidence that the policy fired, or that no policy matched, is captured. Third, redaction is policy-aware. The production-data surface logs argument keys, not argument values, applying B0 retention discipline at the audit layer. The lab has you extend this engine: add an approval-state check, add the AI BOM as a policy input, and wire the audit entries to a tamper-evident store. [SLIDE 14 — The load-bearing principle] The load-bearing principle. Technical security wins the engineering review. Governance wins the enterprise review. The agent with a four-percent injection rate and no governance layer does not ship. The agent with weaker controls and a complete AI BOM, audit trail, and policy-as-code engine ships first. The budget and the board attention follow the governance layer. Build it. [SLIDE 14 — Lab and what's next] The lab has you build the three governance artifacts: an AI BOM generator that reads a sample agent; the policy-as-code engine with default-deny and redaction; an audit-trail writer with append-only semantics and hash-chaining for tamper-evidence. No GPU, about sixty to seventy-five minutes. Next: B12, Harness Security Assessments as a Service. B12 packages the governance layer from this module with the red-team methodologies from B9 and B10 into a single deliverable engagement. The AI BOM, the audit trail, and the RMF mapping become the product. Let's build it.