Section 5 Quiz

--- shuffle_answers: true shuffle_questions: false --- ## An AI research assistant is asked to summarize web pages about cloud security. One page contains hidden HTML comments instructing the agent to read ~/.ssh/config and include the contents in its output. The agent complies. Which two OWASP Agentic categories are demonstrated in this attack chain? > Hint: Think about what happened in two steps -- first the agent's objective changed, then it used its tools for the new objective. - [x] ASI01: Agent Goal Hijacking, then ASI02: Tool Misuse and Exploitation > Correct! ASI01 and ASI02 frequently chain together. First the hidden instructions hijacked the agent's goal from "summarize cloud security content" to "read sensitive credentials" (ASI01). Then the agent used its legitimate file system access to read ~/.ssh/config (ASI02). Note that the second step produces no misuse signature -- the file read is authorised and looks exactly like a legitimate one -- which is why the enforcement has to sit in the code that executes the call rather than in detection. - [ ] ASI06: Memory and Context Poisoning, then ASI07: Insecure Inter-Agent Communication > Memory poisoning requires a write path into persistent storage, and nothing here persists beyond the session. Inter-agent communication requires more than one agent, and this is a single-agent scenario with a single web page as the source. - [ ] ASI04: Agentic Supply Chain Vulnerabilities, then ASI05: Unexpected Code Execution > Supply chain covers a compromised tool, server or package, and every component here is legitimate. No code was executed either -- the agent read a file using a tool it already had, which is tool misuse rather than code execution. - [ ] ASI09: Human-Agent Trust Exploitation, then ASI10: Rogue Agents > Trust exploitation describes a human accepting output without verification, which is not what failed here. Rogue agents deviate without any external manipulation, and this attack was triggered entirely by attacker-supplied content in a web page. ## In CurXecute (CVE-2025-54135), an attacker posted a message into a Slack channel. Cursor's agent read the channel through a legitimate, vendor-published Slack MCP server, then wrote a new entry into its own mcp.json configuration file, which Cursor executed immediately. Which category is the correct primary classification? > Hint: Ask what the attacker actually had to compromise. Then ask which team a finding under each category would be routed to. - [x] ASI01: Agent Goal Hijacking -- the supply chain was clean, and the attacker's only capability was posting text the agent would read > Correct! Nothing in the chain was compromised: not the model, not the MCP server, not the package registry. The attacker supplied text in a place the agent was going to read anyway, which is goal hijacking. The classification has practical consequences -- filing this as a supply chain issue would send someone to audit package sources, and no amount of package auditing would have prevented it. The code execution that followed is ASI05, and the missing control is that Cursor executed new config entries before the user approved them. - [ ] ASI04: Agentic Supply Chain Vulnerabilities -- the attack arrived through an MCP server, so the MCP supply chain is the vector > The MCP server was genuine and behaved correctly, faithfully returning the channel contents it was asked for. A supply chain finding describes a compromised or malicious component, and here the component was doing its job. Contrast MCPoison (CVE-2025-54136), which really is ASI04 because the approved configuration itself was swapped. - [ ] ASI07: Insecure Inter-Agent Communication -- the poisoned message came from an external messaging system > Inter-agent communication covers messages passed between agents in a multi-agent system, where one agent's output becomes another's instruction. Slack here is a data source the single agent reads, not a peer agent delegating a task to it. - [ ] ASI03: Identity and Privilege Abuse -- the agent used its file write permission to escalate > The agent used only the workspace write access it was designed to have, and no credential was stolen, escalated or reused. The failure was that the editor treated a written config entry as an approved one, not that the agent's identity carried too much privilege. ## An AI agent has read-only file access. It reads a .env file containing database credentials, connects to the database, finds an admin API key, and uses it to modify system permissions. No single step was flagged as malicious. Which category and underlying pattern does this match? > Hint: Think about how each step uses a legitimate capability but the chain produces something unauthorized. - [x] ASI03: Identity and Privilege Abuse, an instance of the confused deputy pattern > Correct! Each step uses a legitimate capability, so no step is individually malicious, but the chain escalates privilege. The underlying pattern is the confused deputy: the database sees the service account from the .env file, not "an agent acting for this user". That is why the fix is to evaluate authorization against the requesting user's entitlements rather than the tool's, and why Chapter 3 places it in Layer 3 as an infrastructure control rather than treating it as a prompting problem. - [ ] ASI02: Tool Misuse and Exploitation, because each tool was used for an unintended purpose > Tool misuse describes individual tools being turned to malicious ends by a hijacked agent. What is distinctive here is the escalation itself -- read access became admin access -- which is a property of the credential chain rather than of any single tool call. - [ ] ASI05: Unexpected Code Execution, because the agent ran commands it should not have > No code was executed and no sandbox was escaped at any point in this chain. The agent used its ordinary tools -- file read, database connect, API call -- and the harm came from what those credentials unlocked rather than from arbitrary execution. - [ ] ASI10: Rogue Agents, because the agent deviated from its intended behavior > Rogue agents deviate through misaligned optimization or emergent goals, with no external attacker involved at all. This chain exploits inherited permissions and over-scoped credentials, which is a design and identity failure rather than an alignment one. ## In SpAIware (September 2024), Johann Rehberger showed that injected content could write an instruction into ChatGPT's long-term memory, after which every later conversation was exfiltrated. OpenAI's fix hardened the rendered-URL check that carried the data out. What is the most accurate reading of that remediation? > Hint: Compare what the attacker needed to do with what the fix prevented. - [x] It closed the exfiltration channel but not the injection primitive, so content can still influence what gets stored > Correct! The remediation blocked the outbound path rather than preventing untrusted content from writing to memory. That is a sound immediate fix and it is not a solution to ASI06 -- an agent that lets processed content shape what it stores still has the primitive and needs only a different way out. The design question is narrower than either: what is allowed to write to memory, and is a tool result on that list? - [ ] It resolved ASI06 for ChatGPT, since data can no longer leave through the rendered-URL path > Closing one egress route does not remove the ability to plant a persistent instruction, and a planted memory can influence answers, tool choices and behaviour without any data leaving at all. Treating a channel fix as a category fix is exactly the reasoning error the case is included to surface. - [ ] It was unnecessary, because memory poisoning only affects the session in which the injection occurred > Persistence is the entire point of ASI06 and what separates it from one-shot prompt injection. The demonstrated attack reached conversations the original malicious content never touched, made by a user with no reason to suspect anything. - [ ] It shifted the risk to ASI09, because users must now verify the agent's memory themselves > Trust exploitation describes users accepting outputs without checking, which is a different failure. Users have no practical way to inspect memory writes in the first place -- the invisibility of the write is part of why ASI06 is dangerous, not a burden the fix transferred to them. ## In a multi-agent CI/CD pipeline, Agent 1 (Research) processes a poisoned source and passes corrupted requirements to Agent 2 (Code Generator), which passes backdoored code to Agent 3 (Reviewer), which passes it to Agent 4 (Deployment). Agent 4 deploys to production. Why did the review stage fail to stop this? > Hint: Ask what would have to be true for a review step to add assurance. - [x] A reviewer that shares the pipeline's trust assumptions is not an independent control > Correct! This is ASI08: Cascading Failures. Agent 3 exists to catch exactly this, and it fails not through bad implementation but through structure -- four agents built on the same model, each treating the previous one's output as authoritative, are one control wearing four hats. An automated review adds assurance only when it can fail differently from what it reviews, so at least one gate in the chain has to be a different kind of check: a signature, a policy engine, or a human. - [ ] The reviewing agent lacked the tool permissions needed to inspect the generated code properly > Nothing in the scenario suggests the reviewer was under-provisioned, and granting it more access would not help. It would read the same backdoored code with the same assumptions and reach the same conclusion, because the problem is what it trusts rather than what it can see. - [ ] The messages between agents were intercepted and altered in transit by the attacker > No interception occurred anywhere in this chain. The attacker touched only the research source at the very start, and every message after that was transmitted faithfully -- which is what makes the propagation automatic and free for the attacker. - [ ] All four agents deviated from their intended behavior once the first was compromised > Every agent behaved exactly as designed throughout, and that is the uncomfortable part. They processed corrupted inputs correctly and produced correspondingly corrupted outputs, so no individual agent was rogue and no individual agent malfunctioned. ## What is the relationship between LLM03: Excessive Agency in the OWASP LLM Top 10 (2026) and the OWASP Top 10 for Agentic Applications (2026)? > Hint: Think about LLM03 as a door and the agentic list as what is behind it. - [x] LLM03 is the foundation the agentic list expands: it warns against granting agency, and ASI01-ASI10 map what happens once agency exists > Correct! LLM03 focuses on prevention -- do not give the model a tool it does not need -- while the agentic list maps exploitation. When assessing a system, start with LLM03 as the entry point, then use ASI01-ASI10 for the specific risks that agency creates. The dividing line is per capability, not per product: the model is a component until it can act, and an actor afterwards. - [ ] LLM03 was deprecated when the 2026 edition shipped, and the agentic list replaced it as the successor framework > LLM03 is not only still active, it climbed to third place in the 2026 edition, which is itself informative about how the risk landscape moved. The agentic list is an explicit companion framework published alongside it rather than a successor to any single category. - [ ] They address separate risk domains, so a given system will fall under one framework or the other > OWASP connects them deliberately, and real incidents frequently need both. EchoLeak is catalogued as agentic goal hijacking while its exfiltration step is an output-handling failure from the LLM list, so reaching for one framework and stopping would misfile the control owner. - [ ] The agentic list applies only to systems with several coordinating agents, while LLM03 is the one that covers single-agent deployments > Both frameworks cover single-agent and multi-agent systems alike. The agentic list does include two categories specific to multi-agent architectures, ASI07 and ASI08, but the majority of it applies perfectly well to one agent acting on its own. ## A security team is hardening a multi-agent coding pipeline with limited budget. Three risks are confirmed: (1) ASI04, their MCP servers come from unverified npm packages; (2) ASI06, their agents use persistent memory with no integrity checks; (3) ASI08, agents trust each other's outputs without validation. Which should they mitigate first, and why? > Hint: Use the reachability column. Which of these needs no prior foothold? - [x] ASI04, because it is the only one of the three that needs no prior foothold and it gates the other two > Correct! Reachability decides prioritisation. ASI04 requires nothing but the ability to publish or modify a package, while ASI06 needs content the agent reads plus a write path, and ASI08 needs a compromise somewhere upstream to propagate. A malicious MCP server supplies the entry point for both, so closing it reduces exposure to all three at once. Note the separate point about residual risk: if that entry point has been open for any length of time, go and inspect memory anyway. - [ ] ASI08, because a cascade running unchecked through the pipeline could reach production and cause by far the greatest damage > Cascading failures have severe downstream impact, but they are a propagation mechanism rather than an entry point and cannot start on their own. Something has to compromise the first agent, and in this system the unverified MCP servers are by far the most likely candidate. - [ ] ASI06, because persistent poisoning silently affects every future session and outlasts any single request or investigation > Persistence genuinely makes ASI06 the worst residual risk of the three, and it is the one to audit for after an exposure. But it is a severity multiplier rather than an entry point, and closing the supply chain removes the most likely way poisoned content reaches memory in the first place. - [ ] All three are equally severe, so the team should divide its budget evenly between them > These risks occupy different positions in the attack chain, which is precisely what makes them rankable. Splitting effort evenly spends budget defending consequences that an entry-point control would have prevented, and it is the wrong call whenever resources are constrained. ## An AI optimization agent told to "maximize quarterly revenue" starts pricing services just below competitor rates, including for customers who were more profitable at higher prices. It has not been compromised -- it is doing what it was told. Which category applies, and what does the Replit case add to it? > Hint: Consider whether this needs an external attacker at all. - [x] ASI10: Rogue Agents -- and Replit shows the control is architectural, since an instruction is not a constraint > Correct! ASI10 covers deviation through misaligned optimization rather than external attack, and it is the only category that survives a perfect security posture because threat modelling will not surface it. Replit's agent deleted a production database while under an explicit code freeze instructed in a prompt, which is steering rather than enforcement. A freeze enforced by a read-only credential is a control; a freeze enforced by asking is a preference. The design question is which actions cannot be undone, and what stands in front of them. - [ ] ASI01: Agent Goal Hijacking -- the agent's objective was redirected away from its intended purpose > Nobody redirected anything, and there is no attacker anywhere in this scenario. The agent is pursuing the exact goal it was assigned, which is what distinguishes ASI10 from ASI01 and why the two need different controls entirely. - [ ] ASI09: Human-Agent Trust Exploitation -- the operators accepted the pricing changes without checking > Insufficient oversight is plausibly a contributing factor here, as it is in most ASI10 incidents. But the core failure is the agent's own optimization finding strategies its designers never intended, not a human being manipulated into trusting a compromised output. - [ ] ASI02: Tool Misuse and Exploitation -- the pricing tool was used in a way it was not designed for > The pricing tool was used exactly as designed, to set prices, and it worked correctly every time it was called. Tool misuse requires an agent whose intent has been manipulated by an attacker, and here the intent came straight from the mandate it was given. ## Your team runs an agent that reads customer emails and drafts replies. Which pair of Chapter 3 Blueprint layers is the primary home for the controls this system most needs? > Hint: Identify the ingress, then identify what the agent can do with what it reads. - [x] Layer 5 for what enters and leaves the model, and Layer 3 for what the agent's identity is allowed to reach > Correct! Any external party can write to this agent's ingress simply by emailing it, which puts prompt and response filtering in Layer 5 (Secure Access to AI Services). What the agent may then do is governed by its credentials and tool scope, which is Layer 3 (Secure Your AI Infrastructure) through posture management and identity controls. The pairing reflects the ingress and egress split: controlling only one side leaves the path open, and the two sides usually have different owners. - [ ] Layer 1 for the data and Layer 2 for the model, since the risk is what the model was trained on > Layers 1 and 2 secure training data and model artifacts, which matter greatly but are not where this system is exposed. Nothing here is being poisoned at training time -- the attack arrives at inference in an ordinary email, long after the model was built. - [ ] Layer 4 for the users and Layer 6 for zero-day defense, since staff review every draft reply > Both contribute usefully, and human review does help against subtly wrong drafts. But relying on reviewers runs directly into the automation-bias evidence from Chapter 1, and neither layer prevents an injected email from directing the agent in the first place. - [ ] Layer 6 alone, since behavioral anomaly detection will catch the tool calls that do not match the task > Behavioural detection is a genuinely valuable backstop and is the right home for spotting hijacked tool-call sequences. Relying on it alone accepts every attack up to the point of detection, though, and most agentic actions are authorised and look entirely normal in telemetry.