2. Security for AI Blueprint Overview

Introduction

A stakeholder asks: “are we protected against data poisoning?” You know the attack – Chapter 2 Section 3 covered it. You can name three controls that address it. What you cannot do yet is answer the question the way it was asked: who owns that control, is it running, and what happens if it fails?

That gap is the difference between a threat taxonomy and a defense architecture. The OWASP LLM Top 10 and Agentic AI Top 10 answer what goes wrong. They are catalogues of failure, and they are deliberately silent about who fixes anything. The Security for AI Blueprint answers the other half: who owns the control, where it sits, and what it can and cannot stop. The two are complements, not competitors – and this section is where the second one gets built.

The previous section approached that mapping from the attack side: it took each Chapter 2 attack domain and pointed at the layers that answer it. This section turns the map around and works from the control side, because that is the direction you have to reason in when you are choosing what to build, staff, and pay for.

The Security for AI Blueprint

The Security for AI Blueprint organizes AI security into six layers. Each layer owns a distinct protection domain, and together they cover the full stack – from the data that trains and grounds a model to the runtime defenses that catch techniques nobody has seen yet.

The 6-Layer Architecture

graph TB
    subgraph Blueprint["Security for AI Blueprint"]
        L6["<b>Layer 6</b><br/>Defend Against Zero-Day Exploits<br/><small>Network IDS/IPS, Virtual Patching,<br/>Behavioral Anomaly Detection</small>"]
        L5["<b>Layer 5</b><br/>Secure Access to AI Services<br/><small>AI Gateway, ZTSA, Prompt/Response<br/>Filtering, Rate Limiting</small>"]
        L4["<b>Layer 4</b><br/>Secure Your Users<br/><small>Deepfake Detection, Endpoint Security,<br/>Shadow AI Governance</small>"]
        L3["<b>Layer 3</b><br/>Secure Your AI Infrastructure<br/><small>AI-SPM, Posture Management,<br/>Misconfiguration Detection</small>"]
        L2["<b>Layer 2</b><br/>Secure Your AI Models<br/><small>Container Security, Vulnerability Scanning,<br/>Model Integrity Verification</small>"]
        L1["<b>Layer 1</b><br/>Secure Your Data<br/><small>DSPM, Data Classification,<br/>Vector Store Security</small>"]
    end

    L6 --- L5 --- L4 --- L3 --- L2 --- L1

    TV1["<b>TrendAI Vision One</b><br/>(Unified Platform)<br/><small>Single-pane visibility across<br/>all six layers</small>"]

    TV1 -.->|"Monitors"| L6
    TV1 -.->|"Enforces"| L5
    TV1 -.->|"Protects"| L4
    TV1 -.->|"Manages"| L3
    TV1 -.->|"Scans"| L2
    TV1 -.->|"Classifies"| L1

    style L6 fill:#2d5016,color:#fff
    style L5 fill:#2d5016,color:#fff
    style L4 fill:#2d5016,color:#fff
    style L3 fill:#2d5016,color:#fff
    style L2 fill:#2d5016,color:#fff
    style L1 fill:#2d5016,color:#fff
    style TV1 fill:#1565c0,color:#fff

Layer-by-Layer Preview

Each of the next six sections covers one Blueprint layer in depth. The cards below summarize what each layer protects and the key controls it provides; follow a card to its section.

• Layer 1: Secure Your Data

  Protects: Training data, fine-tuning datasets, RAG corpora, vector stores, conversation logs, model embeddings, and data in transit.

  Data is the foundation of every AI system. Poisoned training data teaches the model the wrong things. Manipulated RAG corpora feed it false information. Leaked conversation logs compromise user privacy.

  Key controls: DSPM, data classification by sensitivity tier, vector store access controls, data lineage tracking, encryption at rest and in transit.

• Layer 2: Secure Your AI Models

  Protects: Model weights, model containers, fine-tuning pipelines, LoRA adapters, model artifacts, and model distribution channels.

  Models are the intellectual property of AI deployments. A compromised model can contain backdoors, leak training data, or execute malicious code. Supply chain attacks on model distribution affect every deployment downstream.

  Key controls: Container security, vulnerability scanning, model integrity verification, artifact signing, serialization safety checks, secure model registries.

• Layer 3: Secure Your AI Infrastructure

  Protects: Cloud AI resources, GPU clusters, model serving infrastructure, orchestration platforms, API backends, and configuration management.

  Infrastructure misconfigurations are one of the most common entry points for attackers. An over-permissioned GPU cluster, an unmonitored API endpoint, or a misconfigured model serving container can expose the entire AI stack.

  Key controls: AI-SPM, misconfiguration detection, risk insights, identity management, infrastructure monitoring, posture dashboards.

• Layer 4: Secure Your Users

  Protects: End users interacting with AI systems, employees using AI tools, stakeholders consuming AI-generated content, and the human-AI trust relationship.

  Users are both consumers and potential victims of AI systems. Deepfake content can manipulate decision-making. Shadow AI adoption can expose sensitive data to unvetted services. Over-trusting AI output leads to acting on misinformation.

  Key controls: Deepfake detection, endpoint security, shadow AI discovery and governance, user behavior analytics, AI content labeling, human-in-the-loop enforcement.

• Layer 5: Secure Access to AI Services

  Protects: AI service endpoints, API gateways, prompt and response channels, authentication and authorization for AI features, and the user-to-AI communication path.

  This is where most runtime attacks are intercepted. Prompt injection, jailbreaking, hidden context exposure, and output exploitation all pass through the access layer. Effective access controls stop attacks before they reach the model.

  Key controls: AI Gateway, ZTSA, prompt filtering, response filtering, rate limiting, input validation, API key management, cost monitoring.

• Layer 6: Defend Against Zero-Day Exploits

  Protects: The entire AI stack against novel, previously unknown attack techniques that bypass existing controls.

  AI security is an adversarial domain – attackers continuously develop new techniques. Zero-day defense ensures that even when specific controls are not yet updated, behavioral anomaly detection and threat intelligence catch novel threats.

  Key controls: Network IDS/IPS, virtual patching, behavioral anomaly detection, zero-day threat intelligence, runtime behavioral analysis, automated incident response triggers.

Comparing the Layers

Six descriptions do not make the layers comparable, and comparing them is the point: you will not deploy all six on day one, and the order you pick should follow from what each one actually does. Two properties separate them.

Control type – how a layer intervenes:

• Preventive (build-time) – acts before anything is serving traffic. A signed model artifact or a lineage-verified corpus is safe or unsafe by the time the first request arrives.
• In-path (runtime) – sits in the request path and can refuse a request or alter a response while it is happening.
• Detective (out-of-band) – observes continuously and reports. It does not touch the request. Its output is an alert, not a block.
• Human-boundary – constrains what a person is allowed to do with the system’s output, or what tooling they are allowed to reach.

Coverage – how many OWASP categories name that layer as a primary defense, counted from the master mapping tables on the chapter landing page across all 20 categories in the LLM Top 10 and the Agentic AI Top 10.

Three readings of that table do most of the work:

Layer 5 is both the broadest and the only in-path blocker. It is named in 11 of the 20 OWASP categories, more than any other layer, and it is the only one that can refuse a request while it is happening. For a system whose primary exposure is a live interface – a customer-facing chatbot, an internal assistant, a public API – that combination is why Layer 5 is normally the first investment.

Coverage is not stopping power. Layer 3 is the second-broadest at 10 of 20, and it blocks nothing. AI-SPM tells you a GPU cluster is over-permissioned, an endpoint is unmonitored, or an API key has no rotation policy. Every one of those is a real finding, and none of them is an interception. A layer with high coverage and no stopping power is telling you that a control somewhere else failed or was never configured – which is valuable, and is not the same as defense.

The layers are not substitutes, so “most coverage first” is a starting heuristic and not the decision. Layer 2 has the narrowest coverage at 3 of 20 and is the easiest to defer, and it is also the only layer that acts before anything is running. If you deploy a backdoored model, no amount of Layer 5 filtering recovers the situation, because the compromise is inside the thing the filter is protecting. Coverage tells you where to start; control type tells you what you are still exposed to after you start there.

Defense in Depth: Why Multiple Layers Matter

Defense in depth is the principle that no single control should be the only thing between an attacker and their objective. The version of it that is easy to state and wrong is that controls form a queue of gates: the attacker defeats one, meets the next, defeats that, meets the next. Real AI deployments are not built that way, and expecting them to be leads to the wrong investments.

Only Layer 5 is in the request path. Layers 1 and 2 have already finished their work by the time a request arrives. Layers 3 and 6 watch from beside the path and produce alerts. Layer 4 acts on the human at the far end. Depth here comes from controls of different kinds at different positions, not from stacking more gates in a line.

Where each layer actually sits

graph LR
    ATK["Attacker<br/><small>prompt injection<br/>targeting PII</small>"]
    GWIN["<b>Layer 5</b> · Access<br/><small>input filtering</small>"]
    MODEL["Model + RAG + tools"]
    GWOUT["<b>Layer 5</b> · Access<br/><small>output filtering</small>"]
    USER["User<br/><small>acts on the answer</small>"]

    ATK -->|"request"| GWIN
    GWIN -->|"if not blocked"| MODEL
    MODEL -->|"response"| GWOUT
    GWOUT -->|"if not redacted"| USER

    PRE["<b>Layers 1-2</b><br/>Data + Models<br/><small>acted before deployment:<br/>clean corpus, signed weights,<br/>classified stores</small>"]
    OOB["<b>Layers 3 + 6</b><br/>Infrastructure + Zero-Day<br/><small>watch continuously,<br/>never in the request path</small>"]
    HUM["<b>Layer 4</b> · Users<br/><small>bounds what a wrong or<br/>leaked answer can cause</small>"]

    PRE -.->|"constrains what<br/>can be retrieved"| MODEL
    OOB -.->|"alerts on anomaly"| GWIN
    OOB -.->|"alerts on anomaly"| MODEL
    HUM -.->|"gates the action"| USER

    style ATK fill:#8b0000,color:#fff
    style GWIN fill:#2d5016,color:#fff
    style GWOUT fill:#2d5016,color:#fff
    style PRE fill:#2d5016,color:#fff
    style OOB fill:#2d5016,color:#fff
    style HUM fill:#2d5016,color:#fff
    style MODEL fill:#a85800,color:#fff

Follow one attack through it. An injection payload reaches the input filter (Layer 5). If the filter misses it – and filters do miss novel phrasings – the payload reaches the model, which retrieves from a corpus whose sensitivity was already classified (Layer 1) and generates a response containing a customer’s email address. The output filter is a second, independent Layer 5 control, and it is scanning for PII patterns rather than for injection phrasing, so a payload that defeated the input filter has no particular advantage against it. The address is redacted.

Meanwhile Layer 3 has recorded an unusual access pattern against the model endpoint and Layer 6 has flagged the request as anomalous against its behavioral baseline. Neither one stopped anything. Both produced the evidence that this was an attack rather than an unlucky prompt – which is what turns a single redaction into an incident someone investigates.

That is the honest shape of defense in depth: one interception, two independent chances at it, and two detections that make the event legible afterwards. An architecture with only Layer 5 gets the redaction and never learns it was attacked.

How the Layers Interrelate

The six layers are not isolated silos. They share data, inform each other’s policies, and create feedback loops that strengthen the overall posture.

The key insight: the Blueprint is a system, not a checklist. Notice that the dependencies run in both directions across the numbering – Layer 1 configures Layer 5, and Layer 5 supplies Layer 6. Deployment order is not layer order, and a layer deployed without its inputs is weaker than the same layer deployed with them.

TrendAI Vision One: The Unified Platform

Six layers produce six streams of signal, and the problem that creates is not volume. It is that a cross-layer attack looks benign in each individual console.

Consider what each layer sees on its own during a credential-abuse incident. Layer 5 sees API calls that authenticate correctly, because the credentials are real – just stolen. Layer 3 sees compute utilization rising, which is what a successful product looks like. Layer 1 sees no data policy violation at all, because nothing sensitive was exfiltrated. Every layer is functioning, every layer’s dashboard is green or unremarkable, and the attack is in progress. The signal exists only in the correlation: valid credentials being used from a new region, at a new rate, against a new model, all starting within the same hour.

TrendAI Vision One integrates all six Blueprint layers into a single investigation surface. It does not replace the layer-specific controls – each layer keeps its own products and capabilities. What it adds is the join: alerts from different layers land on one timeline with a shared identity and asset context, so the pattern that no single console could see becomes a single detection. This is why unified visibility is a capability in its own right rather than a convenience feature, and why “we have all six layers” and “we would catch a cross-layer attack” are different claims.