7. Layer 5: Secure Access to AI Services

Introduction

A team ships a customer-facing assistant. Security asks what protects it, and the answer is “we bought a prompt filter.” That is a real control, it is in the request path, and it will block a large share of what arrives. It is also, on its own, roughly a third of this layer – and Section 2 already named the failure: “a team that buys ‘a prompt filter’ and considers Layer 5 complete has bought half of it.”

Layer 5 is the only layer in the Blueprint that can refuse a live request. That makes it the layer people reach for first, and it makes overclaiming for it the most expensive mistake in Chapter 3. Chapter 2 Section 6 ends with an instruction aimed directly at this section:

“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.”

This section is written to survive that check. Layer 5 has four control families – a gateway with a defensible position, zero-trust access scoping, input-side inspection, and output-side validation – and each one is presented with the attack that defeats it, because Chapter 2 documented those attacks and a defense section that omits them is teaching a filter you will trust too much.

What Layer 5 Owns – and What It Cannot Stop

Section 2 compares layers by the kind of control they contain rather than by their number. Layer 5 has the simplest entry in that table and the most consequential one:

Layer 5 is in-path, in both directions, and it is the only layer that is.

• In-path on the request. Authentication, authorization scoping, normalisation, injection detection, content policy, entitlement resolution, quota enforcement. Every one of these can refuse the request before a token is generated.
• In-path on the response. PII detection, policy classification, sink-specific sanitisation, outbound-reference inspection. Every one of these can alter or withhold a response that has already been generated.
• Detective as a by-product. The gateway is the only component that sees every prompt and every response, which makes it the source of the telemetry Layer 6 baselines against – Section 2 records that dependency explicitly, and ATLAS carries it as AML.M0024 AI Telemetry Logging.

That position is genuinely privileged. It is also narrower than it sounds, and three limits decide how you should budget for this layer.

Limit 3 generalises into the sentence worth carrying out of this section. Layer 5 inspects one request and one response at a time. Anything whose signal only appears across a sequence – goal drift, slow extraction, trust accumulation – is outside its window by construction, not by immaturity of the product.

Set against that, Layer 5 is named as a primary defense in 11 of the 20 OWASP categories, more than any other layer. Both facts are true simultaneously, and Section 2’s warning is the reconciliation: coverage counts how many categories a layer touches, not how completely it resolves any of them. The mapping table at the end of this section states the split for all eleven.

Which Layer 5 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.” For Layer 5 the deciding question is narrower than the deployment pattern: is there a network hop between the user and the model that you control? If there is, you can put a gateway on it. If there is not, most of this section is unavailable to you at any price.

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

1 · Layer 5 ownership tracks the request path, not the stack. Consuming a cloud API removes almost all of Layer 3 from your plate. It removes almost none of Layer 5, because the request still leaves your application, and the hop where it leaves is yours to instrument. This is the inverse of Layer 3 and it surprises teams who assume “managed” means “covered.”

2 · The provider’s guardrail is not your Layer 5. Chapter 1 Section 3 established that provider moderation is a stack, not a switch, and it is tuned to the provider’s policy, not yours. It will not know that “customer account numbers” are sensitive in your corpus. Treat it as a second, independent filter you get for free – which is worth having, on the redundancy argument – and not as the control that discharges the obligation.

3 · The rightmost column has no Layer 5 answer, and pretending otherwise is worse than admitting it. Chapter 2 Section 7 works through the SLM case: with no proxy between user and model, prompt-side filtering has nowhere to run and rate limiting has no compensating control at all. What buys back part of it is an architectural move rather than a control – constrain the input surface: fixed prompt templates, no free-text passthrough to the model. And on the rate-limiting row, Chapter 2’s conclusion stands unchanged: if unlimited free querying of the model is a problem for you, edge is the wrong architecture, not a risky one to be accepted with mitigations.

AI Gateway Architecture

An AI Gateway is a centralized point of control for all traffic between users (or agents) and AI services. It sits in the request path and applies policy to every interaction – authentication, input inspection, routing, output validation, quota enforcement, and logging.

MITRE ATLAS carries the concept as a named mitigation, AML.M0020 Generative AI Guardrails, and its definition is a precise statement of the layer’s scope: “safety controls placed between users, tools, and generative AI models to evaluate prompts, retrieved context, model outputs, and agent actions before they are accepted, executed, or shown to a user.” Note the four objects in that list. A gateway that inspects prompts and responses but not retrieved context or agent actions is implementing half the mitigation, and the retrieved-context half is where EchoLeak entered.

How It Differs from Traditional API Gateways

Traditional API gateways handle routing, authentication, and rate limiting for REST/GraphQL APIs. AI Gateways do all of that plus:

• Semantic input analysis: evaluating the meaning of a prompt, not only its structure – which requires normalising the input first, for reasons the defense techniques below make concrete
• Output content inspection: treating the model’s response as untrusted output bound for a specific sink, rather than as a payload to forward
• Token-level accounting: metering consumption in tokens and currency, because a single request’s cost varies by three orders of magnitude
• Multi-model routing: directing requests by content type, data sensitivity, or cost – which makes the routing logic itself a trust decision
• Context assembly: deciding what goes into the window – system prompt, retrieved chunks, memory, tool results – which is the only place the provenance of each element is still known

That last bullet is the one with no traditional-gateway analogue, and it is the most under-built. By the time text is in the context window it is a flat sequence with no privilege levels (Chapter 2 Section 2). The assembly step is the last moment at which “this came from the user,” “this came from a retrieved document,” and “this came from a tool” are distinguishable facts.

AI Gateway Request Flow

graph LR
    UR["User Request<br/><small>Prompt or<br/>API call</small>"]

    subgraph "AI Gateway"
        AUTH["Authenticate<br/>& Scope<br/><small>Identity, entitlements,<br/>quota check</small>"]
        FI["Inspect Input<br/><small>Normalise, injection<br/>detection, policy,<br/>provenance labelling</small>"]
        ROUTE["Assemble<br/>& Route<br/><small>Context assembly,<br/>model selection</small>"]
        FO["Validate Output<br/><small>PII, policy, sink<br/>sanitisation, outbound<br/>reference scan</small>"]
    end

    LLM["AI Service<br/><small>Model inference</small>"]
    RESP["Response<br/><small>Released to the<br/>caller or sink</small>"]
    BLOCK["Blocked<br/><small>Policy violation<br/>logged and denied</small>"]

    UR --> AUTH
    AUTH --> FI
    FI -->|"Clean"| ROUTE
    FI -->|"Injection<br/>detected"| BLOCK
    ROUTE --> LLM
    LLM --> FO
    FO -->|"Safe"| RESP
    FO -->|"PII / policy<br/>violation"| BLOCK

    style UR fill:#2d5016,color:#fff
    style AUTH fill:#1565c0,color:#fff
    style FI fill:#1565c0,color:#fff
    style ROUTE fill:#1565c0,color:#fff
    style FO fill:#1565c0,color:#fff
    style LLM fill:#2d5016,color:#fff
    style RESP fill:#2d5016,color:#fff
    style BLOCK fill:#8b0000,color:#fff

Four checkpoints, and the two that matter most are the ones teams skip. Scope is evaluated at authentication time, not at retrieval time, in most implementations – which is the bug the entitlement section below is about. Validate Output is the only checkpoint that still exists after the model has been successfully manipulated, which is why Section 2 counts the input and output filters as two controls: they fail independently, because they look for different things.

Where the Gateway Sits

A gateway is only a control if requests cannot go around it. This is a design decision with four common answers and it is rarely made explicitly.

The column that decides it is “routed around by.” An in-process SDK is a linter: it is bypassed by forgetting, and forgetting scales with team size. A reverse proxy is bypassed by anyone holding a provider API key who can reach the internet, which means the gateway is only mandatory if network egress policy denies direct provider access – a Layer 3 default-deny egress rule with the gateway as the sole permitted destination. That coupling is worth stating as a rule:

Zero Trust Secure Access (ZTSA) for AI

Zero trust – “never trust, always verify” – is well established for network and application security. Applying it to AI service access means the identity, the device, the context, and the data the request will reach are all evaluated on every request, and that no part of the decision is delegated to the model’s cooperation.

Core ZTSA Principles for AI

Identity-based access. Every request to an AI service is authenticated. Note that AI systems typically carry two identities – the end user, and the service principal holding the provider credential – and the second is the one that gets stolen. Chapter 2 Section 1’s credential-abuse case is the shape: every request authenticated correctly, because the keys were real and merely stolen. ATLAS carries this as AML.M0019 Control Access to AI Models and Data in Production.

Continuous verification. Trust is not established once. A user who sent legitimate prompts for an hour can send an injection on the next request, and an agent that behaved for forty tool calls can be hijacked on the forty-first.

Least privilege, expressed as scope. A support assistant does not need the code-generation model; a code completion tool does not need financial data through RAG. Scope is the ZTSA object that carries this, and it has to be server-side: a scope the model is asked to respect is a suggestion.

Micro-segmentation of AI services. Different models, endpoints and tool sets sit in separate zones, so compromise of one does not grant the others. ATLAS names the agentic form AML.M0032 Segmentation of AI Agent Components.

ZTSA Policy Components

Keep the Secret Out of the Window

Chapter 2 Section 2 hands this section a specific job for LLM08: Hidden Context Exposure, and it is not a filtering job:

“Anything you tell the model is readable by anyone who can talk to it. Keep credentials and authorization out of the window entirely; enforce scope server-side where cooperation is not required.”

This is worth being blunt about, because the intuitive Layer 5 answer is wrong. You do not defend hidden context exposure by detecting extraction prompts, and you do not defend it by filtering system-prompt text out of responses. Both are backstops with a bypass rate above zero, and the value they protect is absolute: a leaked API key is leaked once and forever.

The ZTSA control that actually resolves LLM08 is architectural. Nothing that would be a crisis if disclosed goes into the context window.

• Credentials live in the gateway or the tool layer, and the model receives a tool it can call, never a key it can quote.
• Authorization decisions are made server-side against the caller’s identity. A system prompt that says “only answer HR questions for HR staff” is enforcing authorization inside the flat sequence, where it has no privilege; the same rule expressed as a data scope is enforced where the model’s cooperation is not required.
• What remains in the window is prompt engineering, and Chapter 2’s advice applies: assume it is discoverable. If leaking it would be a crisis, it was doing a job it cannot do.

Response-side detection of system-prompt fragments stays in the output validation section as what it is – a backstop that tells you an extraction attempt is in progress, which is useful intelligence and is not the control.

Entitlement Belongs Inside the Retrieval Query

Layer 1 classifies the corpus and controls who may write to it. It explicitly hands one decision here: “It cannot stop a model from repeating something that is legitimately in its corpus, for a user who was never entitled to read it – that is a retrieval-time entitlement decision, and it belongs to Layer 5.”

Chapter 2 Section 6 rates this the leakage vector most likely to reach a real organisation, and it is the one with no attacker in it: an in-scope question, a correct retrieval, a cited answer, and a reader who should never have seen the passage. The distinction that makes it a Layer 5 control rather than a Layer 1 one is that there is now a request, so there is an identity to evaluate against.

The implementation detail is the whole control: the entitlement predicate goes inside the retrieval query, not onto its results.

• Inside the query – the vector search is issued with the caller’s permitted-scope filter as part of the search itself, so unentitled chunks are never candidates and never enter the window.
• Onto the results – the search returns the top k by similarity and a post-filter drops the ones the user may not see. This looks equivalent and is not. The unentitled chunks consumed the k slots, so a user with narrow entitlements gets a degraded answer assembled from whatever survived, and any path that forgets the post-filter leaks. Chapter 1 Section 6 makes the same point about the retrieval pipeline: a vector index has no concept of a user, so permission filtering that is not inside the query is not a control.

The metadata that the filter reads is Layer 1’s to write and protect – Chapter 1 Section 6 flags relabelling a chunk as privilege escalation with no code execution. Layer 5 depends on that metadata being trustworthy, which is Section 2’s “Layer 1 informs Layer 5” dependency in its most concrete form.

Prompt Filtering and Injection Defense

Input inspection is the control most people mean by “AI security,” and the honest framing is Chapter 2’s: it is a cost-raiser, not a boundary. Deploy it – raising the cost of an attack is a real security outcome, and the measurements below show how real. Do not build an architecture whose safety depends on it holding.

The Filtering Pipeline

graph LR
    RP["Raw Input<br/><small>User text, tool output,<br/>retrieved document,<br/>image, audio</small>"]
    NM["Normalise<br/><small>Unicode NFKC, strip<br/>zero-width, decode,<br/>re-tokenize as the<br/>model will</small>"]
    ID["Injection<br/>Detection<br/><small>Pattern matching +<br/>classifier</small>"]
    CP["Content Policy<br/><small>Prohibited topics,<br/>sensitivity, compliance</small>"]
    PL["Provenance<br/>Labelling<br/><small>Tag each element by<br/>source and trust level</small>"]
    SP["Assembled<br/>Context<br/><small>Labelled input<br/>ready for the model</small>"]
    BL["Blocked<br/><small>Violation logged,<br/>alert generated</small>"]

    RP --> NM
    NM --> ID
    ID -->|"Clean"| CP
    ID -->|"Injection<br/>detected"| BL
    CP -->|"Compliant"| PL
    CP -->|"Policy<br/>violation"| BL
    PL --> SP

    style RP fill:#2d5016,color:#fff
    style NM fill:#1565c0,color:#fff
    style ID fill:#1565c0,color:#fff
    style CP fill:#1565c0,color:#fff
    style PL fill:#1565c0,color:#fff
    style SP fill:#2d5016,color:#fff
    style BL fill:#8b0000,color:#fff

Two things about this pipeline differ from the naive version, and both come from Chapter 2.

Normalisation is a stage, not an implementation detail. Chapter 2 Section 2 states the filter-evasion failure precisely: “a filter that tokenizes differently from the model is inspecting a different input.” If the model sees ıgnore prevıous as an instruction and the filter sees an unrecognised Unicode string, the filter is not weak – it is looking at something else. Normalise first, then inspect.

The input surface is every element of the window, not the user’s message. The Raw Input node lists five sources deliberately. In EchoLeak the payload arrived as a retrieved email; in GrafanaGhost it arrived as a log line; in CurXecute it arrived as a Slack message read by an agent. In none of them did the user type anything hostile. A filter mounted only on the user’s text field is mounted on the one input that was never the problem.

Defense Techniques

Normalise before inspecting. Unicode NFKC normalisation, zero-width and bidirectional-control character stripping, homoglyph folding, and decoding of the encodings the model handles natively (Base64, ROT13, leetspeak, URL encoding). Then re-tokenize with the target model’s tokenizer, so the filter’s view and the model’s view are the same string. This is the single highest-yield input-side change and it is usually missing.

Cover every modality. Chapter 2 lists cross-modal payloads among the evasions that work: instructions in the pixels of an uploaded image, in a document’s OCR layer, in transcribed audio, in a PDF’s invisible text layer. A text-only filter in front of a multimodal model inspects a fraction of the input surface. ATLAS makes coverage a named property of the guardrail mitigation for exactly this reason.

Pattern matching plus classification, and know what each is for. Blocklists catch the commodity attacks cheaply and are trivially evaded by anyone who reads them – their job is volume reduction, not security. Classifiers generalise beyond known phrasings and cost inference time. Neither one is the boundary, and a classifier is itself a model: Chapter 2 Section 4 makes the point that your input filter is a model with a decision boundary of its own, and therefore has adversarial examples of its own.

Label external content by provenance, and segregate it. Chapter 2 Section 2 gives indirect injection this control: “segregate and label external content, then cap the blast radius.” Concretely, at assembly time, wrap every non-user element in an unambiguous, non-forgeable envelope recording its source and trust level; strip any delimiter sequences the content itself contains, so it cannot close its own envelope; and make the trust level actionable – the strongest form is ATLAS AML.M0030 Restrict AI Agent Tool Invocation on Untrusted Data, which suspends tool invocation for the remainder of a turn in which untrusted content entered the window. That is the control that breaks the lethal trifecta at its third leg without needing to detect anything.

Context and Memory Validation

Layer 1’s mapping hands WarningASI06: Memory and Context Poisoning to this section with a specific unmet half: Layer 1 controls the write path and the classification, and cannot “detect a poisoned instruction inside content the agent is reading.”

Chapter 2 Section 5 rates ASI06 the worst category to already have: the only one that is both invisible to the user and indefinitely persistent. Layer 5’s contribution runs at two moments:

• On the way in. Anything an agent proposes to write to durable memory passes the same input pipeline as a prompt – normalised, inspected, and provenance-labelled – because a memory entry is a prompt that will be replayed on every future session. ATLAS AML.M0031 Memory Hardening is the reference control set, and its first item is that memory writes are authenticated and scoped to the right user, tenant, agent and session.
• On the way back out. Retrieved memory is untrusted content on re-entry, no matter that your own agent wrote it. Treating a prior write as trusted because it is “internal” is the assumption SpAIware exploited, and Layer 1 covers the case.

Be honest about the residual. A poisoned memory that reads as an ordinary preference – “the user prefers responses to be forwarded to this address” – passes every filter here, because nothing about it is anomalous in isolation. The durable control is the write-path allowlist at Layer 1 and the human-visible memory review; Layer 5 raises the cost.

Inter-Agent Message Validation

WarningASI07: Insecure Inter-Agent Communication is the second category Chapter 2 Section 5 splits between Layer 3 and Layer 5, and the split is clean. Layer 3 owns who the sender is – per-agent identity and mediated delegation, so an orchestrator’s request carries the original user’s entitlements rather than the orchestrator’s. Layer 5 owns what the message contains.

Treat an agent-to-agent message as external content and nothing else. It arrives from a peer whose context may already contain an attacker’s text, so a compromised agent is a fully authorised sender of hostile instructions. ATLAS names the control AML.M0033 Input and Output Validation for AI Agent Components: enforce a common format, validate against a schema, check for prohibited information, and sanitise to remove injections – on both the tool/agent inputs and their outputs.

And carry Chapter 2 Section 6’s caution across: a schema guarantees the container, never the contents. A message that validates as {"task": string} is fully satisfied by a task field containing an injection. Validate the field, not the envelope.

What Filtering Buys You, Measured

Numbers make the “cost-raiser, not a boundary” framing concrete rather than defeatist. Anthropic’s Constitutional Classifiers work is the best-instrumented public example of a production input/output guardrail:

Three readings, and the third is the one for your architecture:

1. The cost-raiser is large. Cutting universal jailbreak success from 86% to 4.4% is the difference between a technique that works and one that has to be rediscovered per target.
2. The overhead is now negligible, which removes the usual objection. A 23.7% compute premium is a budget conversation; ~1% is not.
3. The residual is not zero, and the effort behind that residual is not available to you. Those figures come from 1,700 hours of paid red-teaming against a classifier trained by a frontier lab. Your gateway’s rule set will not match them. Design as though the filter has a bypass rate in the low single digits, because the best measured one does.

Response Filtering and Output Validation

If input inspection protects the model, output validation protects everything downstream of it – and it is the more reliable half of Layer 5, for a structural reason. Input filtering has to recognise hostile intent in text an adversary wrote to be unrecognisable. Output validation checks whether a concrete, observable thing is present in a response: an SSN pattern, an outbound reference, an unescaped tag. That is a much easier question, and it is why the output filter is the checkpoint that survives a successful injection.

What Response Filtering Catches

The Renderer Is a Sink

The most instructive Layer 5 failures in 2025-2026 are not filters that were absent. They are validators that were present and passed.

• GrafanaGhost (April 2026): the exfiltration URL was protocol-relative – beginning // rather than https:// – so Grafana’s URL validator parsed it as a path rather than a host and allowed it, while browsers resolved it to the attacker’s domain.
• EchoLeak (CVE-2025-32711): the outbound fetch was routed through a Microsoft Teams proxy domain that CSP already allowed, so a domain allowlist was not merely bypassed – it was used as the delivery mechanism.

Both defeat the naive control this section used to recommend, “URL validation against known domains.” Three rules follow, and Chapter 2 Section 6 states them from the attack side:

1. Any surface that renders model output is an egress channel. A markdown image auto-fetch needs no user interaction and produces no artifact beyond a broken image. So does an OSC-8 terminal escape, and so does a CSS url().
2. Parse before you compare. Resolve the URL to an absolute form against the document base first, then evaluate the host. A validator that string-matches raw output is checking a different thing than the browser will.
3. An allowlisted domain is not a safe destination if it forwards. Open redirectors and proxy endpoints on trusted domains are exactly what EchoLeak used. The durable control is not a better allowlist – it is disallowing outbound fetches from rendered model output at all, and rendering images only from content you host.

Positioning: Streaming Versus Synchronous

Chapter 1 Section 6 and Chapter 2 Section 6 both hand this section the same architectural constraint, and it is the reason response filtering is a position rather than a function you call:

A streamed token is published. Once it has reached the client, output validation has nothing left to block. A filter can stop token 400 and cannot recall tokens 1 through 399, and a partially validated payload has already reached whatever is parsing the stream.

So streaming and output validation are in direct tension, and the resolution is a design decision about who is reading:

The row that catches teams is the third. “It’s just a chat UI, so we stream” is correct about the human and wrong about the renderer – the client rendering markdown is a downstream system, and it is the one both 2026 exfiltration cases went through.

Output Validation for Downstream Systems

When AI output feeds another system, treat it as untrusted input, because that is what it is. Chapter 2 Section 6 gives the reframing worth memorising: your model is an unauthenticated user that your application has given a very short path to its backend.

• HTML escaping for AI-generated content rendered in a page – at the point of rendering, in the templating layer, not at the gateway
• Parameterized queries for AI-generated database operations. Never concatenate model output into SQL, and note that a schema-validated {"query": string} object is not protection – constrained decoding guarantees the container, never the contents
• Argument arrays, not shell strings, for AI-generated commands, so there is no shell to escape for
• Control-character encoding by default for anything reaching a terminal, with raw output opt-in

Note where these live. Only the outbound-reference scan and the PII pass genuinely belong at the gateway; the rest belong at each sink, because the correct encoding depends on the interpreter and the gateway does not know which one the response is bound for. A gateway that “sanitises output” generically is escaping for a sink it guessed.

Rate Limiting and Abuse Prevention

AI services are expensive to operate and cheap to abuse. A single identity with unrestricted access can run up thousands of dollars in compute, monopolise capacity, or systematically probe the model. This is LLM06: Unbounded Consumption, and ATLAS carries the two halves as AML.M0004 Limit AI Service Query Volume and Rate and AML.M0036 Limit AI Workload Resource Consumption.

Multi-Dimensional Limits

Effective limits operate on several dimensions at once, because each dimension has an abuse pattern that stays under the others:

• Request rate – per minute, hour and day, per authenticated identity and per API key. Both, because the identity that gets stolen is the key
• Token budget – input and output, per request and per window. A single 200K-token request can cost more than a hundred short ones
• Cost ceiling – dollars per user, team and organisation per period. The only dimension denominated in the thing you actually lose
• Concurrency – simultaneous conversations or agent sessions
• Agent-loop bounds – maximum iterations, retries and tool calls per run. AML.M0036 names these explicitly, and they are the only limits that bound a runaway agent, which consumes no unusual rate and makes no oversized request

Do Not Sell the Model Cheaply

Two Layer 5 settings decide how expensive model extraction is, and both are decisions rather than controls:

• Log-probabilities. Chapter 2 Section 4 is direct: do not expose log-probabilities on a public endpoint unless a customer use case requires it. They multiply the information each query returns and correspondingly divide the number of queries an extraction attack needs.
• Sustained high-volume querying across a suspiciously broad input distribution is an abuse signal, not a good customer. This is the query-budget half of AML.M0004, and it is worth stating as policy before someone reads the usage graph as growth.

Anomaly Detection, and What It Cannot See

Beyond fixed limits, behavioural analysis catches abuse that stays under every individual threshold: a user whose 50 requests a day become 500, off-hours spikes, sequential prompts that walk the model’s boundaries, one device cycling accounts to reset per-user quotas.

Two honest qualifications. First, this is a detective control living inside an in-path layer – it produces an alert, and by design it fires on a pattern, which means after some of the abuse. Second, and more important, it is blind to the case where nothing anomalous happens: Section 2 works through credential abuse where Layer 5 sees calls that authenticate correctly because the credentials are real and merely stolen. Consumption anomaly detection is the control that closes that gap, and it closes it by noticing the bill, not the traffic.

Defense Perspective: EchoLeak

Layer 5 → OWASP Mapping

Layer 5 is named as a primary defense in 11 of the 20 categories across the LLM Top 10 and the Agentic AI Top 10 – more than any other layer, and Section 2 explains why: it is the only layer that sees every request and every response. For each one, the honest statement has two halves.

Read the fourth column down and the pattern is sharp: Layer 5’s boundary is the single request. Everything it resolves is decidable from one request and one response. Everything it hands on requires either state it does not hold (a sequence, a credential’s real scope) or an action it cannot take (un-disclosing, correcting). That is a more useful way to remember the split than the coverage count, and it is why 11 of 20 does not mean 55% of the problem.

AI Guard Cross-Reference

AI Guard provides the runtime enforcement for Layer 5, filtering prompts and responses in the live request path. Where AI Scanner assesses models for vulnerabilities before deployment, Guard operates during – inspecting every prompt for injection patterns and every response for leakage. Section 9 covers the full scan-protect-validate-improve loop, and the loop matters more here than anywhere else in the Blueprint for one reason the numbers above make plain: a filter’s value is its rule set, and a rule set decays. Scanner findings about a specific model’s susceptibility are what keep Guard’s Layer 5 rules aimed at the model you actually serve.

TrendAI Vision One’s ZTSA module enforces zero-trust access policy for AI service endpoints – identity, device posture, context and scope – and its AI Service Access capability adds the other half of Layer 5’s visibility problem: which AI services people are actually reaching, sanctioned or not, with prompt and response inspection on that path.

What no component in the platform supplies is the gateway itself. AI Guard is an API endpoint your gateway or LLM proxy calls per request and per response (Section 9 works through the placement and the LiteLLM pattern TrendAI documents). Routing, authentication and the decision that all AI traffic traverses one path remain yours to build and enforce – which is precisely why this section spends its length on gateway architecture rather than on a product. Two integration points are worth naming explicitly, because they are the ones that turn a product into a layer:

• Egress control makes the gateway mandatory. Vision One’s network policy is where “all AI traffic goes through the gateway” stops being a convention. Without it, the gateway is advisory.
• Gateway telemetry is Layer 6’s baseline. Every blocked injection and redacted response is a labelled event, and Section 2 records that a Layer 6 deployed without Layer 5 feeding it has far less to work with.

# ZTSA Policy: Customer-Facing Support Assistant
# ----------------------------------------------

identity:
  required: true
  provider: corporate-sso
  mfa: required
  groups_allowed: ["ai-users", "support-team"]
  service_principal: support-assistant-sp   # the key, tracked as its own identity

device_posture:
  managed_device: required
  endpoint_security: up-to-date
  os_patch_level: within-30-days

access_scope:
  models_allowed: ["support-assistant-general", "support-assistant-summary"]
  data_sources: ["public-kb", "product-docs"]
  entitlement: caller-scope-filter-in-query   # not a post-filter on results
  actions_allowed: ["text-generation", "document-summary"]
  actions_denied: ["code-execution", "tool-invocation", "file-write"]

input_pipeline:
  normalise: [unicode-nfkc, strip-zero-width, decode-common, retokenize-as-target]
  modalities_inspected: [text, image-ocr, document, audio-transcript]
  injection_detection: classifier + patterns
  blocked_patterns: ["ignore previous", "system prompt", "developer mode"]  # volume reduction only
  provenance_labelling: required
  on_untrusted_content_in_turn: suspend-tool-invocation      # AML.M0030
  max_input_tokens: 4096

output_pipeline:
  mode: streaming-to-human, synchronous-to-system
  pii_detection: enabled
  pii_action: redact
  outbound_references: strip            # not allowlist -- see EchoLeak
  render_surface_sanitisation: enabled
  entity_allowlist_check: enabled       # hallucinated packages, URLs, commands
  max_output_tokens: 2048

limits:
  requests_per_minute: 10
  tokens_per_hour: 100000
  cost_per_day_usd: 50.00
  cost_alert_usd: 30.00                 # the alert below the cap
  concurrent_sessions: 3
  agent_iterations_max: n/a             # no tool invocation in this profile

logging:
  level: full
  retain_prompts: true
  retain_responses: true
  alert_on: ["injection_detected", "pii_detected", "cost_alert", "rate_limit_exceeded"]

identity:            { required: true, provider: corporate-sso }
access_scope:
  data_sources:      ["all-internal-kb"]
  actions_allowed:   ["text-generation", "ticket-create", "ticket-update"]
input_pipeline:
  blocked_patterns:  ["ignore previous", "disregard", "system prompt"]
output_pipeline:
  mode:              streaming
  pii_detection:     enabled
  url_validation:    allowlist ["*.corp.example.com"]
limits:
  requests_per_minute: 60