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 framework introduced in Section 2 and the six layers that follow in Sections 3-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:#1565c0,color:#fff
    style SD fill:#1565c0,color:#fff
    style ST fill:#1565c0,color:#fff
    style SV fill:#1565c0,color:#fff
    style SDe fill:#1565c0,color:#fff
    style SM fill:#1565c0,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:

Where STRIDE Runs Out, and What to Use Instead

STRIDE earns its place because it is already in your organization’s process and it forces coverage — six categories you cannot skip. But it was designed for systems with predictable logic and fixed trust boundaries, and Chapter 2 Section 5 described a system that has neither. An agent is not one entity in a data flow diagram. It is a caller, a callee and a data store at once, its output becomes its own next input, and the boundary you drew at design time moves whenever it acquires a tool.

The Cloud Security Alliance published MAESTRO in February 2025 for exactly this gap. It replaces STRIDE’s threat categories with seven layers to reason across – foundation model, data operations, agent frameworks, deployment infrastructure, evaluation, orchestration, and the wider ecosystem – so multi-agent interaction and cross-layer effects are in scope by construction rather than by the modeller remembering to look.

Which one to reach for:

The pairing matters more than the choice. A threat model tells you what could go wrong; ATLAS tells you what has actually been done. Running one without the other produces either a tidy diagram with no detections behind it, or a technique list nobody can trace to a design decision.

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/>(LLM05)"| TD
    A -.->|"3. RAG Poisoning<br/>(LLM09)"| 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:#1565c0,color:#fff
    style PF fill:#1565c0,color:#fff
    style RF fill:#1565c0,color:#fff
    style LLM fill:#2d5016,color:#fff
    style RAG fill:#2d5016,color:#fff
    style TOOLS fill:#a85800,color:#fff
    style VS fill:#a85800,color:#fff
    style TD fill:#a85800,color:#fff
    style MEM fill:#a85800,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 Boundary Moves With the Deployment Model

The table above describes a hosted API. That boundary is not fixed – it slides, and the direction is always the same. Knowing where it sits for a given system is the single most useful thing this section gives you, because it determines which of the six Blueprint layers you are obliged to staff.

Two rows deserve a second look, because they are where the model breaks rather than merely shifts.

“Base model safety” is not a responsibility you can hold once. Chapter 2 Section 7 showed that alignment does not survive the journey from a provider’s release to a deployed artifact: distillation, community fine-tuning and quantization each change safety behaviour without changing capability benchmarks. A provider’s safety claim covers the artifact they shipped. If you distilled, fine-tuned, quantized or downloaded a variant, the claim does not transfer – and neither does the responsibility.

“Tool and agent security” was never anyone’s but yours, at every deployment model. It is the only row with no provider column at all, and it is the row that Chapter 2 Section 5 demonstrated does the most damage. Read the two facts together: the highest-consequence attack surface in the course is the one no vendor has ever offered to cover.

The self-hosted column is where the infrastructure attacks from Chapter 2 Section 4 land – serialization exploits, adversarial inputs and denial of service all target components a hosting provider was previously absorbing.

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 TrendAI Vision One providing unified visibility across all layers.