1. Integrating Security into AI Architectures

Introduction

Every attack you studied in Chapter 2 shares a common thread: they exploit gaps where security wasn’t designed in from the start. Prompt injection succeeds when input validation is an afterthought. Data poisoning persists when training pipelines lack integrity checks. Model theft goes undetected when monitoring is bolted on rather than built in. The attacks are varied, but the root cause is the same – security was treated as a feature to add later, not a principle to build around.

This section bridges the gap between knowing the attacks and building the defenses. You’ll learn how traditional DevSecOps extends to AI systems, how to threat-model an LLM deployment, and how a shared responsibility model divides defense duties between AI providers and enterprise security teams. By the end, you’ll have the architectural mindset needed for the Blueprint layers that follow in Sections 2-8.

DevSecOps for AI

Traditional DevSecOps integrates security into every phase of the software development lifecycle – planning, coding, building, testing, deploying, and monitoring. AI systems follow the same principle but add stages that traditional software doesn’t have: data curation, model training, fine-tuning, and inference monitoring. Each of these stages requires its own security checkpoints.

The AI-Adapted DevSecOps Pipeline

graph LR
    P["Plan<br/><small>Threat Model</small>"]
    D["Develop<br/><small>Secure Coding</small>"]
    T["Train<br/><small>Data Integrity</small>"]
    V["Validate<br/><small>Red Team Testing</small>"]
    De["Deploy<br/><small>Container Scanning</small>"]
    M["Monitor<br/><small>Runtime Protection</small>"]
    F["Feedback<br/><small>Incident Response</small>"]

    P --> D --> T --> V --> De --> M --> F
    F -.->|"Continuous<br/>Improvement"| P

    SP["Security Checkpoint:<br/>AI Threat Model Review"]
    SD["Security Checkpoint:<br/>Prompt Hardening, Dependency Audit"]
    ST["Security Checkpoint:<br/>Data Lineage, Poisoning Detection"]
    SV["Security Checkpoint:<br/>AI Scanner Assessment,<br/>Adversarial Testing"]
    SDe["Security Checkpoint:<br/>Model Integrity Verification,<br/>AI-SPM Posture Check"]
    SM["Security Checkpoint:<br/>AI Guard Runtime Filters,<br/>Anomaly Detection"]

    SP -.-> P
    SD -.-> D
    ST -.-> T
    SV -.-> V
    SDe -.-> De
    SM -.-> M

    style P fill:#2d5016,color:#fff
    style D fill:#2d5016,color:#fff
    style T fill:#2d5016,color:#fff
    style V fill:#2d5016,color:#fff
    style De fill:#2d5016,color:#fff
    style M fill:#2d5016,color:#fff
    style F fill:#2d5016,color:#fff
    style SP fill:#1C90F3,color:#fff
    style SD fill:#1C90F3,color:#fff
    style ST fill:#1C90F3,color:#fff
    style SV fill:#1C90F3,color:#fff
    style SDe fill:#1C90F3,color:#fff
    style SM fill:#1C90F3,color:#fff

The key difference from traditional DevSecOps: the Train and Validate stages are entirely new, and the Monitor stage gains AI-specific responsibilities (prompt/response filtering, behavioral anomaly detection, cost monitoring).

What Changes for AI?

AI Threat Modeling

Threat modeling for AI systems builds on established methodologies but adapts them for the unique attack surfaces of LLM deployments. The goal is the same as traditional threat modeling: systematically identify what can go wrong, assess the risk, and design mitigations before deployment.

STRIDE Adapted for AI

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is one of the most widely used threat modeling frameworks. Here’s how each category applies to AI systems:

Threat Model for an LLM Deployment

The diagram below shows a threat model for a typical enterprise LLM deployment. Each numbered threat maps to an OWASP category, and each defense control maps to a Blueprint layer you’ll learn in subsequent sections.

graph TB
    subgraph "External"
        U["End Users"]
        A["Attackers"]
    end

    subgraph "Access Layer"
        GW["API Gateway /<br/>AI Gateway"]
        PF["Prompt Filter"]
        RF["Response Filter"]
    end

    subgraph "Application Layer"
        LLM["LLM Engine"]
        RAG["RAG Pipeline"]
        TOOLS["Tool / Agent<br/>Executor"]
    end

    subgraph "Data Layer"
        VS["Vector Store"]
        TD["Training Data"]
        MEM["Conversation<br/>Memory"]
    end

    U -->|"Prompts"| GW
    A -->|"1. Prompt Injection<br/>(LLM01)"| GW
    GW --> PF --> LLM
    LLM --> RF --> GW
    LLM -->|"Retrieval queries"| RAG
    RAG --> VS
    LLM -->|"Tool calls"| TOOLS
    A -.->|"2. Data Poisoning<br/>(LLM04)"| TD
    A -.->|"3. RAG Poisoning<br/>(LLM08)"| VS
    A -.->|"4. Memory Poisoning<br/>(ASI06)"| MEM
    TD -.-> LLM
    MEM --> LLM

    style A fill:#8b0000,color:#fff
    style U fill:#2d5016,color:#fff
    style GW fill:#1C90F3,color:#fff
    style PF fill:#1C90F3,color:#fff
    style RF fill:#1C90F3,color:#fff
    style LLM fill:#2d5016,color:#fff
    style RAG fill:#2d5016,color:#fff
    style TOOLS fill:#cc7000,color:#fff
    style VS fill:#cc7000,color:#fff
    style TD fill:#cc7000,color:#fff
    style MEM fill:#cc7000,color:#fff

The numbered threats in this diagram correspond to the attack categories you studied in Chapter 2. The blue-shaded defense controls (API Gateway, Prompt Filter, Response Filter) correspond to Blueprint Layer 5 (Secure Access to AI Services), which you’ll study in detail in Section 7. The orange-shaded components (Tool Executor, Vector Store, Training Data, Memory) are the at-risk assets that multiple Blueprint layers protect.

The Shared Responsibility Model for AI Security

Cloud computing established the shared responsibility model: the provider secures the infrastructure, the customer secures their data and applications. AI systems follow a similar pattern, but with additional layers that reflect the unique components of AI deployments.

Who Secures What?

The critical gap: most of the security responsibility for production AI deployments falls on the enterprise, not the AI provider. Providers offer safe base models and basic API infrastructure, but everything from prompt hardening to agent security to data classification is the enterprise’s responsibility.

The Self-Hosted Responsibility Shift

When organizations self-host models (using open-source LLMs, on-premises GPU clusters, or private cloud deployments), the responsibility boundary shifts dramatically. The enterprise takes on nearly all responsibilities – including model infrastructure security, weight protection, and even base model safety validation.

This is directly relevant to the infrastructure attacks covered in Chapter 2 Section 4: serialization exploits, adversarial inputs, and denial of service attacks all target components that self-hosting organizations must secure themselves.

From Attack Taxonomy to Defense Strategy

Chapter 2 gave you the attack vocabulary – the OWASP LLM Top 10, the Agentic AI Top 10, and the MITRE ATLAS framework. This chapter translates that vocabulary into defense architecture.

The mapping follows a simple principle: every attack category implies a defense requirement, and every defense requirement maps to one or more Blueprint layers.

The next section introduces the Blueprint framework in full detail. You’ll see how these six layers stack together into a defense-in-depth architecture, with Trend Vision One providing unified visibility across all layers.