This document indexes the nine lessons in Chapter 5. Every entry traces to source material you've already read. Use the reference block at the end to locate the originating lesson. Where content is genuinely new, it's flagged.
Risk Categories and Ownership
Threat Exposure
Prompt Injection (OWASP LLM01) — An attacker manipulates an LLM's behavior by embedding instructions in user input or retrieved content, overriding system-level directives at runtime. When it comes up: When a CISO asks how your AI system handles untrusted input — especially in RAG architectures where retrieved documents become part of the prompt context. Don't confuse with: Jailbreaking. Jailbreaks target training-level guardrails. Prompt injection targets the runtime context. Both produce policy violations; they require different mitigations and different owners.
Sensitive Information Disclosure (OWASP LLM02) — An LLM surfaces training data, system prompt contents, or user-session material it was not authorized to reveal. When it comes up: In HIPAA and GLBA conversations — specifically when a buyer asks whether the model was trained on customer data and whether that data can be reconstructed from outputs. Don't confuse with: Infrastructure-layer data leakage. LLM02 is model-level exposure. Infrastructure leakage is a separate control domain with a different owner and different remediation path.
Excessive Agency (OWASP LLM06) — An AI agent takes actions beyond its authorized scope — writing to external systems, triggering downstream workflows, or escalating privileges — without explicit human approval. When it comes up: Any agentic deployment conversation. This is the risk that maps most directly to least-privilege principles your buyer already holds, and the one CAIOs cite most often when explaining why autonomous AI makes them nervous. Don't confuse with: Scope creep in a project management sense. Excessive Agency is a runtime authorization failure. The mitigation is architectural — constrained tool access and human-in-the-loop checkpoints — not contractual.
Supply Chain Vulnerabilities (OWASP LLM03) — Risk introduced through third-party model providers, fine-tuning datasets, plugins, or orchestration frameworks outside the deploying organization's control. When it comes up: FedRAMP authorization conversations. The question is whether the AI system's dependencies — model API, vector store, embedding provider — are themselves within an authorized boundary. Don't confuse with: Vendor risk management in the conventional software sense. LLM supply chain includes training data provenance, which has no equivalent in traditional software procurement and no established audit standard yet.
Unbounded Consumption (OWASP LLM10) — An AI system consumes compute, API quota, or financial resources without rate limits, enabling denial-of-service conditions or runaway cost exposure. When it comes up: SOC 2 availability conversations and any customer-facing deployment where the buyer operates in a cost-sensitive cloud environment. Don't confuse with: Performance SLAs. Unbounded Consumption is a security control gap. It belongs in the risk register under the security owner, not in the service agreement under the operations team.
If you remember nothing else from this section: Each OWASP LLM exposure requires a named owner. "Security owns AI risk" is not an ownership model — it's a gap.
Regulatory Classification
EU AI Act Tier — The risk classification assigned to an AI system under the EU AI Act: Unacceptable Risk (prohibited), High Risk (Article 6/Annex III), Limited Risk (transparency obligations), or Minimal Risk (no mandatory requirements). When it comes up: Any European public sector opportunity, and increasingly in US federal conversations where buyers are using EU AI Act tiers as a proxy classification framework ahead of domestic regulation. Don't confuse with: NIST AI RMF risk levels. The frameworks overlap but don't map cleanly. A system can be High Risk under the EU AI Act and sit at a different position on the NIST RMF impact scale. Treat them as parallel classifications, not synonyms.
FedRAMP Authorization Boundary — The defined set of system components, services, and data flows in scope for a FedRAMP authorization. For AI systems, this boundary must explicitly include model APIs, vector stores, and any third-party orchestration layer. When it comes up: Every federal AI deployment conversation. If the AI system's components aren't within an authorized boundary, the system isn't deployable in a federal environment regardless of its capabilities or the agency's enthusiasm. Don't confuse with: ATO (Authority to Operate). FedRAMP is the authorization program; ATO is the agency-level decision to operate within that program. An AI system can be FedRAMP-authorized and still require a separate agency ATO before first use.
If you remember nothing else from this section: EU AI Act tier is the classification your buyer will use to decide whether to deploy — not just whether to comply. It belongs in the register before the procurement conversation, not after.
Governance Mechanisms
AI Risk Register — A structured artifact that names each AI system in scope, classifies it against applicable regulations, maps OWASP LLM exposures to current mitigations, and assigns an accountable owner per risk category. When it comes up: CISO and legal discovery conversations. When a buyer asks "how do you govern AI risk," the register is the answer — not a policy document, not a vendor attestation. Don't confuse with: A model card. Model cards document model behavior and training characteristics. The risk register documents organizational accountability and control coverage. Both are required; neither substitutes for the other.
Audit Trail Requirements — The obligation to log AI system inputs, outputs, decisions, and human overrides in a format that supports post-incident review and regulatory examination. When it comes up: HIPAA audit controls, SOC 2 Type II evidence collection, and EU AI Act Article 12 logging requirements for high-risk systems. Buyers in regulated sectors will ask specifically whether AI-generated outputs are logged and attributable to a session and a user. Don't confuse with: Model explainability. Audit trails document what happened. Explainability addresses why the model produced a given output. Regulators increasingly require both, and they require different technical implementations with different owners.
If you remember nothing else from this section: Named owners are what separate a governance program from a document that satisfies nobody. The register earns its authority from the names in the owner column.
Vocabulary Collision Tables
Three zones where AI and IDAM communities use the same word to mean different things. Misalignment here is where discovery conversations go sideways.
Table 1: Token
| AI Term | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Token | A unit of text (roughly ¾ of a word) that LLMs process; also the pricing and context-limit metric for model APIs | OAuth bearer token: a credential that grants access to a protected resource, with defined lifetime and revocation | AI tokens are stateless text fragments with no security properties. OAuth tokens carry authorization claims and expire by policy. Okta's token introspection endpoint governs OAuth tokens — it has no visibility into LLM token consumption. Using "token" interchangeably in a security architecture conversation produces immediate confusion about what's being protected and by whom. |
Table 2: Session
| AI Term | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Session / Context Window | The bounded memory an LLM holds within a single conversation — typically 8K to 200K tokens; everything outside this window is invisible to the model | An authenticated session: a stateful record of a user's authenticated state, with defined timeout, idle limits, and revocation mechanisms | LLM context windows don't authenticate. They don't expire via policy. They can't be revoked mid-conversation. A user whose IDAM session is terminated may still have an active LLM context containing sensitive data. These are separate control planes requiring separate governance. |
Table 3: Scope
| AI Term | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Scope (EU AI Act) | The risk classification tier that determines which compliance obligations apply — driven by use case, deployment context, and affected population | OAuth scope: a permission boundary that limits what an access token can do within a defined API surface, negotiated between client and resource server | EU AI Act scope is assigned by regulators based on use-case risk. OAuth scope is defined by the resource server and requested by the client. One is assigned externally; one is negotiated internally. Conflating them produces incorrect assumptions about who controls the boundary and who can change it. |
One-Page AI Risk Register Template
One row per AI system. Populate before deployment; update at each material change or regulatory trigger.
| Field | Description / Guidance |
|---|---|
| System Name | Canonical name used in procurement and architecture documentation |
| System Description | One sentence: what it does, who uses it, what data it touches |
| EU AI Act Tier | Unacceptable / High Risk / Limited Risk / Minimal Risk — cite the Annex III category if High Risk |
| Applicable Sector Regulations | Check all that apply: HIPAA / GLBA / FedRAMP / SOC 2 / GDPR / CCPA / Other |
| OWASP LLM Exposures | For each of LLM01–LLM10: In Scope / Out of Scope / Mitigated. Do not leave blank — "Out of Scope" requires a documented rationale. |
| Current Mitigations per Exposure | For each In Scope exposure: control name, implementation status (Planned / Implemented / Tested), and evidence location |
| Security Owner | Named individual + team. Accountable for LLM01, LLM03, LLM06, LLM07, LLM08, LLM10 |
| Privacy / Legal Owner | Named individual + team. Accountable for LLM02, LLM09, and all data subject rights obligations |
| Compliance Owner | Named individual + team. Accountable for regulatory classification, audit trail requirements, and disclosure obligations |
| Procurement / Vendor Owner | Named individual + team. Accountable for model provider compliance posture, DPA coverage, and supply chain risk (LLM03) |
| Model Provider Authorization Status | Is the model API within your FedRAMP boundary? Is the provider's DPA adequate for your sector regulations? |
| Last Review Date | Date of last full register review |
| Next Review Trigger | Material system change / Regulatory update / Security incident / Scheduled quarterly review — whichever comes first |
Not covered above, but worth knowing: The register should capture the model provider's own compliance posture separately from the deploying organization's controls. A system can have strong internal mitigations and still be non-deployable because the underlying model API sits outside the authorization boundary. This is a procurement question, not a security question, and it surfaces in federal conversations before any technical evaluation begins.
For More Information
| Recap Entry | Source Lesson | Section |
|---|---|---|
| Prompt Injection (LLM01) | Lesson 1: Prompt Injection and Jailbreaks | Threat Mechanics |
| Jailbreaks vs. Prompt Injection distinction | Lesson 1: Prompt Injection and Jailbreaks | Attack Taxonomy |
| Sensitive Information Disclosure (LLM02) | Lesson 2: Data Leakage in LLM Systems | Model-Level Exposure |
| Excessive Agency (LLM06) | Lesson 1: Prompt Injection and Jailbreaks | Agentic Risk |
| Supply Chain Vulnerabilities (LLM03) | Lesson 4: Copyright and IP Exposure | Third-Party Model Risk |
| Unbounded Consumption (LLM10) | Lesson 6: US Regulation and Sector Compliance | SOC 2 Availability Controls |
| EU AI Act Tier Classification | Lesson 5: EU AI Act | Risk Tiers and Obligations |
| NIST AI RMF vs. EU AI Act | Lesson 5: EU AI Act | Framework Comparison |
| FedRAMP Authorization Boundary for AI | Lesson 7: FedRAMP and Federal AI Deployment | Authorization Scope |
| HIPAA and AI audit obligations | Lesson 8: Sector Compliance (HIPAA/GLBA) | Audit Controls |
| GLBA and model output risk | Lesson 8: Sector Compliance (HIPAA/GLBA) | Data Handling |
| SOC 2 and AI availability controls | Lesson 6: US Regulation and Sector Compliance | Trust Services Criteria |
| Audit Trail Requirements | Lesson 9: Audit and Disclosure Obligations | Logging Requirements |
| Model cards vs. risk registers | Lesson 9: Audit and Disclosure Obligations | Governance Artifacts |
| Token / Session / Scope vocabulary collisions | Lessons 1, 5, 8 | Vocabulary Alignment |