LLM Security —
The Enterprise Practitioner's Guide

This domain is about understanding why the security problems exist at all. Every attack in the remaining eight domains traces back to one architectural fact: the Transformer model treats all input tokens identically. There is no CPU ring, no kernel mode, no trust boundary between your system prompt and the user's input. They go through the same attention mechanism.

• Alignment Tax — Safety training (RLHF, CAI) reduces capability. Every jailbreak is an attempt to access pre-aligned capability without the safety constraints imposed during alignment.
• RAG security implications — Retrieved documents are untrusted input. Indirect prompt injection embeds malicious instructions in documents the model processes as context.
• Inference parameters — Temperature=0 gives deterministic outputs (easier to probe systematically). Max tokens prevents model DoS. Know these and their security implications.
• Quantization trade-off — Quantized models (INT8/INT4) may exhibit different safety behaviours than full-precision counterparts. Not just a quality issue — a security one.
• Constitutional AI vs RLHF — CAI uses the model to self-critique against a written constitution (Anthropic's approach). RLHF uses human raters to train a reward model. Both are safety alignment mechanisms.

The exam's highest-weighted domain and the most directly applicable to enterprise AI deployments. Know all ten categories, their mitigations, and the distinctions between similar-sounding risks. The exam will test whether you can differentiate between them precisely.

• LLM01 — Prompt Injection: Direct (attacker talks to model directly) vs Indirect (malicious content embedded in data the model processes). The Confused Deputy problem — model uses its legitimate permissions for attacker's purposes. Defence requires 5 independent layers.
• LLM02 — Insecure Output Handling: LLM output is untrusted data. XSS, SQLi, command injection, path traversal all occur when model output flows unvalidated into downstream systems. Context-appropriate encoding per destination.
• LLM03 — Training Data Poisoning: Embedding backdoors at training time. Poisoned models pass standard benchmarks while hiding malicious behaviour — extremely difficult to detect.
• LLM04 — Model DoS: Long prompts, recursive structures, max-output prompts. Rate limit by token consumption, not just request count.
• LLM05 — Supply Chain Vulnerabilities: Model weights, datasets, embeddings, vector DBs, MCP servers, plugins — all are supply chain components requiring SBOM and provenance verification.
• LLM06 — Sensitive Information Disclosure: Training data extraction, system prompt leaking, RAG returning unauthorised documents. Never put secrets in system prompts.
• LLM07 — Insecure Plugin Design: Plugins with excessive permissions, accepting unsanitised LLM output. Least-privilege, input validation, full audit logging per invocation.
• LLM08 — Excessive Agency: Most relevant to AI agents and MCP. Model takes irreversible high-impact actions without human approval. HITL for irreversible operations.
• LLM09 — Overreliance: Users blindly trusting hallucinated outputs. Mandatory human review for regulated decisions.
• LLM10 — Model Theft: Weight extraction via unauthorised storage access or systematic querying. Rate limiting and query anomaly detection.

The most technically interesting domain for anyone who builds production AI. Understanding the attack taxonomy helps you design better system prompts and guardrails — not just pass an exam.

• DAN (Do Anything Now) — Roleplay as an unrestricted AI persona. Exploits instruction-following training against safety training. Detection: persona-switching requests at the input guardrail.
• Crescendo — Multi-turn escalation from benign to harmful across many messages. Each turn appears innocent. Safety filters evaluating individual turns in isolation miss this entirely.
• Skeleton Key (Microsoft) — Convinces the model that safety rules are relaxed for an "authorised" research context. The exam specifically names and tests this attack.
• Many-Shot Jailbreak — Includes many examples of unsafe behaviour in the prompt, shifting output distribution via in-context learning. Exploits the model's pattern-matching capability.
• PAIR (Prompt Automatic Iterative Refinement) — An attacker LLM automatically refines jailbreaks against a target model. No human expertise required at scale. The most dangerous because it democratises sophisticated attacks.

If you work in enterprise IT or security architecture, this domain is familiar territory in a new context. The frameworks are the same ones used for traditional IT risk — they now need to be applied to AI systems.

• NIST AI RMF — Four functions: Govern, Map, Measure, Manage. Govern establishes policies and accountability. Map identifies and contextualises risks. Measure quantifies them. Manage implements controls. The exam will test the function sequence.
• ISO/IEC 42001 — Artificial Intelligence Management System standard. Establish, implement, maintain, continually improve. Structure mirrors ISO 27001.
• EU AI Act — Four Tiers: Unacceptable (banned), High Risk (conformity assessment required — most enterprise LLM deployments in consequential decisions land here), Limited Risk (transparency obligations), Minimal Risk (no requirements).

This domain introduces AI-specific privacy challenges that do not exist in conventional software — particularly around data memorisation and the impossibility of true deletion from a trained model's parameters.

• Differential Privacy — Adds calibrated noise to limit memorisation. Epsilon (ε) controls the privacy-utility trade-off. Lower ε = stronger privacy = worse model quality.
• Federated Learning — Model trains across distributed datasets without raw data leaving its source. Only gradients are shared and aggregated. Preserves data locality.
• Homomorphic Encryption — Would allow inference on encrypted data. Currently computationally prohibitive for full LLM inference. Know what it is; know why it is not yet practical.

Most candidates struggle here because MCP is new — most study guides don't cover it. If you work with Claude Code, Cursor, or any AI-powered development environment, you're already using MCP. Understanding the security model is now a genuine competitive advantage.

• Tool Poisoning — Malicious tool descriptions manipulate LLM decision-making about when and how to invoke tools. The description is an injection vector into the model's runtime behaviour.
• Cross-server exfiltration — Attacker uses one tool to read sensitive data, another to send it externally. The LLM orchestrates the attack without knowing.
• OAuth 2.1 — Recommended auth for remote MCP servers. Token rotation, scope restrictions, secure storage. Never hardcoded API keys in tool descriptions.
• Minimal tool surface — "Get customer order by ID" is safer than "execute any SQL query." Purpose-specific narrow tools over broad general-purpose ones.
• Container isolation — Each MCP server in its own container with minimal network access. A compromised server cannot reach others or the host system.

This is where the CLLMSP separates from older AI security certifications. It covers autonomous agents, multi-agent systems, and the emerging risk of AI-generated code reaching production without meaningful security review.

• ReAct pattern — Thought → Action → Observation loop. Transparent reasoning but the chain may reveal sensitive business logic. Consider hiding chain-of-thought from end users in production.
• Multi-agent injection — One agent's output becomes another agent's input. The injection vector is inter-agent data. Inconsistent safety boundaries between models (GPT orchestrating Claude) can be exploited.
• Circuit breakers — External mechanisms that halt agent execution on anomalous behaviour: excessive tool invocations, unusual data access, privilege escalation attempts. Not self-policing.
• HITL scope — Human-in-the-loop applies to irreversible, high-impact, or externally-communicating actions. Not every tool call. The key word is irreversible.
• Agent memory poisoning — Persistent memories influence future decisions. Encrypt at rest, access-control per session, periodically review for poisoned entries.

LLM integration does not replace traditional AppSec — it adds to it. Every classic vulnerability still applies, now with an LLM in the middle of the request chain.

• SSRF — Attacker makes the LLM fetch internal network resources via URL parameters or browsing tool abuse. The LLM becomes a confused deputy for network requests.
• XSS — LLM output rendered in a browser without encoding. Use Content-Security-Policy (CSP) as the primary header defence. Never trust model output as safe HTML.
• SQL Injection — LLM-generated queries passed to a database without parameterisation. Even a well-instructed model can be manipulated via prompt injection to generate malicious SQL.
• Rate Limiting — Must account for token consumption, not just request frequency. One request consuming 1M tokens is more impactful than 1,000 small requests.
• Streaming security — Guardrails must process partial streaming output in real-time, not just completed responses. Significant implementation complexity.

The smallest domain by weight but the one that ties everything together. Identity and access control, vector database security, and incident response for AI events — cross-cutting concerns that apply across every other domain.

• RBAC — Role-based. Suitable for simple access patterns. Sufficient for small single-tenant deployments with straightforward user roles.
• ABAC — Attribute-based. Preferred for multi-tenant LLM platforms. Can simultaneously enforce policies based on user department, data classification, clearance level, device state, and time. RBAC cannot express this efficiently.
• Agent Capability Tokens — Scoped, time-limited, non-transferable between agents. "Read customer data for 15 minutes" vs permanent full database access. The correct agentic access control pattern.
• Zero Trust — Verify every request regardless of network location. No implicit trust for internal requests. Every API call, tool invocation, and data access authenticated and authorised individually.

• Model output forensics — Analyse what the model produced and reconstruct why, from inputs, context, and system prompt state at the time of the incident.
• Prompt analysis — Examine the full inputs that triggered the incident. Preserve the complete prompt context for forensic investigation.
• Guardrail effectiveness review — Which controls failed and why. Did the guardrail not fire? Was it bypassed? Was it not deployed at all?
• Behavioural baseline deviation — Sudden change in refusal rate may indicate a successful jailbreak. Spike in tool invocations may indicate agent manipulation.