8. Layer 6: Defend Against Zero-Day Exploits

Introduction

On a Tuesday in your quarter, someone publishes a prompt injection technique that gets past the classifier your gateway runs. Your Layer 5 vendor will ship a rule for it – in a release, on their schedule. Between the publication and that release, your system behaves exactly as it did on Monday: every request authenticates, every filter returns clean, every dashboard is green. Nothing in Layers 1 through 5 is broken. They are simply answering a question nobody has asked them yet.

That interval is what Layer 6 owns. Not an asset – every other layer in the Blueprint owns a noun, and Layer 6 owns a gap: the time between a technique existing and your controls knowing about it. Two very different controls live in that gap, and the section’s first job is to keep them apart, because they have opposite properties. Virtual patching blocks and only works on things already disclosed. Behavioural anomaly detection works on the genuinely unknown and blocks nothing. A Layer 6 program that does not know which of those it bought has bought neither.

What Layer 6 Owns – and What It Cannot Stop

Section 2’s comparison table records Layer 6 as detective plus containment, with a qualified Partly under “stops a live request,” and coverage of 6 of 20 OWASP categories. That row is accurate and it compresses two controls with almost nothing in common.

Virtual patching is preventive, it blocks, and it is not zero-day defense. A virtual patch is a rule that matches the exploitation of a specific, disclosed vulnerability. It requires a CVE, an advisory, or a published proof of concept – someone must have described the flaw before anyone can write a rule for it. The name on the layer says zero-day; this half of it is really zero-patch defense, and the distinction is not pedantry. It sets the boundary of what the control can be asked to do: virtual patching is worth a great deal against a vulnerability disclosed on Monday that you cannot upgrade away until the change window on the 20th, and worth exactly nothing against a technique nobody has written up.

Behavioural anomaly detection covers the genuinely unknown and produces an alert. It does not need a signature because it does not describe the attack – it describes you, and reports deviation. That is what makes it the only control in the Blueprint that can say anything at all about a technique with no name. It is also why its output is a page to a human rather than a dropped packet, and why its accuracy is a property of the baseline rather than of the product.

So the layer’s real shape is: the half that blocks needs the attack to be known, and the half that handles the unknown cannot block. There is no control here that does both, and reading Section 2’s “Partly” as “sometimes blocks, sometimes doesn’t” misses which half is which.

And there is one more limit, which the course has already established twice and which this layer has to sit with rather than argue against. Chapter 2 Section 5 rates six of ten agentic categories as having no reliable runtime signal, because the tool calls are all authorised and the traffic is normal. Chapter 2 Section 6 closes with an instruction aimed at this section by name: “at the output boundary, detection is the weakest of your options, and the section’s own evidence says so. Carry that scepticism into Layer 5 and Layer 6 and check whether they present monitoring as a primary control or as a backstop.”

Taken seriously, that is the frame for everything below. Layer 6 is a backstop. It buys you an interval, it bounds a blast radius, and it produces the evidence that turns an unexplained event into an incident someone investigates. It is not where a security program starts, and a novel technique that Layer 6 detects has already reached your system.

Which Layer 6 Controls Are Yours

Chapter 1 Section 3 promised that “the layers stay constant, but which ones are yours is set by the choice you make here.” Layer 6 is where that promise produces the most surprising answer, because the intuition – network security, so a self-hoster’s problem – is wrong in the direction that matters.

Read this against the five deployment patterns from Chapter 1.

The fifth pattern, hybrid, has no column because it inherits the row of whichever path a request takes – and note that a fallback router hands you the self-hosted column for the fraction of traffic that fails over, including its unpatched serving stack.

Three consequences, and they are the point of the table:

1 · Layer 6 does not shrink on a Cloud API – it inverts. Compare this with Layer 3’s ownership table, where a cloud-API consumer loses most rows outright. Here, seven of nine rows are yours in every column. What you lose is the network half beneath the model. What you keep is everything about your own application’s behaviour – and that is where the ASI01 and LLM06 signals live.

2 · The half that is sold and the half that is owned are different halves. IDS/IPS appliances, signature feeds and virtual patch subscriptions are purchasable, and in the two left-hand columns they cover a path you do not own. Tool-call sequence baselines, egress rules on your orchestrator, and a spend anomaly alert are yours in every pattern and no product arrives with them configured, because only you know what your agent is supposed to do.

3 · So the common Layer 6 program is the wrong one. An IDS subscription plus a threat-intelligence feed is a defensible Layer 6 for a self-hoster and close to theatre for a cloud-API consumer. Run this table before the checklist at the end of the section. A finding written against a serving container you do not operate is not a finding; an absent egress rule on an orchestrator you do operate is one, in every column.

Network-Level AI Protection

Intrusion Detection and Prevention Systems have been network security staples for decades, and pointing one at an AI deployment is not a matter of turning it on. The traffic looks different, the interesting boundary has moved, and the single highest-value rule is about what leaves rather than what arrives.

AI Traffic Monitoring

AI systems generate traffic that breaks assumptions built into general-purpose rule sets:

• Large payloads. Prompts and responses run to tens or hundreds of kilobytes against typical API payloads of a few. Size-based heuristics tuned for REST traffic will either alert constantly or be widened until they alert on nothing.
• Streaming responses. Server-Sent Events and WebSocket token streaming mean the response is not a single inspectable body. Anything that decides on a complete response either buffers – which the positioning discussion in Layer 5 covers as a latency trade – or works on fragments.
• Tool-call sequences. An agent generates rapid bursts of API calls as it works. The burst is normal; what changes under a hijack is the composition of the burst, which is not a rate question.
• East-west service mesh traffic. A self-hosted serving stack talks constantly between orchestrator, embedding service, vector store and inference engine. ShadowMQ is in Chapter 2 precisely because those internal sockets were assumed trusted and were reachable, so a monitoring policy that only watches the north-south edge is watching the wrong side of that case.

Three Rule Types, Three Different Intervals

The engine combines signature rules, behavioural rules and virtual patch rules, and the reason to keep them distinct is that each covers a different segment of a technique’s life. The diagram is the argument:

graph LR
    T0["Technique<br/>exists<br/><small>nobody knows</small>"]
    T1["First use<br/>against you"]
    T2["Published<br/>or disclosed"]
    T3["Signature or<br/>vendor patch ships"]
    T4["You have<br/>upgraded"]

    T0 --> T1 --> T2 --> T3 --> T4

    BEH["Behavioural rules<br/><small>the only cover here --<br/>and they only alert</small>"]
    VPR["Virtual patch rules<br/><small>block, and need the<br/>disclosure to exist</small>"]
    SIG["Signature rules<br/><small>block -- but by now<br/>it is not a zero-day</small>"]

    BEH -.->|"covers"| T1
    VPR -.->|"covers"| T2
    VPR -.->|"covers"| T3
    SIG -.->|"covers"| T4

    style T0 fill:#8b0000,color:#fff
    style T1 fill:#8b0000,color:#fff
    style T2 fill:#7a6a00,color:#fff
    style T3 fill:#2d5016,color:#fff
    style T4 fill:#2d5016,color:#fff
    style BEH fill:#1565c0,color:#fff
    style VPR fill:#1565c0,color:#fff
    style SIG fill:#1565c0,color:#fff

Read the red segment first. Between a technique existing and someone publishing it, behavioural rules are the entire Layer 6 offering, and they raise an alert rather than dropping a packet. Everything that blocks lives to the right of disclosure. That is the layer’s honest position, and it is why “we have zero-day protection” is a claim worth interrogating: most products in this space are strong in the amber and green segments, which is valuable and is not what the name promises.

Egress Is the Rule That Pays

Chapter 1 Section 7 assigns one control to this section by name: egress allowlisting at the network layer, as the answer to an agent whose web-fetch capability doubles as an exfiltration channel. It belongs here rather than in Layer 5 because it does not inspect anything – it is a reachability decision made before the run, enforced on the way out, and it is indifferent to whether the technique that triggered the fetch has a name.

That property is what makes it the strongest single rule in the layer:

• It survives a successful exploit. An attacker with code execution in your orchestrator or your sandbox holds credentials and a network position. An egress allowlist means the position is worth less – ATLAS carries this as AML.M0032 Segmentation of AI Agent Components, which specifies limiting resource and network access around agentic tools and code execution.
• It does not need to recognise the payload. Chapter 1’s sandbox test is the same rule stated as a design review: if the sandbox holds credentials or has network egress, it is not a sandbox. Layer 6 enforces at the network what that review decided.
• It has a known failure mode, and you should design for it. EchoLeak routed its exfiltration through a Microsoft Teams proxy domain the CSP already allowed. A domain allowlist was not bypassed; it was used as the delivery mechanism. So an allowlist bounds an attacker to your permitted destinations, and if one of those is a general-purpose proxy or a service that will forward arbitrary content, the bound is loose. Enumerate what each allowed destination can be made to do.

Virtual Patching for AI Systems

Virtual patching deploys a rule that blocks exploitation of a disclosed vulnerability without modifying the vulnerable software. For AI infrastructure the case for it is unusually strong, and the reason is worth stating precisely, because the usual framing gets the gap wrong.

The Gap Is Your Upgrade Window, Not the Vendor’s

The standard story is that virtual patches cover the interval between disclosure and the vendor shipping a fix. Sometimes true, and frequently not: n8n published fixed releases with its advisory, as most maintained projects now do. The gap that actually hurts is downstream of that – between a patched release existing and your instance running it – and for AI infrastructure that gap is wide for reasons specific to the stack:

• The dependency graph resists upgrades. A serving-engine bump can move a CUDA requirement, which moves a driver, which moves a container base image, which needs the model re-validated for output parity. This is not caution; it is a real compatibility surface.
• Inference endpoints are load-bearing and always on. Taking a production model offline is a customer-facing event, which pushes the change into a window.
• Nobody owns the orchestrator. It arrived as internal tooling, and the vulnerability-management program does not have it on the asset list. Chapter 2 names it the highest-value target in the stack and usually the least hardened.

Both Chapter 2 Section 4 and Layer 3 hand this section the same sentence – getting a patch deployed before you can upgrade – and that is the interval to have in mind.

How Virtual Patching Works

1. Disclosure lands. A CVE, advisory or proof of concept describes a flaw in something in your AI stack.
2. The exploitation path is identified. Not the vulnerability – the observable path. This step is where virtual patching succeeds or fails, and some flaws have no observable path at all.
3. A rule is written and deployed to the IDS/IPS, in hours, targeting that path.
4. Exploitation attempts are blocked while the vulnerable software keeps running.
5. The official patch is applied in the change window, and the virtual patch stays. Two independent defenses cover an incomplete fix, a regression, or a rollback that quietly reintroduces the flaw.

Step 2 is the one to be sceptical about. A virtual patch works when exploitation has a distinctive shape on the wire – a deserialization payload, a traversal sequence, a malformed header. It works poorly when the exploit is a legitimately-shaped request from an authorised principal, which is exactly the case study below.

Virtual Patching Coverage for AI Components

Read the fourth column. In every row there is a live vulnerability class that virtual patching cannot reach, and in every case the control that does reach it belongs to another layer. That column is the layer’s boundary drawn concretely.

Novel Output Sinks

The last row deserves its own note, because three separate pages send you here for it. Chapter 2 Section 6 assigns “novel output-boundary sinks (renderers, terminals)” to this layer, with the reason attached: sinks get disclosed faster than you can ship fixes. Layer 5’s mapping says the same from the other side – each sink must encode for itself, and Layer 6 virtual-patches the ones that have not yet.

The mechanism is worth being concrete about. Model output is safe or dangerous depending entirely on what reads it, and the set of things that read it keeps growing – a Markdown renderer, a terminal that honours escape sequences, an IDE that treats a code fence as executable, an MCP client that parses a tool description as instruction. Each new sink is a new interpretation of text nobody audited for that interpretation. EchoLeak’s exfiltration channel was a reference-style Markdown image reference whose syntax survived link-stripping: not a new vulnerability in the model, a new reading of its output.

What Layer 6 can do is block the action the sink takes – the outbound fetch on render, the callback, the resolution of a remote reference – at the network, for sinks whose own code you do not control or cannot ship today. What it cannot do is choose the right encoding, because it does not know which sink the output is headed for. That is why the durable fix is in the sink and this is explicitly the interim.

Behavioral Anomaly Detection

This is the half of Layer 6 that handles the genuinely unknown, and it earns that only when the baseline describes something an attack has to disturb. Most of the work is in choosing the right signal, and the two signals that matter most are the two that a naive implementation gets wrong.

Model-Specific Signals

Traditional behavioural detection watches CPU, connections and filesystem changes. AI deployments add signals that live above that:

Output-characteristic drift. A model whose responses shift distribution – length, vocabulary, formatting, the sudden appearance of embedded URLs or image references – may be under manipulation. This is the signal that catches a successful prompt injection whose technique you cannot recognise, because the injection’s purpose is to change what comes out.

Refusal and safety-trigger rates. How often the model declines, and on what categories. A shift here is one of the earliest indicators that requests have changed character, and it is cheap to instrument because the model is already producing the signal.

Latency and cost per request. Adversarial inputs constructed to be expensive show up as processing time and token spend before they show up as anything else. Baseline the distribution, not the mean – the interesting cases are in the tail.

Tool-call composition. Which tools, in what order, relative to what was asked. Covered on its own below, because it is the signal most often implemented as something weaker.

Sequence, Not Volume

Here is the signal the rest of the course keeps pointing at, and the one worth implementing properly. Chapter 2 Section 5 states it exactly: goal hijacking is caught “only by inspecting a sequence of tool calls against the task that was requested.” Layer 5’s mapping hands the same job over in the same terms, and its quiz makes the boundary explicit – sequence correlation against the requested task is Layer 6’s, because it needs state across a session that a per-request filter does not hold.

The weak implementation is a volume threshold: this agent normally calls two or three tools, so alert at fifteen. That catches a clumsy hijack and misses the realistic one, because an attacker whose injected instruction adds two tool calls stays comfortably inside the count. Chapter 2’s Cursor cases are the shape to think about: CurXecute needed the agent to read a Slack message and write one configuration file. That is not a burst.

What makes the signal work is comparing the sequence against the stated task:

• Anchor on the request. Hold what the user asked for, and evaluate each subsequent call for whether it plausibly serves that goal. A summarisation request that produces a write to a configuration file is anomalous at one call, not fifteen.
• Alert on first-use, not just frequency. A tool this agent has never invoked for this class of task is a stronger signal than an unusual count of tools it always uses.
• Watch for the read-then-write turn. The high-value pattern is a call that ingests untrusted content followed by a call with a side effect. Layer 5 prevents this by restricting tool invocation on untrusted data (AML.M0030); Layer 6 notices when the restriction is absent or was bypassed.
• Keep per-agent identity in the telemetry. Without it a multi-agent run is one undifferentiated stream, and ASI07 is invisible by construction. ATLAS AML.M0024 AI Telemetry Logging specifies intermediate agentic steps, tool use, and agent identity for exactly this reason.

Two honest qualifications. This produces an alert after some calls have executed – the detection point is mid-run, and what bounds the damage is Layer 4’s gate on the irreversible subset, not this. And it is only decidable where the requested task is recorded in a form a detector can compare against, which is an instrumentation decision made when the agent is built.

Consumption Anomaly Across Sessions

Layer 5’s mapping hands Layer 6 one thing under LLM06 explicitly: consumption anomaly across sessions, because a per-request limit cannot tell an expensive customer from an extraction campaign when every individual request is reasonable.

Storm-2139 is the case that makes this concrete, and Chapter 2’s verdict names this layer: “the control that would have prevented this is not model-level hardening – it is credential hygiene, spend caps, and anomaly detection on consumption.” The attackers used harvested keys, so every request authenticated correctly. Layer 5 saw legitimate credentials making permitted calls. The victims’ actual detection mechanism was the monthly bill.

So build the baseline on the axes the abuse actually moves:

• Spend per principal per day, with an alert threshold below the hard cap. A cap that only fires at the limit tells you after the money is gone.
• Request volume per credential against its own history, not against a global average. The signal is 50 becoming 500 for this key.
• Input-distribution shape per principal – systematic, near-identical queries walking a parameter are what model extraction looks like, and extraction is irreversible once complete.
• Credential reuse across origins, which is what a leaked key looks like before it looks like anything else.

The uncomfortable property, stated plainly in Layer 5: this control closes the credential-abuse gap by noticing the bill, not the traffic. That is a real detection and it is a lagging one.

Baselining and Drift Detection

A baseline is a claim about normal, and it decays. For an AI deployment it should cover response-length distribution, token generation rate, tool-call composition per task class, refusal and error rates, spend per principal, and resource utilisation – as distributions with percentiles, not single numbers.

Four practical constraints determine whether it works:

• Baseline per task class, not per system. An agent doing code review and the same agent doing customer replies have different normals. One merged baseline is wide enough to admit both attacks.
• Re-baseline on deliberate change. A model version bump, a prompt change, or a new tool moves the distribution legitimately. An un-refreshed baseline turns every release into an incident, and the team learns to ignore the alerts.
• Your alert budget sets your threshold, not the other way round. At production request volumes, a detector with an excellent false-positive rate still generates an unworkable number of alerts. Decide how many a human can actually adjudicate per day and derive the threshold from that – then be explicit that the residual is the attacks quiet enough to sit under it.
• The feed matters more than the algorithm. Baselines are built from labelled events, and Section 2 records where they come from: every injection Layer 5 blocked and every response it redacted. Layer 6’s accuracy is largely a function of Layer 5’s instrumentation.

Zero-Day Threat Intelligence

Intelligence is what converts the amber segment of the timeline into the green one – it is how a technique becomes a rule. General CVE feeds cover the traditional stack and lag on AI-specific classes, so the sourcing has to be deliberate.

External Sources

• OWASP LLM and Agentic AI projects – the LLM Top 10 and the Top 10 for Agentic Applications, both revised as the categories move. This course’s own 2026 renumbering came from one such revision.
• MITRE ATLAS – techniques, mitigations and case studies for adversarial AI, versioned by release. Two cautions from using it in anger: names drift between releases, and it is split into predictive and generative halves. AML.M0015 is Predictive AI Adversarial Input Detection and is the wrong half of the framework for anything LLM-shaped; the generative counterpart is AML.M0020 Generative AI Guardrails.
• Vendor and project advisories for everything you run – the serving engine, the orchestrator, the vector store, the container toolkit, the driver. This is the feed that produces virtual patches, and it is only as good as your inventory.
• Research and conference output – arXiv pre-prints, USENIX, IEEE S&P, Black Hat. Novel technique classes appear here first, typically months before any rule exists.
• Bug bounty and disclosure programs, increasingly run by AI vendors, which surface flaws in the platforms you consume rather than the ones you host.

Your Own Gateway Is the Source Nobody Buys

Section 2 records a dependency that belongs in this list and is missing from most Layer 6 programs: “blocked injection attempts and filtered responses generate the threat intelligence Layer 6 uses to build behavioral anomaly baselines.” Layer 5 states it from its own side – the gateway is the only component that sees every prompt and every response, which makes its telemetry Layer 6’s substrate.

This is the highest-value intelligence source you have, for a reason no external feed can match: it is labelled and it is about you. A blocked injection is a positive example from your own traffic, against your own model, in your own domain vocabulary. Two things follow. Retain gateway decisions long enough to baseline against them, which is a retention decision someone has to make deliberately. And treat a shift in blocked-attempt composition as intelligence in its own right – a new technique often shows up as your existing filters firing in an unfamiliar pattern before it shows up in anyone’s feed.

Intelligence Has to Terminate in a Change

A feed nobody acts on is a subscription. Each item should resolve into one of four outcomes, and the routing is the process:

1. A virtual patch rule – for a disclosed vulnerability in a component you run and cannot upgrade today.
2. A signature or filter update – for a documented technique with a recognisable shape, which mostly means a Layer 5 change rather than a Layer 6 one.
3. A behavioural threshold or signal change – for a technique whose effect is describable even where its form is not.
4. A posture reassessment – routed to Layer 3’s AI-SPM when a new vulnerability class affects a component’s configuration rather than its version.

And there is a fifth outcome that is not an update at all: a red-team exercise, because some intelligence is only actionable once you know whether it works against you. ATLAS specifies this as AML.M0035 AI Red Team – recurring, threat-informed exercises scoped across the whole system including agents, memory, tools, retrieval, identities and human workflows, with confirmed failures converted into regression tests, detection logic and deployment criteria. That last clause is the one that matters for this layer: a red-team finding that does not become a detection rule has been spent rather than invested.

Underneath all four routes sits an inventory precondition. ATLAS AML.M0016 Vulnerability Scanning covers model artifacts, downstream products and external software dependencies – and intelligence about a component you do not know you are running produces no action at all. That is the failure the case study below turns on.

Defense Perspective: n8n CVE-2025-68613

Layer 6 → OWASP Mapping

Layer 6 is named as a primary defense in 6 of the 20 categories across the LLM Top 10 and the Agentic AI Top 10. For each one, the honest statement has two halves – and for this layer a third question matters: which segment of the timeline is it covering?

Read the fourth column down and the pattern is different from every other layer’s. Elsewhere the limits are about reach – Layer 1 cannot see a request, Layer 5 cannot see a sequence, Layer 4 does not touch traffic. Layer 6’s limits are about timing. In every row it either blocks something already described, in which case it was never zero-day defense, or it detects something undescribed, in which case it alerts after the fact. There is no cell in this table where Layer 6 both handles a novel technique and stops it.

That is the correct reading of Section 2’s “Partly,” and it is also why the ASI08 row is the one to be most careful with. It is the only category where Layer 6 is named as the primary defense, and Chapter 2 rates its runtime notice as “late – usually at the last human gate.” A layer that owns a category and detects it late is telling you the real control is architectural.

AI Scanner Cross-Reference

AI Scanner contributes to Layer 6 by supplying the thing behavioural detection is worst at getting on its own: a description of normal that was not learned from production traffic. A baseline built by observation inherits whatever was happening during the observation window, including an attack already under way. A pre-deployment assessment establishes how the model responds when pushed, which techniques it is susceptible to, and what its refusal behaviour looks like before any user has touched it – which is a calibration input rather than a Layer 6 control. It also narrows the search: a model that Scanner shows is susceptible to a particular manipulation class tells you which output signals are worth alerting on. Section 9 covers the full scan-protect-validate-improve loop.

TrendAI Vision One’s Network Security component (TippingPoint) supplies the network half – IDS/IPS with virtual patch rules deployable within hours of disclosure, which is the control that matters for a self-hosted serving stack and an orchestrator you cannot upgrade this week. Behavioural correlation across the Vision One platform is what turns single-layer signals into one event: Section 2 works through the case where a consumption spike, an exposed-credential posture finding and an anomalous access pattern are individually unalarming and jointly unmistakable.

Read that against the ownership table before sizing the investment. In the two left-hand columns the platform is covering a network path you do not operate, and the controls that carry the most weight there – your orchestrator’s egress rules, your agent’s tool-call baseline, a spend alert below the cap – are configuration decisions on your side that no console arrives with. Buying the network half of Layer 6 for a cloud-API deployment and calling the layer done is the characteristic mistake this section exists to prevent.