Section 1 Quiz

--- shuffle_answers: true shuffle_questions: false --- ## A fintech company discovers that their AI customer service chatbot has been revealing internal pricing formulas when users craft specific requests. The formulas were written into the assistant's system prompt. Which OWASP LLM Top 10 (2026) category does this map to? > Hint: Think about where the exposed information was stored, not just what it contained. - [ ] LLM05: Data and Model Poisoning, because the model's behaviour was corrupted > Poisoning targets the training pipeline. Nothing here was trained or fine-tuned -- the formulas were placed in the context at request time and read back out. - [ ] LLM03: Excessive Agency, because the assistant exceeded its intended scope > Excessive Agency covers systems taking unauthorized *actions* through tools or permissions. This assistant disclosed information; it did not act. - [x] LLM08: Hidden Context Exposure, because the system prompt was reconstructed > Correct. Hidden Context Exposure (formerly System Prompt Leakage) covers the extraction or inference of any non-user-facing context -- system prompts, policy text, tool schemas. The deeper lesson is OWASP's design rule: assume hidden context is discoverable. Pricing formulas that are damaging when leaked should never have been in the prompt. - [ ] LLM02: Sensitive Information Disclosure, because confidential data reached a user > Tempting, and the two overlap. LLM02 covers regulated user data and training data leaking through responses. When the leaked material is the application's own hidden configuration, LLM08 is the more precise category. ## An attacker publishes a corrupted LoRA fine-tuning adapter on Hugging Face that appears to improve a model's medical knowledge. When loaded, it subtly steers recommendations toward a specific pharmaceutical brand. Which stage of the AI lifecycle is being attacked? > Hint: Consider when in the AI lifecycle LoRA adapters are applied. - [ ] Inference phase, because the harm appears when users ask questions > The effect manifests at inference, but the compromise happened earlier. Ask where the attacker's artifact entered the system, not where the damage shows. - [x] Customization phase, because the adapter alters behaviour during fine-tuning > Correct. LoRA adapters are applied during the Customization phase. This is simultaneously LLM04: Supply Chain (a distributed artifact is not what it claims) and LLM05: Data and Model Poisoning (the artifact steers behaviour). The 2026 edition added artifact-trust failure to LLM04 for exactly this pattern. - [ ] Monitoring phase, because the attack exploits the retraining feedback loop > The Monitoring phase covers logging and feedback. That loop is a real attack surface, but this compromise arrived as a downloaded adapter, not through feedback. - [ ] Deployment phase, because the adapter travels through model distribution > Deployment covers packaging and distribution infrastructure. Adapters are distributed, but they take effect when applied during Customization. ## Your organisation's incident log shows zero prompt injection incidents over the past year, and eleven cases of a downstream system acting on a fabricated model output. A colleague proposes cutting the injection filtering budget. What is the strongest response? > Hint: The 2026 OWASP edition found exactly this pattern in the global incident record. - [x] Low injection counts may reflect the filtering working, so measure before cutting > Correct. This is the defense effect the 2026 edition surfaced: prompt injection ranks #1 on the practitioner vote but drops out of the top 10 by raw incident count, because teams defend it heavily. A low count for a well-defended risk is evidence the control is earning its money. The eleven fabrication cases are the real signal -- misinformation is the category the field under-rates relative to the record. - [ ] Agree, since the incident record is objective evidence and beliefs are not > Incident records are evidence of what was *detected and reported*, not of what was attempted. OWASP deliberately weighted the community vote at 75% against 25% for incident data for this reason. - [ ] Disagree, because prompt injection ranks #1 and rankings should set budgets > Rankings are a starting point, not a budget allocation. Deferring to the rank without asking why your own numbers differ is the same mistake as deferring to the raw count. - [ ] Agree, but only after reclassifying the eleven cases as injection incidents > The eleven cases describe fabricated output driving a downstream action -- LLM07: Misinformation compounded by LLM03. Relabelling them to justify a decision hides the category that is actually hurting you. ## In the Microsoft v. Storm-2139 case, attackers harvested exposed Azure OpenAI API keys and resold access through reverse-proxy software. Which OWASP category does this map to, and why? > Hint: Think about what the victims lost, and which 2026 category was reframed around exactly that. - [ ] LLM02: Sensitive Information Disclosure, because credentials are sensitive data > The credentials were harvested from sources already exposed outside the AI system -- code repositories and leak dumps. The AI-specific risk is what the stolen keys then enabled. - [x] LLM06: Unbounded Consumption, because stolen keys enabled consumption at the victim's cost > Correct. The 2026 edition reframed LLM06 around cost asymmetry -- an attacker triggering expensive computation at negligible cost to themselves. Stolen credentials are the purest form of that. The controls that stop it are credential hygiene, spend caps, and consumption anomaly detection, all in Layers 5 and 6. - [ ] LLM04: Supply Chain, because the reverse-proxy software was a malicious component > The proxy was the attackers' own tooling, not a compromised component inside the victim's pipeline. Supply Chain covers artifacts *you* pull in and trust. - [ ] LLM10: Improper Output Handling, because policy-violating content was generated > The generated content violated the provider's usage policy, but Improper Output Handling covers output passed unvalidated into downstream systems, not the content itself being objectionable. ## A widely quoted figure puts LLMjacking losses at "over $100,000 per day." How should you present that number in a risk briefing? > Hint: Ask where the number came from and what kind of number it is. - [ ] As confirmed damages awarded in the Microsoft v. Storm-2139 proceedings > Microsoft has not published a damages figure for that case. Attaching the number to a specific lawsuit gives it a precision it does not have. - [x] As a modelled worst case from research -- a ceiling, not an observed loss > Correct. The figure originates in security research on the technique, not in any specific victim's bill -- Sysdig's 2024 analysis calculated roughly $46,000 per day at maximum quota, and later estimates scaled it past $100,000 for frontier models. Presented as a ceiling it is genuinely useful; presented as an observed loss it is unsupportable. - [ ] As the industry average cost of a credential-based AI incident last year > No such average is being reported here. The figure is a single modelled scenario at maximum quota, which is close to the opposite of an average. - [ ] As an obsolete estimate, since per-token inference pricing has fallen sharply > Falling per-token prices are offset by reasoning models with far larger output budgets and by agentic fan-out, both of which the 2026 LLM06 entry calls out as cost multipliers. ## A team is reviewing a document-summarisation assistant that reads a shared mailbox, has no tools, and stores nothing between sessions. They want to add a calendar-booking tool with write access. What changes about which framework governs the review? > Hint: The two OWASP lists divide on a single question about what the model is. - [ ] Nothing changes, because the LLM Top 10 already covers tool risk under LLM03 > LLM03: Excessive Agency is the entry question, not the whole assessment. Once agency exists, the ASI categories enumerate the specific failures LLM03 only warns against creating. - [x] It crosses from model-as-component to model-as-actor, so the Agentic list applies > Correct. That is precisely the boundary OWASP draws: the LLM list owns risk while the model is a component inside your application; once it becomes an actor -- calling tools, carrying memory, setting consequences in motion -- the risk moves to the Agentic list. Write access to a calendar crosses it. Both lists apply from that point; neither covers the ground alone. - [ ] MITRE ATLAS becomes the governing framework once a system can take actions > ATLAS is a threat-modelling and red-team reference across the full adversarial lifecycle. It is not scoped by whether a system has agency, and it is too granular for everyday review vocabulary. - [ ] Nothing changes yet, because the Agentic list covers only multi-agent systems > The Agentic Top 10 covers single-agent risks throughout -- goal hijacking, tool misuse, code execution. Only ASI07 and ASI08 are specifically about multi-agent architectures. ## A security team must map an attacker's complete journey, from initial reconnaissance through to final impact, for a formal threat model. Which framework fits, and why? > Hint: One framework categorises what can go wrong; another maps how an attacker moves. - [x] MITRE ATLAS, because it maps tactics and techniques across the attack lifecycle > Correct. ATLAS organises 16 tactics and 178 techniques into an ATT&CK-style matrix that traces the attacker's path from reconnaissance to impact -- exactly the structure formal threat modelling needs. The OWASP lists answer "what can go wrong," which is a different question. - [ ] OWASP LLM Top 10, because its categories are the most comprehensive available > The LLM Top 10 categorises vulnerabilities. It deliberately does not model attacker movement, which is why the two frameworks are described as complementary rather than competing. - [ ] OWASP Agentic Top 10, because it covers the most severe modern attack classes > The Agentic list is scoped by system type, not by attack sequence. Severity is not the selection criterion; the shape of the question is. - [ ] Any of the three, since all map adversarial behaviour at similar granularity > They differ sharply in unit and granularity -- vulnerability category, agentic risk category, and individual technique. That is why the choice matters. ## An organisation starts its agentic AI assessment from LLM03: Excessive Agency. What is the relationship between LLM03 and the ASI categories? > Hint: One is preventive and singular; the other is diagnostic and enumerative. - [ ] LLM03 supersedes the ASI categories, which restate the same risk in detail > They are not redundant. LLM03 is one preventive principle; the ASI list enumerates ten distinct failures, most with no LLM03 equivalent. - [x] LLM03 says "don't grant excess agency"; ASI maps failures once agency exists > Correct. LLM03 is preventive: minimise functionality, permissions and autonomy. ASI01-ASI10 are diagnostic: what actually goes wrong in a system that legitimately has agency. OWASP makes the link explicit in the LLM03 entry, noting it manifests as ASI02, ASI03 and ASI08 in agentic systems. - [ ] LLM03 and the ASI categories are unrelated frameworks with no defined link > The link is stated in the 2026 LLM03 entry itself, which names the ASI categories that excessive agency manifests as. - [ ] LLM03 applies only to non-agentic systems and is skipped for agent reviews > The opposite: it is the entry question for an agent review. Ask whether the system has more capability than its job needs, then use the ASI list to enumerate what follows. ## An attacker with no coding ability uses a jailbreak template copied from social media against a customer-service agent that holds write access to a refunds API. How should the low capability of the attacker affect your risk assessment? > Hint: Distinguish how an attacker finds a weakness from how much the weakness costs you. - [ ] It lowers the risk, since low-capability attackers cannot chain exploits well > No chaining is needed. The template supplies the exploit and the agent's own permissions supply the impact. - [x] It does not lower the impact, because the agent's permissions set the damage > Correct. Capability limits how an attacker *finds* a weakness, not what the weakness costs. Published templates spread within hours, so assume they will be tried on day one. The agent's write access to refunds is the variable that matters -- which makes this an LLM03 problem, and scoping the credential is the fix. - [ ] It raises the risk, because unskilled attackers act unpredictably and at volume > Volume is a real concern, but the reasoning is wrong. Risk here is driven by the permissions the agent holds, not by the attacker's behavioural profile. - [ ] It is not assessable, since actor category cannot be inferred from technique > You can profile the actor reasonably well here. The point is that the profile should not reassure you when the target is over-permissioned.