Lab 15 · AI Risk Register + Acceptable-Use Policy

This is pure GRC — no exploit, no scan — because the skill it trains is the one that closes the loop on every other lab in this track: translating technical AI risk into governance language that leadership signs, auditors verify, and legal defends. You will optionally use Claude to draft register entries into a schema-enforced structure, but every mapping and control is your judgment call.

Time & tier

~90 minutes, no exploitation · Core tier (maps to module M8 — AI governance, risk & compliance). Runs at ₹0: the frameworks (NIST AI 600-1, OWASP LLM Top 10, DPDP Act/Rules) are free to read; the optional draft step uses Claude at a few paise, or you can write the register by hand.

Setup

No install required for the paper artifact. For the optional AI-assisted drafting step:

pip install anthropic pydantic

Pick one real AI feature to govern — ideally one from an earlier lab so the risks are concrete. A good default: the "internal help-desk assistant over a private KB" (the RAG app from Lab 10, or the support copilot from Lab 09). Write its one-paragraph description in feature.md: what it does, what data it touches (KB contents, user queries, any PII), who uses it, and what it can act on. That description is the input to both artifacts.

Guided steps

1. 1.

   Frame the register columns. A register entry auditors accept has, at minimum: risk_id, description, the NIST AI RMF function it falls under (Govern / Map / Measure / Manage), the OWASP LLM Top-10 category it corresponds to, likelihood, impact, a concrete mitigation, and an owner. Lay these as columns in risk-register.md.

2. 2.

   Enumerate risks from the actual attack surface. Don't invent generic risks — derive them from what the earlier labs proved. For the help-desk assistant you should capture at least six: indirect prompt injection via KB/ticket content (LLM01), sensitive-information disclosure of KB PII (LLM02), insecure output handling into a downstream sink (LLM05), RAG data poisoning (LLM04), system-prompt leakage (LLM07), and excessive agency if it can act (LLM06). Each is a lab you've done — the register is where you record that you tested it.

3. 3.

   Map each risk to NIST AI RMF and score it. For every entry, assign the NIST function (most technical controls are Manage; establishing the policy itself is Govern; identifying the risk is Map; the red-team metric is Measure) and rate likelihood/impact Low/Medium/High with a one-line justification. A prompt-injection risk on a KB fed by user-editable content is High/High; a leakage risk behind strong output filtering might be Low/Medium.

4. 4.

   Write real mitigations that point at your controls. The mitigation column is where governance meets the rest of the track: for prompt injection, cite the trust-zone split and taint gates from Lab 09; for poisoning, the provenance filter from Lab 10; for output handling, the encoding + egress allowlist from Lab 11; for excessive agency, the permission matrix from Lab 12; for the whole set, the CI-gated red-team suite from Labs 13–14. A register whose mitigations are real, tested controls is worth ten times one full of "we will monitor."

5. 5.

   Optional — draft entries with schema-enforced structure. To accelerate (and to demonstrate structured outputs to auditors), have Claude draft register entries into a Pydantic schema so the output is validated, not free prose. Save draft_register.py:

   Copy

   import anthropic
   from pydantic import BaseModel
   from typing import Literal
   
   class RiskEntry(BaseModel):
       risk_id: str
       description: str
       nist_ai_rmf: Literal["Govern", "Map", "Measure", "Manage"]
       owasp_llm: str                       # e.g. "LLM01:2025 Prompt Injection"
       likelihood: Literal["Low", "Medium", "High"]
       impact: Literal["Low", "Medium", "High"]
       mitigation: str
       owner: str
   
   class RiskRegister(BaseModel):
       feature: str
       entries: list[RiskEntry]
   
   feature = open("feature.md").read()
   client = anthropic.Anthropic()
   resp = client.messages.parse(
       model="claude-opus-4-8",
       max_tokens=2000,
       thinking={"type": "adaptive"},
       system=("You are a GRC analyst. Draft an AI risk register for the feature. "
               "Map each risk to a NIST AI RMF function and an OWASP LLM Top-10 "
               "category. Propose concrete, testable mitigations — never 'monitor'. "
               "You draft; the human owner approves every entry."),
       messages=[{"role": "user", "content": feature}],
       output_format=RiskRegister)
   reg = resp.parsed_output
   for e in reg.entries:
       print(f"{e.risk_id}  {e.owasp_llm:32} {e.nist_ai_rmf:7} "
             f"{e.likelihood}/{e.impact}  owner={e.owner}")
   

   The Literal enums make "the model invented a NIST function" an impossible state — the response is schema-valid or it errors. Treat the draft as a first pass you correct, never as the final register; you own every entry.

6. 6.

   Write the one-page AUP. In acceptable-use-policy.md, keep it to a page a non-lawyer will actually read, with these sections: (a) Scope — which AI tools and which data classes; (b) Permitted use — approved endpoints only, e.g. client-sanctioned tenancy or local models for sensitive data; (c) Prohibited use — no pasting client PII/secrets/source into unapproved public tools; (d) Data handling — data-minimization and redaction before prompting, tied to DPDP purpose-limitation and security-safeguard duties; (e) Human accountability — a named human owns every AI-assisted decision and every agent action; (f) Incident reporting — reconcile the two India clocks explicitly: CERT-In's 6-hour reporting rule and the DPDP Board's 72-hour rule; (g) Review cadence — the policy is reviewed on a schedule and after any incident. Note the ISO 42001 alignment: the AUP is one control artifact of an AI Management System, referenced by your register's Govern entries.

7. 7.

   Close the governance loop. Add a final risk-register.md note stating how the register stays live: each mitigation links to a lab/control and its CI test (Labs 13–14), so a failing red-team build is also a risk-register status change. That link — technical test to governance record — is what makes the register a living control rather than a document written once for an audit.

Verification

• •
  risk-register.md has ≥6 entries, each with a NIST function, an OWASP LLM category, likelihood/impact with justification, a concrete mitigation, and a named owner.
• •
  Every mitigation names a specific control (from Labs 09–14), not a vague intention.
• •
  acceptable-use-policy.md fits one page and covers all seven sections, including both the CERT-In 6-hour and DPDP 72-hour clocks.
• •
  If you ran the draft step, the output validated against the Pydantic schema (no invented NIST functions).

Completion artifact

The governance pack: feature.md, risk-register.md, acceptable-use-policy.md, and optionally draft_register.py. Self-grading rubric (pass = 8/10):

• Register completeness (0–3): ≥6 risks derived from the real attack surface, each dual-mapped to NIST AI RMF + OWASP LLM Top 10 = 3.
• Mitigation quality (0–3): every mitigation cites a specific, tested control, not "monitor/review" = 3.
• AUP realism (0–2): one page, all seven sections, DPDP-aware with both incident clocks reconciled = 2.
• Living-control link (0–2): register mitigations tied to CI red-team tests so a failing build changes register status = 2.

Stuck?

• Register feels generic: you're inventing risks instead of deriving them from the labs. Every OWASP LLM category you defended in Labs 09–14 is one register row with a real mitigation.
• Unsure which NIST function applies: identifying/contextualizing a risk is Map; the control that reduces it is Manage; the metric that tracks it (bypass rate, poisoning rate) is Measure; the policy/ownership around it is Govern.
• AUP ballooning past a page: move detail into the register and keep the AUP to rules and responsibilities; a policy no one finishes reading is not enforced.
• DPDP timeline confusion: DPDP Rules 2025 were notified 14 Nov 2025; substantive Data Fiduciary obligations are enforceable from 13 May 2027 — but CERT-In's 6-hour incident rule already applies; cite both clocks and their sources.

Client-safe variant

This lab is inherently client-safe — no data, no live system, only governance documents you can fully anonymize. On a services engagement it is often the billable deliverable: map the client's real AI feature to NIST AI RMF and OWASP LLM Top 10, and produce a DPDP-aware, ISO-42001-aligned AUP their legal and security teams adopt. Redact client identifiers in feature.md, and if you use the AI-draft step, route it through the client's sanctioned endpoint rather than the public API so even the feature description never leaves their boundary. The register-plus-AUP pack is exactly what a client's AI-governance owner (the "Elena" persona) needs to satisfy auditors and Fortune-500 vendor-security requirements.

Answer key (don't read before attempting)

1. 1The strongest register maps to controls, not intentions: the difference between a passing and failing register is the mitigation column. "Monitor for prompt injection" is worthless; "trust-zone split + taint gates (Lab 09), regression-tested in CI (Lab 13)" is a control an auditor can verify. Learners who write aspirational mitigations have produced an audit prop, not a risk-management tool.
2. 2Dual mapping is deliberate: NIST AI RMF gives leadership/auditors the governance vocabulary (Govern/Map/Measure/Manage lifecycle); OWASP LLM Top 10 gives engineers the technical vocabulary. Mapping each risk to both is what lets the same register serve a board committee and a dev team — the core GRC-translation skill.
3. 3The two-clock reconciliation is the India-specific trap: many learners cite only DPDP's 72-hour Board notification and miss that CERT-In's 6-hour directive already binds Indian entities today. An AUP that names one clock and not the other is non-compliant; the correct artifact reconciles both and says which applies to what.
4. 4What this lab does NOT include: no live system or data — it is a pure paper artifact by design, the governance capstone that references the tested controls from Labs 09–14. The optional draft step's messages.parse call and Pydantic schema were validated for shape (model claude-opus-4-8, adaptive thinking, no forbidden sampling params); the register content itself is your judgment, which is exactly the point of a GRC exercise.