Section 8 Quiz

--- shuffle_answers: true shuffle_questions: false --- ## Layer 6 combines signature rules, virtual patch rules and behavioural rules. A technique exists and is being used against you, but nobody has published it yet. Which of the three covers that interval, and what does it produce? > Hint: Two of the three rule types need somebody to have described the attack first. - [ ] Signature rules, which match the payload and drop the traffic > Signatures require the attack to have been documented and a pattern derived from it. Before publication there is nothing to write a signature against. - [x] Behavioural rules, and they raise an alert rather than blocking > Correct! Behavioural rules do not describe the attack -- they describe your system's normal, and report deviation from it. That is why they are the only cover in the pre-disclosure segment. It is also why their output is an alert to a human rather than a dropped packet, which is the honest limit of the layer's zero-day half. - [ ] Virtual patch rules, which block exploitation before the vendor ships a fix > Virtual patching needs a disclosed vulnerability: a CVE, advisory, or published proof of concept. It is strong immediately *after* disclosure and has nothing to act on before it. - [ ] All three together, since the engine correlates their outputs > The engine does combine all three, but two of them are inert here. Correlating rule types does not create coverage that none of them individually has. ## Your team is evaluating a product marketed as "zero-day protection for AI infrastructure." Its core capability is deploying blocking rules within hours of a CVE being published. What should you conclude about the coverage you are buying? > Hint: Compare what the product does against the two halves of the layer. - [ ] It covers the whole layer, since novel vulnerabilities are disclosed as CVEs > A CVE is a disclosure, so by definition it exists after the technique is known. Techniques with no CVE -- a new jailbreak, a new injection phrasing, a new output sink -- never enter this product's coverage. - [x] It is strong on disclosed-but-unpatched flaws and blind before disclosure > Correct! This is virtual patching, which is genuinely valuable and is really zero-*patch* defense: it covers the interval between disclosure and your upgrade. The pre-disclosure segment needs behavioural baselining, which describes your own system rather than the attack -- and that is the half no product arrives with configured, because only you know what your deployment's normal looks like. - [ ] It is redundant with the vendor patch, so the value is marginal > The value is not marginal. Applying a vendor patch requires a change window, dependency revalidation, and taking an inference endpoint offline -- and the virtual patch covers exactly that interval, then stays afterwards as defense in depth. - [ ] It duplicates Layer 5's filtering, so it belongs in the gateway budget > Layer 5 inspects prompts and responses in the request path. Virtual patching blocks exploitation of a vulnerability in the software around the model. Different targets, different failure modes. ## A vendor's virtual patch guidance says the rule covers "the window before the vendor ships an official fix." For CVE-2025-68613, n8n published patched releases at the same time as the advisory. Does the virtual patch still have a job, and if so which window is it covering? > Hint: Consider what has to happen between a fixed release existing and your instance running it. - [x] Yes -- it covers your upgrade window, which is the gap that actually persists > Correct! The gap that hurts is downstream of the vendor. A serving-engine or orchestrator bump can move a CUDA requirement, a driver, a base image, and require model output revalidation; inference endpoints are always on, so the change lands in a window. Both Chapter 2 Section 4 and Layer 3 hand this section the same phrasing -- getting a patch deployed *before you can upgrade*. - [ ] No -- with a fixed release available the correct action is to upgrade > Upgrading is the correct action and it is not instantaneous. Treating "a patch exists" as equivalent to "we are patched" is the assumption that leaves the exposure open for weeks. - [ ] No -- a virtual patch is only valid while no official fix exists at all > Nothing about the rule's validity depends on the vendor's release state. The section also recommends keeping virtual patches active *after* the official patch, against an incomplete fix or a rollback. - [ ] Yes -- but only for instances that cannot reach the vendor's release feed > Reachability of the release feed is not the constraint. The constraint is the operational cost of applying the upgrade to a running production endpoint. ## An agent that normally makes three tool calls per task is hijacked by an injected instruction. The hijack adds two calls: it reads a shared document, then writes one configuration file. Your behavioural detection alerts at fifteen tool calls. What happens, and what would have caught it? > Hint: The realistic hijack does not look like a burst. - [ ] The volume rule fires late, so lowering the threshold to six calls fixes it > Lowering the threshold trades one blind spot for a false-positive rate that makes the alert unusable, and a hijack needing one extra call still passes. The problem is the axis being measured, not the number on it. - [x] Nothing fires; the fix is comparing the sequence against the requested task > Correct! Five calls is comfortably inside the threshold, so a volume rule sees nothing. Chapter 2 Section 5 states the working signal precisely: a hijack is caught only by inspecting a sequence of tool calls *against the task that was requested*. A summarisation request that produces a write to a configuration file is anomalous at one call. This is also the shape of the CurXecute case -- read a message, write one file. - [ ] Nothing fires, and this is why the detection belongs in Layer 5 instead > Layer 5 decides one request at a time and does not hold state across a session, which is exactly why Layer 5's own mapping hands sequence correlation to Layer 6. - [ ] The rule fires on the configuration write, since writes are always anomalous > A volume rule counts calls; it has no concept of a write. And an agent whose job includes writing files performs writes routinely -- what makes this one anomalous is its relationship to the stated task. ## Your organisation consumes a managed model API. You own no GPU, no serving container, and no part of the network path beneath the model. Which Layer 6 controls remain yours? > Hint: Compare this against Layer 3's ownership table, where a cloud-API consumer loses most rows. - [ ] Almost none -- Layer 6 is network security, so the provider holds it > This is the intuition the ownership table is designed to break. Seven of its nine rows stay with you on a cloud API; what you lose is the network path beneath the model. - [x] Egress control, behavioural baselines, and consumption anomaly -- most of them > Correct! Layer 6 does not shrink on a cloud API, it inverts. You lose IDS/IPS on serving traffic and virtual patching of the serving stack. You keep egress control from your application and orchestrator, output-drift and tool-call baselines, consumption and spend anomaly, orchestrator patching, and red-team testing -- and those are precisely the controls no product ships pre-configured, because only you know what your agent is supposed to do. - [ ] Only threat intelligence, since acting on it requires infrastructure you lack > Intelligence without a control to change is a subscription. The controls you own here are the ones intelligence should be routed into -- behavioural thresholds and egress rules among them. - [ ] Only the vendor assessment, which substitutes for the controls you cannot run > A vendor assessment covers the provider's stack. It says nothing about your orchestrator's egress rules or your agent's tool-call baseline, both of which run on your side. ## Attackers with keys harvested from exposed configuration files ran traffic against your model for weeks. Every request authenticated correctly and none individually exceeded a rate limit. Which Layer 6 signal closes this gap, and what is its uncomfortable property? > Hint: Chapter 2's account of this case names how the victims actually found out. - [ ] Output-drift baselining, since the attacker's prompts change response character > Response characteristics track what the model is asked, and abuse of stolen credentials for ordinary generation produces ordinary-looking output. Nothing in the response distribution marks the caller as illegitimate. - [x] Consumption anomaly per principal -- and it detects by the bill, not the traffic > Correct! This is the Storm-2139 pattern, and Chapter 2's verdict names this layer: the control is credential hygiene, spend caps, and anomaly detection on consumption. Because the credentials are real, per-request inspection sees nothing wrong -- so the signal has to be spend and volume per principal against its own history, with the alert threshold set *below* the hard cap. Layer 5 states the discomfort plainly: this closes the gap by noticing the bill, which is a lagging detection. - [ ] Signature rules on the credential pattern, once the leak has been documented > Signatures match attack payloads, not the legitimacy of a credential. The requests here contain no attack pattern -- the key is genuine and merely stolen. - [ ] Virtual patching the endpoint, since exposed credentials are a known weakness > There is no software vulnerability to patch. The endpoint behaved as designed and honoured valid credentials, which is why the answer is detective rather than preventive. ## CVE-2025-68613 is an authenticated RCE in n8n: a crafted workflow expression escapes the evaluation sandbox into the Node.js runtime, and exploitation needs only an account that can edit a workflow. Which Layer 6 control contributes most, and why? > Hint: There is no malicious packet here -- the payload is a legitimate expression from an authorised user. - [ ] IDS/IPS on the orchestrator's traffic, which flags the exploitation attempt > An IDS watching this traffic sees an authorised user saving a workflow over an authenticated session. Reading the case as one network monitoring would have caught files an application-layer authorisation problem as a perimeter one. - [x] Egress control from the orchestrator, which devalues the code execution > Correct! RCE as the n8n process matters because of what the process can reach -- Chapter 2 calls the orchestrator the credential store for the whole AI estate, plus the network position those credentials are used from. An egress allowlist does not stop the expression executing; it means the attacker's code can only reach destinations the workflows legitimately use. ATLAS carries this as `AML.M0032`, and it is available before any disclosure exists. - [ ] A virtual patch on the workflow-save path, blocking the payload shape > This is possible and it is the weakest kind of virtual patch: it inspects authenticated traffic to a legitimate endpoint against an expression language with many equivalent formulations. Treat it as raising cost during your upgrade window. - [ ] Behavioural baselining of model output, which shifts once n8n is compromised > Model output is the wrong place to look. The compromise is in the orchestration host, and its observable signals are a Node process spawning a shell or contacting unfamiliar destinations -- host telemetry, not model telemetry. ## Your agent's output is consumed by a new internal tool that renders it as rich text and fetches referenced images automatically. No CVE exists for the tool, and your team cannot ship a change to it this quarter. What is Layer 6's contribution under LLM10, and what stays unresolved? > Hint: Layer 6 can act on what the sink *does*, not on how the output is encoded. - [ ] Response filtering strips the dangerous markup before the tool receives it > That is a real control and it is Layer 5's, not Layer 6's -- and it requires knowing which encoding this particular sink is unsafe for, which is the knowledge the situation lacks. - [x] Block the sink's outbound fetch at the network; the encoding fix stays owed > Correct! A new sink is a new interpretation of text nobody audited for that interpretation, and the automatic fetch on render is the exfiltration channel -- the mechanism EchoLeak used through a reference-style Markdown image reference. Layer 6 can block that outbound action for a sink whose code you cannot change today. What it cannot do is choose the right encoding, because it does not know which sink the output is bound for. Chapter 2 Section 6 is explicit that each sink must encode for itself. - [ ] Add the tool to the model's system prompt so it formats output safely > Instructing the model about a downstream consumer is not a control -- the same untrusted content that reaches the model can override the instruction. The boundary has to be enforced outside the prompt. - [ ] Nothing, since a sink with no CVE falls outside Layer 6's remit > Novel output-boundary sinks are assigned to this layer explicitly, and the reason given is that sinks get disclosed faster than fixes can ship. A missing CVE does not remove the layer's interim role. ## A compromised agent's output was consumed by a second agent, which acted on it and passed results to a third. Leadership asks whether virtual patching every component would have prevented the cascade. What is the accurate answer? > Hint: Look at what Chapter 2 lists as the precondition for a cascade. - [ ] Yes -- containing the initial exploitation means the cascade never begins > This holds only when the initial compromise is a software exploit. Chapter 2 gives ASI08's precondition as any of the other agentic categories in one agent, and the dominant route is goal hijacking, which requires only text. - [x] No -- the usual trigger is injected text, and no patch blocks text > Correct! Virtual patching acts on exploitation of a disclosed software vulnerability. A cascade typically starts with ASI01 goal hijacking, whose entire prerequisite is text in something the agent reads. Chapter 2 also rates the cascade's runtime notice as late, usually at the last human gate -- so Layer 6's real contribution here is containment and correlation, and the structural fix is Chapter 2's: at least one gate in the chain must be a different *kind* of check than another agent. - [ ] No -- cascades are only detectable once the downstream artifacts are reviewed > Detection is genuinely late, but cross-component correlation can name the sequence as one event rather than three unrelated ones. The question is about prevention, and the reason patching fails is the trigger, not the timing. - [ ] Yes -- provided the virtual patches also cover the inter-agent message paths > Inter-agent messages carry text, not exploit payloads. Validating their contents is Layer 5's work and establishing sender identity is Layer 3's; neither is a patch. ## Which of these findings does NOT belong to Layer 6, and where does it belong instead? > Hint: One of these is invisible to any behavioural baseline by construction. - [ ] An agent contacted a destination outside its configured integration list > This is squarely Layer 6 -- an egress and behavioural signal, and one of the strongest available because it does not require recognising the technique that triggered the fetch. - [x] A fine-tuned model answers one topic with subtle bias and the rest normally > Correct! This is invisible to Layer 6 by construction. Token rate, latency, response length and formatting are all normal, the outputs are fluent, and subtle bias is *defined* by not tripping a safety filter -- so no baseline is disturbed. Poisoning is answered before the model serves traffic, by Layer 1's ingestion gate and Layer 2's validation and provenance (ATLAS `AML.M0008`). - [ ] Spend on one API credential rose from its usual daily figure to ten times it > Consumption anomaly per principal is a Layer 6 signal, and the one that closes the stolen-credential gap Layer 5 cannot see. - [ ] A disclosed RCE affects the serving engine, and the upgrade is two weeks out > This is the canonical virtual patching case: a disclosed vulnerability you cannot upgrade away yet, with a rule covering the interval.