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: ...')

# Module B11 — Governance and Compliance

**Course**: 2B — Securing & Attacking Harnesses and LLMs
**Module**: B11 — Governance and Compliance
**Duration**: 60 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, twenty minutes each:

- **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. The compliance landscape: NIST AI RMF (US, voluntary but de facto), EU AI Act compliance engineering (B0 covered the law; here we cover the engineering), ISO 42001 (the AI management system standard), sector frameworks, and the CSA NIST AI Agent Standards mapping.
- **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.

## 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 |
| **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 |
| **ISO/IEC 42001:2023** | The certifiable AI management system standard; the ISO 9001 equivalent for AI; interoperable with the RMF |
| **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 Research Notes — NIST AI Agent Standards (2026)** — Cloud Security Alliance mapping of NIST CAISI's AI Agent Standards Initiative (announced Feb 2026) onto enterprise governance obligations; the live 2026 reference for agent-specific compliance. `labs.cloudsecurityalliance.org`
7. **NTIA Minimum Elements for an SBOM (2021)** + **CISA SBOM** work — the SBOM foundation the AI BOM extends.
8. **HIPAA Security Rule, 45 C.F.R. § 164.312(b)** — audit controls standard; the sector requirement an AI audit trail in healthcare must satisfy.
9. **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.
10. **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.
11. **Course 2B B4 (Supply Chain)** — the SBOM and supply-chain controls the AI BOM extends.
12. **Course 2B B8 (Observability)** — the engineering capability the audit trail is the compliance evidence of.
13. **Course 2B B12 (Assessment as a Service)** — the module that operationalizes the governance layer (including the AI BOM) as a packaged assessment.