Ten pieces. Four risk domains. One scaffold that holds them together.
The register below is the working artifact this chapter was building toward. Walk the columns. Then use the template at the end.
Register Columns
AI System Name — The specific AI component being assessed: a model, an agent, a RAG pipeline, a fine-tuned classifier. Not the platform — the discrete system that touches data, makes decisions, or acts on behalf of a user or process. When it comes up: A CISO asks what AI is running in the environment. "We use Azure OpenAI" is not a system name. "A RAG-based document retrieval agent with access to the HR knowledge base" is. Don't confuse with: The vendor or platform. One vendor can host multiple AI systems with different risk profiles. List systems, not contracts.
EU AI Act Risk Tier — The classification that determines compliance burden: Unacceptable, High, Limited, or Minimal. In public sector accounts, any AI system touching benefits eligibility, law enforcement, critical infrastructure, or essential public services defaults to High unless the agency has documented otherwise. When it comes up: Legal or procurement asks whether the agency needs a conformity assessment before deployment. The tier determines the answer. Don't confuse with: The vendor's risk classification of their own product. Vendors classify their models; agencies classify their deployments. The same model can be Minimal risk in one context and High risk in another depending on what it's deciding.
Applicable Sector Regime — The regulatory frameworks that apply to the data the AI system processes: HIPAA for protected health information, GLBA for financial data, FedRAMP for federal cloud deployments, SOC 2 for general enterprise controls. Regimes stack — a federal health agency deploying an AI system that processes data from EU persons can trigger HIPAA, FedRAMP, and EU AI Act obligations simultaneously. When it comes up: Legal asks whether the AI system needs a data processing agreement. The answer depends on which regimes apply and whether the vendor holds the right certifications for each. Don't confuse with: A compliance checklist. Sector regimes define the floor, not the ceiling. An agency can be HIPAA-compliant and still have an AI deployment that violates its own ATO conditions.
OWASP LLM Top 10 Exposures with Current Mitigations — The attack surface categories that apply to the specific deployment shape. Not all ten apply to every system — a batch classification model has a different exposure profile than a user-facing conversational agent with tool access.
| OWASP LLM ID | Exposure | Applies To | Baseline Mitigation |
|---|---|---|---|
| LLM01 | Prompt Injection | Any user-facing agent | Input validation, instruction hierarchy enforcement |
| LLM02 | Insecure Output Handling | Systems passing LLM output to downstream processes | Output schema validation, sandboxed execution |
| LLM03 | Training Data Poisoning | Fine-tuned or RAG-augmented models | Data provenance controls, retrieval source allowlisting |
| LLM04 | Model Denial of Service | Public-facing or high-volume deployments | Rate limiting, query complexity caps |
| LLM05 | Supply Chain Vulnerabilities | Any system using third-party models or plugins | Vendor attestation, model provenance tracking |
| LLM06 | Sensitive Information Disclosure | RAG systems, systems with persistent memory | Output filtering, retrieval scope controls |
| LLM07 | Insecure Plugin Design | Agents with tool access | Least-privilege tool scoping, tool call logging |
| LLM08 | Excessive Agency | Autonomous agents with write access | Human-in-the-loop gates, action scope limits |
| LLM09 | Overreliance | Decision-support systems | Confidence thresholds, mandatory human review for adverse decisions |
| LLM10 | Model Theft | Proprietary fine-tuned models | API rate limiting, output watermarking |
When it comes up: A security architect asks what the threat model is for the proposed deployment. This table is the starting point for that conversation. Don't confuse with: A vulnerability scan. OWASP LLM exposures are architectural risks, not software bugs. They don't close with a patch cycle.
If you remember nothing else: Prompt injection is the SQL injection of AI — not exotic, not theoretical, and not the vendor's problem to solve for you.
Accountable Owner per Risk Category — The internal role responsible for each risk domain. Security owns LLM01, LLM04, LLM07, LLM08. Legal owns LLM09 and EU AI Act tier classification. Privacy owns LLM06 and sector regime compliance. Procurement owns vendor attestation (LLM05) and FedRAMP ATO status. When it comes up: An incident occurs and nobody knows who owns the AI system's risk posture. This column exists to prevent that conversation. Don't confuse with: The system owner. The system owner manages the deployment. The accountable owner per risk category is responsible for the control, and that responsibility survives personnel changes.
Vocabulary Collision Reference
Three collision zones where AI terminology and IDAM terminology share a word and diverge on meaning. Customer conversations go sideways in the gap.
Table 1: Identity and Authorization Terms
| AI Term | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Agent | Autonomous system that perceives context and takes actions toward a goal | Software agent (directory sync connector, provisioning agent) | AI agents require dynamic, runtime scope negotiation; IDAM agents have fixed, provisioned permissions that don't change between calls |
| Session | Conversation context window — the model's working memory for a single interaction | Authenticated user session with defined lifetime and idle timeout | AI sessions carry no authentication state and don't expire on inactivity by default; IDAM sessions are security boundaries with mandatory timeout policies |
| Scope | The domain or task boundary informally assigned to a model | OAuth permission boundary — formally declared and enforced at the authorization server | AI scope is model-defined and unenforced; IDAM scope is protocol-enforced and auditable |
Table 2: Data and Trust Terms
| AI Term | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Token | Subword unit of text — the atomic unit of LLM input and output | Bearer credential (OAuth access token, JWT) carrying authorization claims | LLM tokens have no security properties; IDAM tokens are trust artifacts. Same word, orthogonal concepts — conflating them in a customer conversation signals a fluency gap |
| Context | The full input to a model: instructions, history, retrieved documents, user input | Security context — the structured set of claims about an authenticated principal | AI context is unstructured and model-interpreted; IDAM context is schema-defined and enforced by policy |
| Memory | Persistent storage of prior conversation state across sessions | Credential store or session cache | AI memory has no access control model by default; IDAM credential stores have defined read/write permissions and audit trails |
Table 3: Risk and Compliance Terms
| AI Term | What It Means in AI | IDAM Equivalent | Key Divergence |
|---|---|---|---|
| Guardrails | Model-level behavioral constraints — instructions or fine-tuning that limit outputs | Policy enforcement point (PEP) — a component that deterministically enforces authorization decisions | Guardrails are probabilistic and bypassable; PEPs are deterministic and protocol-enforced. A guardrail is not a control in the compliance sense |
| Alignment | The degree to which a model's behavior matches intended values | Policy compliance — adherence to defined authorization rules | Alignment is measured by output sampling, not audit log; compliance is binary and auditable. "The model is aligned" is not a compliance statement |
Risk Category → Control Discipline Mapping
| Risk Category | Primary Control Discipline | Secondary Control Discipline |
|---|---|---|
| Prompt Injection (LLM01) | Input validation and sanitization | Instruction hierarchy enforcement |
| Sensitive Information Disclosure (LLM06) | Data classification and retrieval scoping | Output filtering |
| Excessive Agency (LLM08) | Least-privilege authorization | Human-in-the-loop workflow gates |
| Supply Chain (LLM05) | Vendor risk management | Model provenance and attestation |
| Training Data Poisoning (LLM03) | Data governance | Retrieval source allowlisting |
| EU AI Act High-Risk Obligations | Conformity assessment | Technical documentation and logging |
| HIPAA/GLBA Sector Compliance | Data processing agreements | Breach notification procedures |
Risk Category → Architectural Layer Mapping
| Risk Category | Architectural Layer | Where the Control Lives |
|---|---|---|
| Prompt Injection (LLM01) | Application layer | API gateway, input validation service |
| Insecure Output Handling (LLM02) | Integration layer | Output schema validator, downstream API contract |
| Excessive Agency (LLM08) | Authorization layer | Tool call policy, action scope enforcement |
| Sensitive Information Disclosure (LLM06) | Data layer | Retrieval index access controls, output filter |
| Model Denial of Service (LLM04) | Infrastructure layer | Rate limiter, query complexity cap |
| Supply Chain Vulnerabilities (LLM05) | Procurement/vendor layer | Vendor attestation, ATO documentation |
One-Page Register Template
Apply this to any AI deployment you encounter in an account. Complete every column. Any cell you cannot complete is a finding.
| AI System | EU AI Act Tier | Sector Regime(s) | OWASP LLM Exposures | Current Mitigations | Accountable Owner |
|---|---|---|---|---|---|
| Name the specific system, not the platform | Unacceptable / High / Limited / Minimal | HIPAA / GLBA / FedRAMP / SOC 2 / Other | List applicable LLM IDs | List controls currently in place | Security / Legal / Privacy / Procurement |
Worked Example:
| AI System | EU AI Act Tier | Sector Regime(s) | OWASP LLM Exposures | Current Mitigations | Accountable Owner |
|---|---|---|---|---|---|
| Benefits eligibility screening chatbot (HHS agency) | High — essential public services | HIPAA, FedRAMP Moderate | LLM01, LLM06, LLM08 | Input validation layer; PHI output filtering; human-in-the-loop required for adverse eligibility decisions; FedRAMP-authorized hosting confirmed | Security (LLM01, LLM08); Privacy/Legal (LLM06, HIPAA); Procurement (FedRAMP ATO) |
If you remember nothing else: The cells you can't fill are the findings.
For More Information, See…
| Topic | Source Article | Section |
|---|---|---|
| EU AI Act risk tiers and classification logic | Ch. 5, Lesson 1: The EU AI Act for Public Sector Sellers | Risk Tier Classification |
| OWASP LLM Top 10 — full attack descriptions | Ch. 5, Lesson 3: OWASP LLM Top 10 in Deployment Context | Exposure Catalog |
| Prompt injection mechanics and mitigations | Ch. 5, Lesson 4: Prompt Injection as Architectural Risk | Attack Surface and Controls |
| HIPAA obligations for AI deployments | Ch. 5, Lesson 6: Sector Regimes and AI | HIPAA and PHI in LLM Context |
| FedRAMP and AI system ATO requirements | Ch. 5, Lesson 7: FedRAMP in the Age of AI | ATO Scope and AI Components |
| Excessive agency and authorization architecture | Ch. 5, Lesson 8: When Agents Act | Scope, Authorization, and Human Gates |
| Accountability and ownership frameworks | Ch. 5, Lesson 9: Who Owns the Risk | Ownership by Risk Category |
| Architectural layers and control placement | Ch. 4 (Enterprise Deployment), Lesson 5: Layered Architecture | Layer-by-Layer Control Reference |