Governance & Compliance

Module B11 · Course 2B — Securing & Attacking Harnesses and LLMs

60 minutes · Where enterprise budgets and board attention actually move

B2–B8 built the technical controls. They are necessary but not sufficient. This module is where a control you built becomes the control an auditor signs off on, the AI BOM procurement accepts, and the audit trail a regulator reads.

Pillar 4 — Frameworks & Governance

The governance gap

You can attack and defend an agent at a level most teams cannot. None of that ships the agent.

Engineering review

Won by technical security — B2–B8. The guardrail works. The injection rate dropped 60% → 4%. Sufficient for the demo.

Enterprise / governance review

Won by frameworks — NIST AI RMF, ISO 42001, EU AI Act. The CISO, governance council, and board release budget and approval against these, not against a working guardrail.

These are not the same activity. An agent with a 4% injection rate and no AI BOM, no audit trail, and no policy-as-code layer will not clear enterprise governance — and an agent with weaker controls but a complete governance stack will ship first.

B11.1 — The governance frameworks

NIST AI RMF + the landscape

NIST AI RMF — the four core functions

Function	What it asks	B2–B8 control that answers
GOVERN	Who owns the risk? What policy applies?	Policy-as-code layer (B11.3); scope file (B0)
MAP	What is the system? What can go wrong?	Threat model (B1); AI BOM (B11.2)
MEASURE	Have we tested it? Residual risk?	Injection rates (B2); OWASP (B9); MSFT (B10)
MANAGE	Controls deployed? How do we respond?	Tool governance (B3); sandbox (B6); obs (B8)

The loop, not the pipeline. A continuous loop — Govern is the foundation underneath, Map→Measure→Manage operate on top. Residual risk that exceeds tolerance goes back to Map (re-scope) or Govern (re-policy).

Voluntary in law, mandatory in practice

The RMF carries no penalties. And yet it is the de facto US AI governance standard.

OMB M-24-10 requires US federal agencies to implement the RMF — vendors selling to those agencies inherit the requirement.
Insurers underwriting AI liability policies ask for RMF alignment.
Enterprise governance councils map their AI programs against it because it's the framework their auditors read.

The working control and the documented mapping are both required. 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 compliance frameworks landscape

Framework	What it is	When it applies
NIST AI RMF	Voluntary, US, non-sector	Default framework to map to
ISO/IEC 42001:2023	Certifiable AI management system standard	When certification is a procurement requirement
EU AI Act (eng.)	Annex IV docs · Art 12 logging · Art 14 oversight	EU market — the RMF made mandatory
HIPAA / FedRAMP / SOX	Sector rules layered on top	Healthcare / government / finance
CSA NIST AI Agent Standards (2026)	CAISI initiative + CSA compliance mapping	The live agent-specific reference

Two artifacts all of them ask for first: the AI BOM and the audit trail.

B11.2 — The AI BOM & the audit trail

The two artifacts a regulator asks for first

The AI BOM — SBOM extended to AI

AI-specific (the extension)

Model (provider, checkpoint, license) · training data (sources, provenance, PII) · system prompt & config (versions, hashes)

SBOM surface (extended)

Tools / MCP servers (endpoints, capability scope) · frameworks & SDKs (the dependency list) · external services (APIs, vector DB, identity)

An agent without an AI BOM cannot be audited. A vulnerability in a dependency cannot be traced to the agents that include it. A model-version dispute cannot be resolved. A compliance assertion cannot be evidenced. A change cannot be governed.

Generated from the running system, not maintained in a wiki — a wiki and reality drift, and the auditor reads reality.

The audit trail — evidence controls are enforced

Event class	Fields
Agent decision	timestamp, agent id, model version, decision, rationale
Tool call	tool, redacted args, result class, outcome
Approval	approval id, approver, policy reference, decision
Model version	model id, checkpoint, sampled at decision time
Policy evaluation	policy id, action, decision (ALLOW/DENY), reason
Data access	surface, data class, record count (not content)

Complete, not sampled. An observability dashboard that logs 1% of events is useful for engineering and useless for compliance. EU AI Act Art 12 and HIPAA § 164.312(b) both require the logs to exist, be complete, and be retained.

B11.3 — Policy-as-code

The governance-to-engineering bridge

The policy → control → test → audit loop

1. POLICY (Govern)         "no agent may access prod data
                            without human approval"
        │  policy-as-code compiles
        ▼
2. CONTROL (B2-B8/B11.3)   matches (surface == 'production_data')
                            requires approval.state == 'approved'
        │
        ▼
3. TEST (Measure, B9/B10)  propose access w/o approval
                            assert control DENIES
        │
        ▼
4. AUDIT (Manage, B11.2)   {policy_id, action, decision, reason,
                             timestamp, model_version}

A policy that stops at stage 1 is the wiki — no runtime effect. The loop, not the pipeline. A test failure propagates back to a control fix; a policy gap propagates back to re-policy.

Two reference implementations

DD-20 IronCurtain — deterministic policy compilation.
Plain-English constitution.md → offline LLM compiles → deterministic JSON rules. Zero LLM at runtime. The LLM is a build-time tool; enforcement is pure if/then.

DD-09 NemoClaw — governance beneath the agent.
Enforcement sits in the execution path between agent and world. The agent cannot reach it to disable it. Policy inside the agent process is policy a prompt injection turns off.

The synthesis: write policy in plain English (human-readable, Govern-owned); compile to deterministic rules (IronCurtain); enforce in the harness execution path (NemoClaw); emit an audit-trail entry for every evaluation. That is the bridge, end to end.

The policy-as-code engine

class Decision(Enum): ALLOW · DENY · ESCALATE

engine = PolicyEngine(RULES, audit_sink)
engine.evaluate(action)
# → (Decision.ESCALATE, "P-001: no agent may access
#     production data without human approval")
# → audit entry emitted: {policy_id, action, decision,
#     reason, timestamp, model_version}

Three properties to notice: (1) default-deny — an unmatched action is DENIED, not allowed; the failure mode of a missing policy is safety. (2) audit on every evaluation, including the default-deny — the evidence is captured. (3) policy-aware redaction — production-data surfaces log arg keys, not values (B0 retention discipline).

The load-bearing principle

Technical security wins the engineering review; governance wins the enterprise review. The agent with a 4% injection rate and no governance layer does not ship. The agent with weaker controls and a complete AI BOM, audit trail, and policy-as-code engine ships first. The budget and the board attention follow the governance layer — build it.

B12 packages this layer as an assessment service: the AI BOM, the audit trail, the RMF mapping, delivered as one engagement. The framework is what makes the technical work sellable, fundable, and defensible.

Lab & what's next

Lab (07): build the three governance artifacts — an AI BOM generator that reads a sample agent; the policy-as-code engine with default-deny and redaction; an audit-trail writer with append-only semantics and hash-chaining. No GPU, ~60–75 min.

Next — B12: Harness Security Assessments as a Service. B12 packages the governance layer from B11 with the red-team methodologies from B9/B10 into a single deliverable engagement. The AI BOM, the audit trail, and the RMF mapping become the product.