# Module B11 — Governance and Compliance **Course**: 2B — Securing & Attacking Harnesses and LLMs **Module**: B11 — Governance and Compliance **Duration**: 75 minutes **Level**: Senior Engineer and above **Prerequisites**: B0–B10 complete; Course 1 DD-09 (NemoClaw) and DD-20 (IronCurtain) recommended > *B2 through B8 built the technical controls. They are necessary but not sufficient. CISOs, AI governance teams, and boards release budget and approval against frameworks — NIST AI RMF, ISO 42001, the EU AI Act's compliance engineering — not against a working guardrail. This module is where the technical control you built becomes the control the auditor signs off on, the AI BOM the procurement team accepts, and the audit trail the regulator reads. Where enterprise budgets and board attention actually move.* --- ## Learning Objectives After completing this module, you will be able to: 1. Explain the **governance gap**: why technical security (B2–B8) is necessary but not sufficient for enterprise adoption, and why a governance and compliance layer is the budget and board layer an agent must pass before production. 2. Map the technical controls from B2–B8 to the four core functions of the **NIST AI RMF** (AI 100-1) — Govern, Map, Measure, Manage — and explain why the RMF is voluntary yet becoming the de facto US governance standard. 3. Build and read an **AI BOM (AI Bill of Materials)** — the SBOM concept extended to the model, training data sources, tools/MCP servers, and dependencies — and argue why an agent without an AI BOM cannot be audited. 4. Specify the **audit trail** fields that make an agent's decisions, tool calls, approvals, and model versions reconstructable after the fact, and connect them to B8's observability layer. 5. Translate a governance policy (e.g., "no agent may access production data without human approval") into an **enforceable harness control** using the policy-as-code pattern (policy → control → test → audit), tying it to DD-20 IronCurtain's deterministic enforcement and DD-09 NemoClaw's governance layer. 6. Navigate the **compliance frameworks landscape** — NIST AI RMF (US, voluntary), EU AI Act compliance engineering, ISO 42001, sector frameworks (HIPAA, FedRAMP) — and reference the CSA NIST AI Agent Standards compliance mapping. --- ## Why this module exists You have spent nine modules building controls. B2 hardened the prompt and input boundary. B3 locked down tool calling. B4 secured the supply chain. B5 constrained memory. B6 sandboxed execution. B7 mediated inter-agent trust. B8 built the observability layer. B9 handed you the OWASP checklist. B10 the Microsoft red-team taxonomy. You can now 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. An AI governance council does not sign off because an injection success rate dropped from 60% to 4%. A board does not allocate next year's security 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. An agent with a 4% injection success rate and no AI BOM, no audit trail, and no policy-as-code layer will not clear an enterprise governance review — and 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. This module teaches you to build it. The bridge this module builds is concrete: a **policy** becomes a **control** (B2–B8), becomes a **test** (B9, B10), becomes an **audit-trail entry** (B8). That lifecycle is the governance-to-engineering bridge. Everything in this module is about making each link machine-checkable, because auditors do not read wikis — they read artifacts. Three sub-sections — the first deepened to carry the NIST AI RMF material: - **B11.1 — The Governance Frameworks (NIST AI RMF + the landscape).** The four core functions — Govern, Map, Measure, Manage — and how the B2–B8 controls map to each. Then the deep dive: NIST AI 600-1 (the twelve Generative AI risk categories), the Agentic Profile (CSA Agentic NIST AI RMF Profile v1, CLTC Berkeley, NIST CAISI), ISO 42001 and the EU AI Act's six risk tiers (from voluntary to mandatory), and the practical governance documentation package. The compliance landscape: NIST AI RMF (US, voluntary but de facto), EU AI Act compliance engineering, ISO 42001, sector frameworks. - **B11.2 — The AI BOM and the Audit Trail.** The AI Bill of Materials (the inventory that makes an agent auditable) and the audit trail (the evidence that controls are actually enforced). These are the two artifacts a regulator or auditor asks for first. - **B11.3 — Policy-as-Code: The Governance-to-Engineering Bridge.** How a governance policy becomes an enforceable control, a test, and an audit-trail entry. The policy-as-code engine. Ties to DD-20 IronCurtain's deterministic enforcement and DD-09 NemoClaw's governance-beneath-the-agent pattern. --- # B11.1 — The Governance Frameworks *The frameworks the budget and the board follow — and how your technical controls map onto them.* ## NIST AI RMF (AI 100-1): the central framework The NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1, published January 2023) is a **voluntary, rights-preserving, non-sector-specific** framework for managing AI risk. It is not a regulation. It carries no penalties. And yet it has become the de facto US governance standard for exactly the reason this module exists: it is the framework CISOs, governance councils, and federal agencies map their AI programs against, because it is the one regulators and insurers read. OMB M-24-10 requires US federal agencies to implement the RMF for AI the government uses; vendors selling to those agencies inherit the requirement. Insurers underwriting AI liability policies ask for RMF alignment. The RMF is voluntary in law and mandatory in practice. The framework is organized into **four core functions** — Govern, Map, Measure, Manage — that form a continuous loop, not a linear pipeline. Every AI system is expected to be doing all four at all times. ### GOVERN — culture, accountability, policy Govern is the foundational function: the structures, policies, and accountability that make the other three work. It covers: who owns AI risk (a named accountable role, not a committee); what policies exist (acceptable use, model approval, incident response); how risk tolerance is documented and communicated; how the organization trains its people. Govern is the function most often absent in engineering teams that built a working agent and then asked "now what do we tell the board?" The Govern output is not a guardrail — it is a **policy** and a **named owner**. The harness implication: the policy documents produced under Govern are the *input* to B11.3's policy-as-code layer. A governance policy that is not enforceable in code is a policy that does not exist at runtime. ### MAP — context, use, risk surface Map establishes the context in which an AI system operates: the specific use case, the stakeholders, the potential harms, the trust surface. For an agent: what data can it reach (B4, B5), what tools can it call (B3), who can interact with it (B1's trust model), what is the blast radius of a compromise. Map is where B1's threat model becomes a governance artifact — the documented risk surface that the rest of the framework measures and manages. Map's output is the **context statement**: a documented description of the agent, its deployment, its data, its users, and the harms that would result from misuse or failure. This is the human-readable ancestor of the AI BOM (B11.2). ### MEASURE — test, evaluate, verify Measure is the function that quantifies risk: testing, evaluation, red-teaming, monitoring. This is where the technical controls you built become evidence. The InjecAgent success-rate measurement (SDD-B03), the OWASP ASI checklist scores (B9), the Microsoft taxonomy chain findings (B10) — these are all Measure outputs. A guardrail that works is a Measure artifact only if it is measured; a guardrail asserted without measurement is not an RMF output, it is an opinion. Measure's output is the **evidence base**: success rates, coverage percentages, residual-risk measurements. This is what the audit trail (B11.2) captures at runtime. ### MANAGE — mitigate, respond, remediate Manage allocates resources to the risks identified by Map and quantified by Measure: mitigations (the B2–B8 controls), response plans (B0's incident-reporting obligations), and remediation tracking. Manage is where the controls are deployed and where the audit trail proves they were deployed. Manage is also the function that closes the loop: residual risk that exceeds tolerance goes back to Map (re-scope) or Govern (re-policy). Manage's output is the **deployed control set** plus the **incident-response capability** — both evidenced in the audit trail. ### How B2–B8 maps to the four functions | RMF Function | What it asks | Course 2B controls that answer it | | --- | --- | --- | | **Govern** | Who owns the risk? What policy applies? | The policy-as-code layer (B11.3); the scope file's provider_authorization (B0) | | **Map** | What is the system? What can go wrong? | The threat model (B1); the AI BOM (B11.2) | | **Measure** | Have we tested it? What is the residual risk? | Injection success rates (B2, SDD-B03); OWASP checklist scores (B9); Microsoft taxonomy findings (B10) | | **Manage** | What controls are deployed? How do we respond? | Tool-call governance (B3); sandboxing (B6); observability (B8); incident response (B0) | This table is the bridge. A governance review is not a re-test of your controls — it is a request for evidence that your controls map to the four functions and that the mapping is documented. The working control and the documented mapping are both required. ## NIST AI 600-1: the Generative AI Profile The base RMF (AI 100-1) is technology-neutral — it applies to a logistic-regression fraud model and a frontier LLM agent identically. That breadth is a feature for a general-purpose standard and a liability for practitioners shipping generative AI, because the failure modes of generative systems are categorically different from those of predictive ML. NIST closed that gap with the **Generative AI Profile (NIST AI 600-1, July 2024)**, a companion to RMF 1.0 that enumerates twelve risk categories characteristic of generative AI and roughly two hundred suggested actions distributed across the four functions. The twelve categories, with the agent-specific reading that matters for this course: | Risk category (AI 600-1) | What it names | The agent-specific reading | | --- | --- | --- | | **CBRN Information** | Generation of chemical, biological, radiological, nuclear instructions | An agent with web/tool access (B3) is a CBRN-amplifier only if the policy layer (B11.3) does not gate the relevant surfaces. | | **Confabulation** | Plausible but false outputs | An agent that confabulates a fact and then calls a tool against it (B3) turns a harmless hallucination into a real-world action. The audit trail (B11.2) is what makes this reconstructable. | | **Dangerous, Violent, or Hateful Content** | Prohibited output classes | Output governance is B2's boundary and the constitution's deny-list (B11.3, DD-20). | | **Data Privacy** | PII exposure, re-identification, training-data leakage | The B5 memory and B7 inter-agent data-flow controls. An agent moving data across trust boundaries is the central privacy risk. | | **Human-AI Configuration** | The autonomy/oversight dial — when the user understands vs. misunderstands the system | This is the HITL control (B0, B10) made into a governance concept. The configuration decision (how autonomous is this agent) is a Govern output that the harness must enforce. | | **Information Integrity** | Misinformation, influence operations, synthetic media at scale | Agents that publish, post, or email are information-integrity surfaces; the policy-as-code engine gates who they can reach. | | **Information Security** | Prompt injection, extraction, abuse — the adversarial surface | The entire subject of Course 2B (B2–B10). AI 600-1 names what this course teaches. | | **Intellectual Property** | Training-data provenance, output ownership, copyright | The AI BOM's training-data-provenance field (B11.2) is the IP artifact. | | **Harmful Bias & Homogenization** | Discriminatory outputs, collapse of diversity at scale | An agent making decisions about people (credit, hiring, triage) inherits this; the audit trail must capture enough to detect drift. | | **Obscene, Degrading, or Abusive Content** | Prohibited content classes | Output filtering (B2) and the constitution's deny-list. | | **Data & Content Provenance** | Provenance of training data and of generated content | The AI BOM (B11.2) and the audit trail (B11.2) together. Provenance is what the EU AI Act Article 12 logging requirement operationalizes. | | **Environmental Impacts** | Compute, energy, water | A Govern concern (risk tolerance includes sustainability); out of scope for this course's technical controls but required in the documentation. | The point of this table is not to memorize twelve categories. It is to see that **every technical control in B2–B10 is a control against a risk the RMF names.** The Confabulation row is your audit-trail design; the Information Security row is your injection-rate measurement; the Human-AI Configuration row is your HITL gate. The profile is what makes the mapping two-way: not only does your control answer a function, it answers a named risk. ## The Agentic Profile: the RMF applied to agents AI 600-1 extends the RMF to generative AI. But agents add a third layer of specificity — autonomy, identity, authorization — that neither the base RMF nor the GenAI profile fully addresses. Two 2025–2026 efforts close that gap and are the sources to cite when an enterprise asks "what is the agent-specific governance standard." **The CSA Agentic NIST AI RMF Profile (v1).** The Cloud Security Alliance published a structured set of **extensions to RMF 1.0 organized by function**, tailored for AI agents. The pattern is additive: the CSA profile does not replace the four functions, it augments each with agent-specific actions. The agent-specific concerns that recur across all four functions are identity (who or what is the agent — authentication, non-repudiation, a stable principal the audit trail references), authorization (the capability scope — what tools, what data, what surfaces, with delegation and revocation), and autonomy scope (the dial between fully HITL and fully autonomous — where the boundaries are, who sets them, how the harness enforces them). The CSA's March 2026 follow-up maps the **243 controls** of its AI Controls Matrix (AICM) onto NIST AI 600-1, giving the agent-specific RMF a control-level vocabulary. This is the artifact to hand an enterprise auditor who asks "show me your agent control matrix." **The CLTC Berkeley Agentic AI Risk Profile.** The Center for Long-Term Cybersecurity at UC Berkeley produced an academic companion, structured around the same Govern/Map/Measure/Manage loop, focusing on the risks that emerge only when an AI system acts autonomously — the chain-of-action problem (a long sequence of agent steps where each is locally acceptable but the cumulative effect is not), the principal-agent problem (the agent's goals drift from the principal's), and the authorization-delegation problem (an agent delegating to a sub-agent inherits and amplifies the sub-agent's risk). These are not theoretical: B7's inter-agent trust model is the harness-level answer to the delegation problem, and the audit trail's `agent_id` and `policy_id` fields are the evidence the principal-agent drift is detectable. **NIST CAISI (Center for AI Agent Standards and Identity), announced February 2026.** NIST's own initiative, focused on the three pillars the CSA profile makes operational: **interoperability** (agents from different vendors, governed consistently), **security** (identity, authorization, the adversarial surface), and **openness** (open standards for agent identity and capability disclosure). CAISI is the long-arc standards work; the CSA profile is the near-term implementation guide. Cite both. The synthesis for this module: the RMF gives you the four functions; AI 600-1 gives you the twelve GenAI risks; the CSA Agentic Profile gives you the agent-specific extensions to the functions. An agent's governance documentation maps every control to all three — function, risk category, and agent-specific action. ## ISO 42001 and the EU AI Act: from voluntary to mandatory The RMF is voluntary. Two instruments turn RMF-aligned practice into something enforceable, and both interoperate with the RMF by design. **ISO/IEC 42001:2023 — the certifiable AI management system (AIMS).** Where the RMF is a framework, 42001 is a **certifiable standard**: ten clauses defining the management system (organizational context, leadership, planning, support, operation, performance evaluation, improvement) and thirty-eight Annex A controls (the control-level vocabulary an auditor assesses against). Certification is by third-party audit on a three-year cycle — the same model as ISO 9001, 27001, and 27017. NIST published an **official crosswalk** mapping the RMF to 42001 (the AI Resource Center document `NIST_AI_RMF_to_ISO_IEC_42001_Crosswalk`), and the practical result is interoperability: the Govern function maps roughly to 42001's Clauses 4–5 (context, leadership) and Clause 6 (planning); Map to Clause 6 and the risk-assessment Annex A controls; Measure to Clause 9 (performance evaluation); Manage to Clauses 8 and 10 (operation, improvement). An organization that has done RMF mapping honestly is most of the way to a 42001-certifiable AIMS. When an enterprise (or a regulator, or a procurement team) requires certification rather than framework alignment, 42001 is the certificate and the RMF is the preparation. **EU AI Act (Regulation 2024/1689) — the regulation with teeth.** B0 covered the law; the governance-relevant detail is the **risk-tier structure**, because the tier an agent falls into determines which obligations apply. The Act defines six tiers: | Tier | What it is | The obligations | Where an enterprise agent lands | | --- | --- | --- | --- | | **Unacceptable** (Article 5) | Prohibited practices — social scoring, manipulative subliminal AI, untargeted facial scraping | Banned outright | An agent that scores individuals, manipulates users, or scrapes faces is not deployable in the EU at any governance level. | | **High Risk** (Annex III) | AI in employment, credit, essential services, justice, migration, biometric ID | Conformity assessment, CE marking, Annex IV technical documentation, Article 12 logging, Article 14 human oversight, Article 15 accuracy/robustness, post-market monitoring | **Most enterprise agents that make or support decisions about people fall here.** An agent screening job applicants, adjudicating claims, or routing patients is High Risk. The engineering obligations are the RMF made mandatory: Annex IV reads like an AI BOM plus a risk assessment; Article 12 reads like an audit-trail spec; Article 14 reads like a HITL control. | | **Limited Risk** (transparency) | Chatbots, emotion recognition, deepfakes, AI-generated content | Transparency obligations — users must know they are interacting with AI | A customer-facing agent that does not present as AI to its users is non-compliant. | | **Minimal Risk** | Everything else (spam filters, recommendations, etc.) | Voluntary codes of conduct | The default tier; most internal tools. | | **GPAI** (Title VIII) | General-purpose AI models (the foundation-model layer) | Technical documentation, training-data summary, copyright policy, downstream-provider information | The model provider's obligations. An agent platform consuming a GPAI inherits transparency about the model. | | **GPAI with Systemic Risk** | GPAI trained above **10^25 FLOPs** | All GPAI obligations plus model evaluations, adversarial testing (red-teaming), incident reporting, cybersecurity protections | The frontier-model tier. If your agent runs on a systemic-risk GPAI, your documentation must reference the provider's evals and your incident-response must align with theirs. | The agent-specific mapping is the load-bearing observation: **an agent is governed by its use-case tier (High Risk in most enterprise deployments) and inherits its model's tier (GPAI or GPAI-systemic).** Both apply simultaneously. An agent built on a systemic-risk GPAI and deployed for employment screening must satisfy Annex III (High Risk) *and* reference the provider's systemic-risk obligations. This is why the AI BOM (B11.2) records both the model provenance *and* the use-case scope — both tiers must be documentable. ## Practical implementation: agent platform governance documentation Translating the above into the artifacts an enterprise governance review actually reads. A defensible agent platform governance package contains, at minimum: 1. **The AI BOM** (B11.2) — model, training-data provenance, tools/MCP servers, dependencies, config, external services. This is the Annex IV technical-documentation core, the RMF Map input, and the 42001 risk-assessment evidence. 2. **The RMF mapping** — every B2–B8 control mapped to its function (Govern/Map/Measure/Manage) *and* its AI 600-1 risk category *and* (where applicable) its CSA Agentic Profile extension. Three columns, not one. 3. **The policy registry** — the compiled policy set (B11.3, DD-20 IronCurtain's constitution), with every policy traceable to a Govern owner and a named risk tolerance. 4. **The audit-trail schema and a sample export** — the field set from B11.2, with evidence the trail is complete, append-only, and tamper-evident. This is what Article 12 and HIPAA § 164.312(b) actually read. 5. **The risk-tier classification** — for each agent deployment, the EU AI Act tier (with rationale) and the ISO 42001 control-mapping status. This is the document a regulator asks for first. 6. **The incident-response runbook** — tied to the audit trail's detection capability (B8) and the policy engine's ESCALATE decision (B11.3), satisfying Manage and Article 14 oversight. This package is what makes the difference between an agent that passes engineering and an agent that ships. The technical controls in B2–B10 produce the evidence; the governance package assembles it into the shape the auditor reads. None of this requires new technology — it requires the discipline of producing the artifacts from the running system, not from a wiki. **Forward reference — Course 4 E11 (Enterprise Platforms: Governance and Compliance).** This module covers the agent and the platform. Course 4's E11 scales the same governance stack to the **enterprise platform** — multi-tenant agent hosting, the organizational AIMS (ISO 42001 at the organization, not the product, level), cross-jurisdictional deployment (an agent that serves EU and US users under both regimes), and the procurement-side governance (the clauses a buyer puts in a vendor contract). The E11 module directory is under development; treat the B11 artifacts as the per-agent instance of the per-platform governance E11 will define. ## The compliance frameworks landscape NIST AI RMF is the center, but the landscape is plural. An enterprise agent may be governed by several frameworks simultaneously. - **EU AI Act compliance engineering.** B0 covered the law; here we cover the engineering. The AI Act (Regulation 2024/1689) imposes conformity obligations on high-risk AI systems (Title III) and GPAI providers (Title VIII). Compliance engineering means: building the technical documentation dossier (Annex IV — which reads like an AI BOM plus a risk assessment), implementing the quality/risk management system, logging (Article 12 — which reads like an audit trail spec), and human oversight (Article 14 — which reads like a HITL control). The AI Act is the regulation with teeth; its engineering requirements are the RMF made mandatory. - **ISO/IEC 42001:2023** — the AI management system standard. The ISO 9001 equivalent for AI: a certifiable management system covering AI policy, roles, risk treatment, and continual improvement. Where the RMF is a voluntary framework, 42001 is a certifiable standard — some enterprises (and some regulators) treat certification as procurement requirement. 42001 and the RMF are designed to interoperate; an RMF-aligned program is most of the way to 42001. - **Sector frameworks.** Healthcare AI inherits **HIPAA** (the agent that reads PHI is a covered entity's business associate; its audit trail must satisfy the Security Rule's access-control and audit-control standards). Government AI inherits **FedRAMP** (the agent running on government data must run in a FedRAMP-authorized environment with the controls assessed). Financial AI inherits **SOX** and model-risk management (SR 11-7). The framework does not replace the sector rule; it layers on top. - **CSA NIST AI Agent Standards mapping.** The Cloud Security Alliance's research notes on NIST's AI Agent Standards Initiative (CAISI, announced February 2026; CSA compliance-mapping notes published March–April 2026) map the emerging agentic standards onto enterprise governance obligations. The initiative's three pillars (interoperability, security, openness) and the CSA compliance-mapping notes are the live reference for how agent-specific governance is converging with the RMF. This is the 2026 source to cite when an enterprise asks "what is the agent-specific governance standard." **The operational synthesis:** NIST AI RMF is the default framework to map to; ISO 42001 if certification is required; the EU AI Act's engineering requirements if you operate in the EU market; the sector framework if one applies. The AI BOM and the audit trail (B11.2) are the two artifacts all of them ask for. --- # B11.2 — The AI BOM and the Audit Trail *The two artifacts a regulator asks for first — the inventory that makes an agent auditable, and the evidence that controls are actually enforced.* ## The AI BOM (AI Bill of Materials) The Software Bill of Materials (SBOM) is established practice for traditional software: a machine-readable inventory of every component, dependency, and version in a build, so that a vulnerability in one component can be traced to every product that includes it. The NTIA minimum elements (2021) and the CISA SBOM work established the format. Executive Order 14028 made SBOMs a federal procurement requirement for software. 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 is the inventory that makes the full AI supply chain visible — and therefore auditable. ### What an AI BOM contains | Component | Example fields | Why it matters | | --- | --- | --- | | **Model** | provider, model id, version/checkpoint, modality, parameters, license | A finding against `claude-opus-4-1-20260605` may not reproduce on the next checkpoint (B0). The model version is the single most important field. | | **Training data sources** | dataset names, sources, provenance, license, PII status | Provenance is the B4 supply-chain control. A model trained on a dataset with unknown licensing is a compliance liability. | | **Tools / MCP servers** | tool names, MCP server endpoints, versions, capability scope | The B3 tool surface. A tool added without an AI BOM entry is a tool invisible to the auditor (and to B10's capability-disclosure recon). | | **Frameworks & SDKs** | harness framework, version, dependencies (the SBOM subset) | The traditional supply-chain surface (B4, SDD-B07). | | **System prompt & config** | prompt version, config hash, guardrail versions | The B2 input-boundary surface. A system prompt that changed without an AI BOM version bump is an undocumented configuration drift. | | **External services** | API providers, vector DB, identity provider, sandbox provider | The B1 trust surface. Every external dependency is an attack surface and a compliance dependency. | This table is the union of the SBOM (software), the model card (model + data), and the harness inventory (tools + config). An AI BOM generator (the lab) produces this from the running system, not from a wiki — because a wiki and reality drift, and the auditor reads reality. ### Why an agent without an AI BOM cannot be audited An audit reconstructs what the system was at a point in time. Without an AI BOM: - A vulnerability disclosed in a dependency (a malicious MCP server, a poisoned dataset, a model version with a known jailbreak) **cannot be traced** to the agents that include it. The supply-chain response (B4) has no inventory to query. - A model-version dispute ("this finding does not reproduce") **cannot be resolved** — there is no record of which version was running when. - A compliance assertion ("we do not use unlicensed training data") **cannot be evidenced** — there is no provenance record. - A change ("we updated the system prompt") **cannot be governed** — there is no version history. The AI BOM is the precondition for every other governance artifact. This is why B4 (supply chain) and B12 (assessment) both depend on it. The lab has you build a generator that emits an AI BOM in a machine-readable format (the NTIA minimum elements extended with the AI-specific fields above) for a sample agent. ## 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. A policy that says "no agent may access production data without human approval" is aGovern output; the audit trail entry that shows the approval was captured, the data access was logged, and the model version is pinned is the Manage evidence that the policy was real. ### What must be logged for compliance | Event class | Fields | Why | | --- | --- | --- | | **Agent decision** | timestamp (UTC), agent id, model version, decision, rationale/trace | Reconstructability — the regulator's first question after an incident is "what did the agent decide and why?" | | **Tool call** | tool name, arguments (redacted per data class), result class, outcome | The B3 tool surface in evidence. A tool call that was not logged did not happen, for compliance purposes. | | **Approval** | approval id, approver, policy reference, decision, timestamp | The HITL control (B0, B10) in evidence. An approval not logged is an approval that cannot be proven. | | **Model version** | model id, checkpoint, sampled at decision time | The B0 minimum-evidence requirement, extended to every decision, not just findings. | | **Policy evaluation** | policy id, action evaluated, decision (ALLOW/DENY), reason | The B11.3 policy-as-code engine output. A policy that was not evaluated at runtime is a policy that was not enforced. | | **Data access** | surface, data class, records accessed (count, not content) | The B5/B7 data-access control. PII access counts, not PII content (B0 retention discipline). | These fields are the B8 observability layer made compliance-grade. B8's observability is the engineering capability; the audit trail is the *evidence* that capability produces, formatted for the regulator. The difference is retention, integrity (append-only, hash-chained or tamper-evident), and completeness — an observability dashboard that samples is not an audit trail, because an auditor reads the complete record. ### The audit trail is the evidence controls are enforced This 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. The policy-as-code engine (B11.3) is what closes the gap — every policy evaluation emits an audit-trail entry, and the entry is the evidence. The EU AI Act's Article 12 (logging) and HIPAA's Security Rule audit-control standard (§ 164.312(b)) both require this. Neither accepts "we have logging configured" — they require the logs to exist, to be complete, and to be retained for a defined period. The audit trail is not optional and it is not best-effort. --- # B11.3 — Policy-as-Code: The Governance-to-Engineering Bridge *How a policy becomes a control, becomes a test, becomes an audit-trail entry — the full lifecycle.* ## The problem policy-as-code solves 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. The gap between policy and enforcement is where every governance failure lives. Policy-as-code closes the gap by making the policy **machine-evaluable and enforced in the harness's execution path.** The policy is expressed as a rule (in code or a declarative policy language). The rule is evaluated against every action the agent proposes. The evaluation produces a decision (ALLOW, DENY, ESCALATE-TO-HUMAN). The decision is enforced (the action proceeds, is blocked, or waits for approval). And the decision is written to the audit trail. The policy, the enforcement, and the evidence are one system. ## The policy → control → test → audit lifecycle This is the governance-to-engineering bridge as a four-stage lifecycle: 1. **Policy** — a governance statement, written in plain English, owned by a named role (a Govern output). Example: *"No agent may access production data without human approval; high-risk tool calls require a second reviewer."* 2. **Control** — the policy compiled to an enforceable rule (a B2–B8 control or a B11.3 policy-as-code rule). Example: a rule that matches `(surface == 'production_data')` and requires `approval.state == 'approved'`, and a rule that matches `(tool.risk == 'high')` and requires `approval.reviewers >= 2`. 3. **Test** — a B9/B10 test that verifies the control fires correctly (a Measure output). Example: a test that proposes a production-data access without approval and asserts the control DENIES; a test that proposes a high-risk tool call with one reviewer and asserts the control ESCALATES. 4. **Audit** — the audit-trail entry emitted by the control's evaluation at runtime (a Manage output). Example: every evaluation writes `{policy_id, action, decision, reason, timestamp}` to the append-only audit trail. The four stages form a loop, not a pipeline. A policy change (Govern) propagates to a control update, a test update, and an audit-trail schema update. A test failure (Measure) propagates back to a control fix and a policy clarification. The loop is the governance system operating; a static policy document is the loop frozen at stage 1. ## The two reference implementations This pattern has two production references in Course 1's deep dives: - **DD-20 IronCurtain — deterministic policy compilation.** IronCurtain's signature contribution is the *constitution pipeline*: you write policy in plain English in a `constitution.md`, an offline LLM pipeline compiles it to deterministic JSON rules, and at runtime enforcement is pure if/then evaluation — **zero LLM at runtime.** The LLM is a build-time tool; the enforcement is deterministic. This is the architecturally pure policy-as-code pattern: the policy is human-readable, the enforcement is machine-certain, and the two are connected by a verifiable compilation step. The policy-as-code engine in this module's lab is a simplified IronCurtain. - **DD-09 NemoClaw — governance beneath the agent.** NemoClaw's contribution is 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's 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 (human-readable, 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 (B11.2). That is the governance-to-engineering bridge, end to end. ## The policy-as-code engine (code) The engine takes an action the agent proposes, evaluates it against the policy, and produces a decision plus an audit-trail entry. Type-hinted, runnable, no GPU. ```python from __future__ import annotations from dataclasses import dataclass, asdict from datetime import datetime, timezone from enum import Enum from typing import Any, Callable class Decision(str, Enum): ALLOW = "ALLOW" DENY = "DENY" ESCALATE = "ESCALATE" # require human approval @dataclass(frozen=True) class AgentAction: """An action the agent proposes to take. Evaluated by the policy engine.""" agent_id: str model_version: str tool: str # e.g. 'query_prod_db', 'send_email', 'run_code' arguments: dict[str, Any] # tool-specific; data-class redacted before logging surface: str # 'production_data' | 'internal_api' | 'sandbox' | ... risk_tier: str # 'low' | 'medium' | 'high' (from B3 tool governance) @dataclass(frozen=True) class PolicyRule: """One governance policy, compiled to a deterministic rule. The plain-English policy lives in a constitution.md; this is the compiled form (cf. IronCurtain's deterministic policy compilation, DD-20).""" policy_id: str # stable id, referenced from the audit trail description: str # the human-readable policy text (Govern output) matches: Callable[[AgentAction], bool] # does this rule apply to this action? decide: Callable[[AgentAction], Decision] # what does it require? @dataclass(frozen=True) class AuditEntry: """The evidence that a policy was evaluated at runtime. Append-only.""" timestamp: str # UTC ISO 8601 policy_id: str agent_id: str model_version: str action_summary: dict[str, Any] # redacted: no PII, no secrets (B0 retention discipline) decision: str reason: str class PolicyEngine: """Evaluates an agent action against the policy set and emits an audit entry. This sits in the harness execution path — every tool call passes through it (cf. NemoClaw's governance-beneath-the-agent, DD-09). It is NOT in the agent process; a compromised agent cannot disable it.""" def __init__(self, rules: list[PolicyRule], audit_sink: Callable[[AuditEntry], None]) -> None: self._rules = rules self._audit = audit_sink def evaluate(self, action: AgentAction) -> tuple[Decision, str]: for rule in self._rules: if rule.matches(action): decision = rule.decide(action) reason = f"{rule.policy_id}: {rule.description}" self._emit_audit(action, rule, decision, reason) return decision, reason # default-deny: an action no rule matches is not permitted decision, reason = Decision.DENY, "no policy matched; default-deny" self._emit_audit(action, None, decision, reason) return decision, reason def _emit_audit(self, action: AgentAction, rule: PolicyRule | None, decision: Decision, reason: str) -> None: entry = AuditEntry( timestamp=datetime.now(timezone.utc).isoformat(), policy_id=rule.policy_id if rule else "UNMATCHED", agent_id=action.agent_id, model_version=action.model_version, action_summary=self._redact(action), decision=decision.value, reason=reason, ) self._audit(entry) # append-only sink; tamper-evident in production @staticmethod def _redact(action: AgentAction) -> dict[str, Any]: # B0 retention discipline: log the shape, not the content, for sensitive surfaces if action.surface == "production_data": return {"tool": action.tool, "surface": action.surface, "arg_keys": sorted(action.arguments.keys())} return {"tool": action.tool, "surface": action.surface, "arguments": action.arguments} # --- Sample policy set (compiled from a constitution.md) --- RULES: list[PolicyRule] = [ PolicyRule( policy_id="P-001", description="No agent may access production data without human approval", matches=lambda a: a.surface == "production_data", decide=lambda a: Decision.ESCALATE, # force human approval ), PolicyRule( policy_id="P-002", description="High-risk tool calls require a second reviewer", matches=lambda a: a.risk_tier == "high", decide=lambda a: Decision.ESCALATE, ), PolicyRule( policy_id="P-003", description="Sandboxed code execution is permitted without approval", matches=lambda a: a.surface == "sandbox", decide=lambda a: Decision.ALLOW, ), ] # --- Usage --- def console_sink(entry: AuditEntry) -> None: print(f"[AUDIT] {entry.timestamp} {entry.policy_id} {entry.decision} {entry.reason}") engine = PolicyEngine(RULES, console_sink) # Action 1: sandbox run -> ALLOW a1 = AgentAction("agent-7", "claude-opus-4-1-20260605", "run_code", {"language": "python"}, "sandbox", "low") print(engine.evaluate(a1)) # (Decision.ALLOW, 'P-003: ...') # Action 2: production DB query -> ESCALATE (requires human approval) a2 = AgentAction("agent-7", "claude-opus-4-1-20260605", "query_prod_db", {"sql": "SELECT * FROM users"}, "production_data", "high") print(engine.evaluate(a2)) # (Decision.ESCALATE, 'P-001: ...') ``` Three things to notice in this engine. 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's retention discipline at the audit layer. This is the governance-to-engineering bridge in ~80 lines. The lab has you extend this engine: add an approval-state check (the ESCALATE decision blocks until an approval is recorded), add the AI BOM as a policy input (a rule that DENIES any tool not in the AI BOM), and wire the audit entries to a tamper-evident store. --- ## Anti-Patterns ### "The policy is in the wiki" A governance policy written in a document and not enforced in code is a policy that does not exist at runtime. The agent will do what its tools permit, wiki or no wiki. Cure: policy-as-code — every governance policy compiles to a rule enforced in the harness execution path, and every evaluation emits an audit-trail entry. ### Policy enforcement inside the agent process A policy engine that runs as a tool the agent calls, or a system-prompt instruction the agent follows, is a policy engine a prompt injection can disable or bypass. Cure: governance beneath the agent (DD-09 NemoClaw) — the engine sits in the execution path between agent and world, where the agent cannot reach it. ### An AI BOM maintained by hand A wiki-maintained AI BOM drifts from reality the moment a dependency is updated or a tool is added. Cure: generate the AI BOM from the running system — read the model version from the API, the tool list from the harness registry, the dependencies from the SBOM tooling. The generator, not the wiki, is the source of truth. ### Sampling observability passed off as an audit trail An observability dashboard that samples 1% of events is useful for engineering and useless for compliance. An audit trail must be complete and retained. Cure: separate the two systems — observability for engineering (B8, sampled), audit trail for compliance (B11.2, complete, append-only). ### Treating the RMF mapping as a paperwork exercise Mapping controls to Govern/Map/Measure/Manage in a spreadsheet, without the underlying controls being measured and the audit trail being complete, is governance theater. Cure: the mapping is evidence-backed — every Map claim references an AI BOM, every Measure claim references a test result, every Manage claim references an audit-trail entry. ### Default-allow policy engines A policy engine that allows any action no rule matches is an engine that fails open. A missing policy becomes a permission. Cure: default-deny. An unmatched action is DENIED with reason "no policy matched" until a rule is added. --- ## Key Terms | Term | Definition | | --- | --- | | **NIST AI RMF (AI 100-1)** | The NIST AI Risk Management Framework (2023); voluntary, four core functions (Govern, Map, Measure, Manage); the de facto US AI governance standard | | **Govern / Map / Measure / Manage** | The RMF's four core functions — policy/accountability, context/risk surface, test/evaluate, mitigate/respond — operating as a continuous loop | | **NIST AI 600-1 (Generative AI Profile)** | The 2024 companion to RMF 1.0; enumerates twelve GenAI risk categories (CBRN, Confabulation, Dangerous Content, Data Privacy, Human-AI Configuration, Information Integrity, Information Security, IP, Bias/Homogenization, Obscene Content, Provenance, Environmental) and ~200 suggested actions | | **CSA Agentic NIST AI RMF Profile** | The Cloud Security Alliance's agent-specific extensions to RMF 1.0, organized by function; addresses agent identity, authorization, and autonomy scope; the near-term agent-governance implementation guide | | **NIST CAISI** | NIST's Center for AI Agent Standards and Identity (announced Feb 2026); the long-arc standards work on agent interoperability, security, and openness | | **ISO/IEC 42001:2023** | The certifiable AI management system standard; the ISO 9001 equivalent for AI; ten clauses plus thirty-eight Annex A controls; third-party audited on a three-year cycle; interoperable with the RMF (NIST published an official crosswalk) | | **EU AI Act risk tiers** | Six tiers — Unacceptable (prohibited), High Risk (Annex III, conformity), Limited Risk (transparency), Minimal Risk (voluntary), GPAI (transparency), GPAI with Systemic Risk (>10^25 FLOPs, model evals) — determining which obligations apply to a deployment | | **AI BOM (AI Bill of Materials)** | The SBOM extended to AI — an inventory of the model, training data sources, tools/MCP servers, dependencies, config, and external services; the precondition for auditability | | **Audit trail** | The append-only, complete record of agent decisions, tool calls, approvals, model versions, and policy evaluations; the evidence that controls are enforced, not just documented | | **Policy-as-code** | Governance policy expressed as machine-evaluable rules enforced in the harness execution path; the policy → control → test → audit lifecycle | | **Governance-to-engineering bridge** | The four-stage loop (policy → control → test → audit) that connects governance statements to enforceable, evidenced controls | | **EU AI Act compliance engineering** | The technical implementation of the AI Act's obligations — Annex IV documentation, Article 12 logging, Article 14 human oversight — the RMF made mandatory | | **Default-deny** | A policy-engine design where an action no rule matches is DENIED; the failure mode of a missing policy is safety, not openness | | **Governance beneath the agent** | The architectural principle (DD-09 NemoClaw) that enforcement lives in the harness execution path, not the agent process — a compromised agent cannot disable it | --- ## Lab Exercise See `07-lab-spec.md`. Three builds in one lab: (1) an **AI BOM generator** that reads a sample agent's model version, tool registry, dependencies, and config, and emits a machine-readable AI BOM; (2) the **policy-as-code engine** that evaluates agent actions against a constitution-derived policy set, with default-deny and redaction, emitting an audit-trail entry for every evaluation; (3) an **audit-trail writer** with append-only semantics and hash-chaining for tamper-evidence. No GPU, runnable in Python 3.10+, ~60–75 minutes. This lab produces the three artifacts a governance review asks for first. --- ## References 1. **NIST AI 100-1 (2023)** — Artificial Intelligence Risk Management Framework (AI RMF 1.0). The four core functions (Govern, Map, Measure, Manage). `nist.gov/itl/ai-risk-management-framework` 2. **NIST AI RMF Generative AI Profile (NIST AI 600-1, 2024)** — the GenAI-specific risk profile that extends the RMF to generative AI systems, including agents. 3. **NIST AI GEC (Generative AI Public Working Group) outputs** — the consensus documents behind the GenAI profile; the multi-stakeholder process that produced the RMF extension. 4. **ISO/IEC 42001:2023** — Artificial Intelligence Management System standard. Certifiable; interoperable with the RMF. 5. **Regulation (EU) 2024/1689** — EU AI Act. Annex IV (technical documentation), Article 12 (logging), Article 14 (human oversight): the compliance-engineering requirements. 6. **CSA Agentic NIST AI RMF Profile (v1)** — Cloud Security Alliance; extensions to RMF 1.0 organized by function, tailored for AI agents; the agent-specific governance profile. Companion: CSA AI Controls Matrix (AICM) mapped to NIST AI 600-1 (March 2026, 243 controls). `labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1/` 7. **NIST AI RMF to ISO/IEC 42001 Crosswalk** — NIST AI Resource Center; the official mapping of the RMF's four functions to 42001's clauses and Annex A controls; the interoperability document. `airc.nist.gov/docs/NIST_AI_RMF_to_ISO_IEC_42001_Crosswalk.pdf` 8. **CLTC Berkeley — Agentic AI Risk Profile** — Center for Long-Term Cybersecurity, UC Berkeley; the academic companion structuring agent-specific risks (chain-of-action, principal-agent, authorization-delegation) around the Govern/Map/Measure/Manage loop. 9. **NIST CAISI (Center for AI Agent Standards and Identity)** — NIST's agent-standards initiative (announced February 2026); three pillars (interoperability, security, openness); the long-arc agent-identity and authorization standards work. 10. **NTIA Minimum Elements for an SBOM (2021)** + **CISA SBOM** work — the SBOM foundation the AI BOM extends. 11. **HIPAA Security Rule, 45 C.F.R. § 164.312(b)** — audit controls standard; the sector requirement an AI audit trail in healthcare must satisfy. 12. **Course 1 DD-20 (IronCurtain)** — deterministic policy compilation; the plain-English-to-JSON constitution pipeline; zero LLM at runtime. The architecturally pure policy-as-code reference. 13. **Course 1 DD-09 (NemoClaw)** — governance beneath the agent; NeMo Guardrails in the execution path; the agent cannot reach the enforcement layer. The architectural-placement reference. 14. **Course 2B B4 (Supply Chain)** — the SBOM and supply-chain controls the AI BOM extends. 15. **Course 2B B8 (Observability)** — the engineering capability the audit trail is the compliance evidence of. 16. **Course 2B B12 (Assessment as a Service)** — the module that operationalizes the governance layer (including the AI BOM) as a packaged assessment.