Runbook 02 Enterprise AI Security Architecture Review

Purpose

This runbook provides a repeatable methodology for performing an Enterprise AI Security Architecture Review.

The goal is to evaluate whether an AI solution has been designed with appropriate security controls before production deployment or major architectural change.

A strong architecture review helps identify security weaknesses early, when they are easier and less expensive to correct.

The review should answer:

Does this architecture provide appropriate protection for the business use case, data, identities, AI components and supporting infrastructure?

Runbook Objective

Use this runbook to:

• Understand the business use case.
• Review the proposed AI architecture.
• Identify security boundaries.
• Review data flows.
• Review identity and authorization.
• Review LLM integration.
• Review RAG architecture.
• Review AI agents and tools.
• Review API security.
• Review cloud and platform security.
• Review secrets management.
• Review security logging.
• Review resilience and availability.
• Identify design weaknesses.
• Recommend security controls.
• Document architecture decisions.
• Define security conditions for production approval.

When to Use This Runbook

Use this runbook when:

• A new AI system is being designed.
• A Generative AI capability is being introduced.
• An organization is integrating an external LLM provider.
• RAG is being added to an existing application.
• AI agents or autonomous workflows are being introduced.
• Sensitive enterprise data will be exposed to AI.
• A new cloud AI platform is being deployed.
• Major architectural changes are planned.
• An AI platform is moving from development to production.
• Security architecture approval is required.
• A previous incident indicates architectural weaknesses.

Typical Enterprise Workflow

Business Requirement
        ↓
Solution Architecture
        ↓
Security Architecture Review
        ↓
Threat Modeling
        ↓
Security Requirements
        ↓
Engineering Changes
        ↓
Security Validation
        ↓
Risk Decision
        ↓
Production Deployment

Security should ideally become involved before implementation is complete.

Roles Involved

An architecture review may include:

• AI Security Engineer

• Security Architect

• Enterprise Architect

• Cloud Security Engineer

• Application Security Engineer

• AI / ML Engineer

• Software Architect

• DevSecOps Engineer

• Data Engineer

• Platform Engineer

• Privacy

• Risk and Compliance

• AI Governance

• Business Owner

The AI Security Engineer may lead or support the security review.

Required Inputs

Collect:

• Business requirements

• Architecture diagrams

• Data flow diagrams

• AI / LLM design

• RAG architecture

• AI agent design

• API specifications

• Identity architecture

• IAM roles

• Cloud architecture

• Network architecture

• Data classification

• Secrets management design

• CI/CD architecture

• Logging design

• Monitoring design

• Third-party integrations

• Security requirements

• Compliance requirements

• Existing threat models

• Deployment model

If an input is missing, record it.

Missing architecture information is itself a risk to effective review.

Architecture Review Workflow

Understand Business Requirement
          ↓
Identify Architecture Components
          ↓
Map Data Flows
          ↓
Identify Trust Boundaries
          ↓
Identify Assets
          ↓
Review Identity
          ↓
Review Data Security
          ↓
Review LLM Integration
          ↓
Review RAG
          ↓
Review AI Agents
          ↓
Review APIs
          ↓
Review Infrastructure
          ↓
Review Security Controls
          ↓
Review Logging
          ↓
Review Resilience
          ↓
Identify Threat Scenarios
          ↓
Identify Architecture Gaps
          ↓
Define Required Controls
          ↓
Document Decision

Phase 1 — Understand the Business Requirement

Before reviewing components, understand what the system is trying to achieve.

Document:

Business Use Case

Examples:

• Internal knowledge assistant

• Customer chatbot

• Security analyst assistant

• AI coding assistant

• Document summarization

• Fraud analysis

• AI-driven automation

Users

Identify:

• Employees

• Administrators

• Customers

• Partners

• Developers

• Service accounts

• AI agents

Business Criticality

Determine:

• Low

• Medium

• High

• Mission Critical

Sensitive Functions

Ask whether the system can:

• Access sensitive data

• Modify records

• Send communications

• Execute code

• Create resources

• Change permissions

• Perform financial actions

• Make business decisions

The greater the capability, the stronger the security requirements.

Business Review Checklist

• Business use case documented

• Business owner identified

• Users identified

• Criticality defined

• Sensitive functions identified

• Regulatory requirements identified

• Data sensitivity understood

• Human oversight requirements identified

Phase 2 — Identify Architecture Components

List every significant component.

Example:

Users
   │
   ▼
Web Application
   │
   ▼
API Gateway
   │
   ▼
AI Application
   │
   ├── LLM Provider
   ├── RAG Pipeline
   ├── Vector Database
   ├── Enterprise Data
   └── AI Agents

Supporting components may include:

Cloud Account
IAM
Secrets Manager
Object Storage
Containers
Kubernetes
Databases
Logging
Monitoring
SIEM
CI/CD
Source Control

Component Inventory

Create:

Component	Purpose	Owner	Trust Level
Web Application	User interface	App Team	Medium
API Gateway	API entry point	Platform Team	High
LLM Service	AI inference	AI Team	External/Internal
Vector Database	RAG storage	Data Team	High
Agent Service	Executes tools	AI Team	High

Phase 3 — Map Data Flows

Document how data moves.

Example:

Employee
   │
   │ Prompt
   ▼
Application
   │
   ▼
AI Service
   │
   ├── Retrieve Data
   │       ↓
   │   Vector Database
   │
   └── Generate Response
           ↓
        Employee

For every data flow ask:

• What data moves?

• Is it sensitive?

• Is it encrypted?

• Is it authenticated?

• Is authorization applied?

• Is it logged?

• Does it leave the organization?

Data Flow Checklist

• User input mapped

• Model input mapped

• Model output mapped

• RAG data flow mapped

• Agent data flow mapped

• External provider flow mapped

• Logging flow mapped

• Sensitive data paths identified

Phase 4 — Identify Trust Boundaries

A trust boundary exists where data crosses between different security contexts.

Examples:

Internet
   │
   ▼
Web Application

Application
   │
   ▼
External LLM Provider

AI Agent
   │
   ▼
Production System

RAG Pipeline
   │
   ▼
Enterprise Data

For each boundary ask:

• How is identity established?

• How is authorization enforced?

• Is traffic encrypted?

• Is input trusted?

• Is output trusted?

• What logging exists?

Trust Boundary Checklist

• Internet boundary identified

• Cloud boundaries identified

• External provider boundary identified

• RAG boundary identified

• Agent-to-tool boundary identified

• Administrative boundary identified

• Data boundary identified

Phase 5 — Identify Critical Assets

Typical AI assets include:

• Sensitive data

• User prompts

• LLM outputs

• System prompts

• Models

• Embeddings

• Vector databases

• API keys

• Credentials

• Service accounts

• Source code

• AI agents

• Logs

• Business workflows

For each asset identify:

• Owner

• Classification

• Required confidentiality

• Required integrity

• Required availability

Phase 6 — Review Identity Architecture

Identity should be explicit throughout the design.

Review:

User Identity

How does the application authenticate users?

Application Identity

How does the application authenticate to backend systems?

Workload Identity

How do cloud workloads authenticate?

AI Agent Identity

Does each AI agent have a separate identity?

Administrator Identity

How is privileged access controlled?

Identity Architecture Checklist

• Central authentication used

• MFA applied where appropriate

• User identity propagated safely

• Service identities separated

• AI agents use dedicated identities

• Least privilege applied

• Privileged access separated

• Long-lived credentials minimized

• Identity events logged

Architecture Principle

Every significant actor should have an identifiable and appropriately scoped identity.

Avoid architectures where many components share one highly privileged credential.

Phase 7 — Review Authorization Architecture

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Review whether authorization exists between:

User → Application
Application → Data
Application → LLM
RAG → Documents
Agent → Tools
Service → Service

Authorization Checklist

• User roles defined

• Data authorization enforced

• RAG respects user access rights

• API permissions scoped

• Agent permissions restricted

• Administrative operations protected

• Authorization occurs outside model instructions

• Authorization failures logged

Critical Architecture Principle

Never design:

User
  ↓
LLM
  ↓
"Decides whether user is allowed"

Prefer:

User
  ↓
Trusted Authorization Layer
  ↓
Approved Data / Action
  ↓
LLM

The model should not become the primary security boundary.

Phase 8 — Review Data Architecture

Identify:

• Data sources

• Data owners

• Data classifications

• Storage locations

• Processing locations

• Retention

• Data transfers

Review whether sensitive data enters:

• Prompts

• RAG

• Logs

• Model context

• External AI providers

Data Architecture Checklist

• Data inventory exists

• Sensitive data identified

• Data classification applied

• Data minimization considered

• Encryption in transit enabled

• Encryption at rest enabled

• Retention defined

• Deletion process exists

• Cross-border considerations reviewed where applicable

• Third-party data handling reviewed

• Logging avoids unnecessary sensitive data

Phase 9 — Review LLM Integration Architecture

Understand how the application interacts with the model.

Example:

User Input
    ↓
Application
    ↓
Prompt Construction
    ↓
LLM API
    ↓
Model Output
    ↓
Application Processing
    ↓
User

Review:

• Prompt construction

• System instructions

• Context

• Input handling

• Model outputs

• Error handling

• API credentials

• Rate limits

LLM Architecture Checklist

• Model provider identified

• Model purpose documented

• Prompt flow documented

• Model input classified

• Model output treated as untrusted

• Output validation defined

• API credentials protected

• Rate limits defined

• Failure behavior defined

• Sensitive actions not dependent solely on model output

Phase 10 — Review System Prompt Design

System prompts may contain:

• Instructions

• Business logic

• Security guidance

• Internal context

Do not assume system prompts can reliably act as strong access-control mechanisms.

Review:

• Whether sensitive information is unnecessarily embedded

• Whether secrets are embedded

• Whether business rules rely entirely on prompt instructions

• Whether application controls exist outside the prompt

System Prompt Checklist

• No credentials embedded

• No unnecessary sensitive data embedded

• Security boundaries enforced outside prompt

• Prompt changes controlled

• Prompt versions tracked where appropriate

Phase 11 — Review RAG Architecture

RAG commonly introduces:

Data Source
    ↓
Ingestion
    ↓
Processing
    ↓
Embeddings
    ↓
Vector Database
    ↓
Retrieval
    ↓
LLM Context

Every stage needs review.

RAG Architecture Checklist

Data Sources

• Approved sources identified

• Data owners identified

• Sensitive content classified

Ingestion

• Ingestion permissions restricted

• Source validation exists

• Changes logged

• Malicious content considered

Vector Database

• Access restricted

• Encryption enabled

• Network exposure minimized

• Backup and recovery considered

Retrieval

• User authorization enforced

• Data segmentation implemented where required

• Results filtered according to access

• Retrieved content treated as untrusted

Critical RAG Principle

Retrieval must not bypass the organization’s existing data permissions.

If a user cannot open a document directly, the AI assistant should not automatically provide its contents.

Phase 12 — Review AI Agent Architecture

Agents require special attention because they can move from:

Generate Information

to

Perform Actions

Example:

User
 │
 ▼
AI Agent
 │
 ├── Email
 ├── Database
 ├── Cloud API
 ├── Ticketing
 └── Code Repository

Review every connected tool.

Agent Architecture Checklist

• Agent purpose defined

• Agent identity defined

• Tools inventoried

• Permissions documented

• Least privilege applied

• High-risk operations identified

• Tool inputs validated

• Tool outputs validated

• Human approval defined

• Action limits defined

• Actions logged

• Emergency disable capability exists

Agent Risk Tiering

Consider classifying agents.

Low Risk

Read-only access to public or low-sensitivity information.

Medium Risk

Read access to internal information.

High Risk

Ability to modify enterprise systems.

Critical Risk

Ability to:

• Change permissions

• Execute production code

• Transfer money

• Delete critical data

• Perform privileged administrative actions

Security controls should increase with agent capability.

Phase 13 — Review API Architecture

AI systems commonly depend on multiple APIs.

Review:

User
 ↓
Application API
 ↓
AI API
 ↓
Data API
 ↓
Tool API

API Architecture Checklist

• APIs inventoried

• Authentication defined

• Authorization defined

• TLS used

• Rate limiting implemented

• Input validation defined

• Error handling defined

• Secrets protected

• API logging enabled

• Administrative APIs separated

• Public exposure minimized

Phase 14 — Review Secrets Architecture

Identify where secrets exist.

Examples:

• LLM API keys

• Cloud credentials

• Database passwords

• Service tokens

• Certificates

Prefer:

Application
    ↓
Managed Identity / Secret Store
    ↓
Backend Service

Avoid:

Source Code
    ↓
Hardcoded API Key

Secrets Checklist

• Central secret management used

• Hardcoded credentials prohibited

• Short-lived credentials preferred

• Secret access logged

• Rotation supported

• Environment separation implemented

• Agent secret access minimized

Phase 15 — Review Cloud Architecture

If the solution is cloud-hosted, review:

• Accounts / subscriptions

• IAM

• Networks

• Storage

• Compute

• Containers

• Logging

• Key management

• Secrets

• AI services

Cloud Security Checklist

• Production environment separated

• IAM least privilege applied

• Network segmentation used

• Public exposure minimized

• Private connectivity considered

• Encryption configured

• Cloud audit logging enabled

• Security monitoring enabled

• Resource ownership defined

• Backup and recovery defined

Phase 16 — Review Container & Kubernetes Architecture

If containers are used:

• Trusted images

• Image scanning

• Minimal images

• Non-root execution

• Runtime permissions

• Secrets

• Resource limits

If Kubernetes is used:

• RBAC

• Workload identities

• Network policies

• Admission controls

• Secrets

• Pod security

• Logging

Container / Kubernetes Checklist

• Trusted container registry used

• Images scanned

• Containers run with minimal privilege

• Kubernetes RBAC reviewed

• Workload identities separated

• Network policies considered

• Secrets managed appropriately

• Resource limits configured

• Audit logging enabled

Phase 17 — Review Network Architecture

Understand network flows.

Example:

Internet
   ↓
WAF
   ↓
Application
   ↓
Private AI Service
   ↓
Private Data Layer

Review:

• Public endpoints

• Private endpoints

• Firewalls

• Security groups

• WAF

• Egress restrictions

• Service-to-service communication

Network Checklist

• Public endpoints identified

• Public exposure justified

• Internal services private where possible

• Inbound restrictions implemented

• Outbound restrictions considered

• TLS enforced

• Administrative paths restricted

• Network monitoring available

Phase 18 — Review Supply-Chain Architecture

Identify external dependencies.

Examples:

• Models

• Model repositories

• Python packages

• Container images

• Plugins

• Datasets

• SaaS providers

• AI APIs

Review trust relationships.

Supply-Chain Checklist

• Model source verified

• Dependency sources approved

• Container provenance verified

• Third-party AI providers reviewed

• Dataset provenance understood

• Vulnerability scanning implemented

• Update process controlled

• Dependency inventory maintained

Phase 19 — Review Logging Architecture

Security architecture must include observability.

Potential logs:

Identity Logs
Application Logs
API Logs
LLM Activity
RAG Retrieval Logs
Agent Tool Logs
Cloud Audit Logs
Infrastructure Logs
Security Alerts

Review the path:

AI System
    ↓
Logging
    ↓
Central Log Platform
    ↓
SIEM
    ↓
Detection
    ↓
SOC

Logging Checklist

• Required log sources identified

• Logs centralized

• Agent actions logged

• Authentication events logged

• Authorization failures logged

• RAG changes logged

• Administrative changes logged

• Sensitive data protected in logs

• Retention defined

• SOC access available

Phase 20 — Review Detection Architecture

Ask:

If someone abuses this AI system, how will we detect it?

Potential detections:

• Repeated prompt abuse

• Abnormal retrieval patterns

• Excessive data access

• Unusual agent actions

• Credential misuse

• Knowledge-source modification

• Abnormal resource consumption

• Suspicious administrative changes

Detection Checklist

• Important threat scenarios identified

• Relevant telemetry available

• Detection logic defined

• Alerts routed to correct team

• Escalation process defined

• False-positive handling considered

Phase 21 — Review Incident Response Architecture

Architecture should support containment.

Ask:

If the AI system is compromised, what can we disable?

Possible controls:

Disable User
Disable Agent
Revoke Token
Rotate Secret
Block API
Remove Data Source
Disable Model
Isolate Workload
Restrict Network

Incident Response Checklist

• Users can be disabled

• Agent identities can be disabled

• Tokens can be revoked

• Secrets can be rotated

• Malicious data can be removed

• Workloads can be isolated

• Logs are retained

• Response ownership defined

Phase 22 — Review Availability & Resilience

AI systems may depend on:

• External model providers

• APIs

• Vector databases

• Cloud services

• Internet connectivity

Review failure scenarios.

Example

Primary LLM Provider
       │
       X
       │
Application Failure

Ask:

• Is fallback required?

• What happens when the model is unavailable?

• What happens during high usage?

• Are timeouts configured?

• Are retry limits defined?

Resilience Checklist

• Critical dependencies identified

• Single points of failure identified

• Timeouts defined

• Retry behavior controlled

• Resource limits defined

• Backup strategy defined

• Recovery procedures documented

• Provider outage considered

Phase 23 — Review Privacy Architecture

AI applications may process personal or confidential information.

Review:

• What information enters prompts?

• What is retained?

• Who can retrieve it?

• Is it used for model improvement?

• Does it leave the organization?

Privacy Checklist

• Personal data identified

• Purpose defined

• Data minimization applied

• Retention defined

• Third-party processing understood

• User transparency considered

• Privacy team involved where required

Phase 24 — Identify Threat Scenarios

Now challenge the architecture.

Potential scenarios:

Scenario 1 — Prompt Manipulation

Can malicious instructions alter expected behavior?

Scenario 2 — RAG Poisoning

Can untrusted content influence responses?

Scenario 3 — Unauthorized Data Retrieval

Can users access information outside their authorization?

Scenario 4 — Agent Abuse

Can manipulation cause an agent to execute an unauthorized action?

Scenario 5 — Credential Theft

Could compromise expose API keys or service identities?

Scenario 6 — Supply-Chain Compromise

Could a malicious model or dependency enter the environment?

Scenario 7 — Logging Failure

Could abuse occur without sufficient investigation evidence?

Threat Review Workflow

Threat
  ↓
Affected Component
  ↓
Attack Path
  ↓
Existing Control
  ↓
Control Gap
  ↓
Business Impact
  ↓
Architecture Recommendation

Phase 25 — Identify Architecture Security Gaps

A security architecture gap is different from a normal implementation bug.

Examples:

Weak Design

AI Agent
   ↓
Shared Administrator Credential

Recommended:

AI Agent
   ↓
Dedicated Identity
   ↓
Least Privilege

Weak Authorization

User
  ↓
AI
  ↓
All Enterprise Documents

Recommended:

User
  ↓
Authorization
  ↓
Approved Documents
  ↓
AI

Weak Output Trust

LLM Output
    ↓
Automatic Execution

Recommended:

LLM Output
    ↓
Validation
    ↓
Policy Check
    ↓
Human Approval if Required
    ↓
Execution

Phase 26 — Define Security Requirements

Convert identified gaps into architecture requirements.

Use:

REQ-AI-001
AI agent identities must use least privilege.

REQ-AI-002
RAG retrieval must enforce source-system authorization.

REQ-AI-003
LLM-generated actions must be validated before execution.

REQ-AI-004
AI agent tool calls must be centrally logged.

REQ-AI-005
Production API credentials must be stored in an approved secrets platform.

Good requirements are:

• Specific

• Testable

• Actionable

• Assignable

Phase 27 — Prioritize Architecture Findings

Classify findings based on:

• Business impact

• Data sensitivity

• Exploitability

• Privilege

• User exposure

• Existing controls

Example:

ID	Architecture Finding	Priority
AR-01	RAG bypasses source authorization	Critical
AR-02	AI agent has broad write access	Critical
AR-03	Model output executed without validation	High
AR-04	AI activity not centrally logged	High
AR-05	Public API lacks sufficient rate controls	Medium

Phase 28 — Document Positive Controls

Architecture reviews should not only identify weaknesses.

Record strong controls as well.

Examples:

• Dedicated workload identities

• Private networking

• Central secrets management

• RAG authorization

• Human approval

• Central logging

• Container scanning

This provides a more accurate assessment.

Phase 29 — Determine Architecture Decision

Possible decisions:

Approved

No material security architecture gaps identified.

Approved with Conditions

Deployment may proceed if specified controls are completed.

Remediation Required

Major design changes are required before production.

Risk Acceptance Required

Known risks require formal business acceptance.

Not Approved

Architecture presents unacceptable risk.

Architecture Decision Template

# AI Security Architecture Decision

## System

## Business Owner

## Review Date

## Architecture Version

## Overall Security Assessment

## Critical Architecture Findings

## Required Security Controls

## Conditions for Production

## Residual Risks

## Security Recommendation

## Risk Owner

## Final Decision

Phase 30 — Track Architecture Actions

Create:

Action	Owner	Priority	Target	Status
Implement RAG authorization	AI Team	Critical	TBD	Open
Restrict agent IAM role	Platform Team	Critical	TBD	Open
Enable centralized logging	SOC Team	High	TBD	In Progress

Do not close the architecture review until required security actions are addressed or formally accepted.

Evidence to Retain

Maintain:

• Architecture diagrams

• Data flow diagrams

• Threat models

• IAM design

• Network design

• Data classification

• Security requirements

• Meeting decisions

• Risk decisions

• Validation evidence

• Final approval

Recommended Review Package

AI-Security-Architecture-Review/
│
├── 01-Business-Requirements.md
├── 02-Architecture.md
├── 03-Data-Flows.md
├── 04-Asset-Inventory.md
├── 05-Trust-Boundaries.md
├── 06-Threat-Model.md
├── 07-Security-Requirements.md
├── 08-Architecture-Findings.md
├── 09-Action-Register.md
├── 10-Architecture-Decision.md
│
└── Evidence/
    ├── IAM/
    ├── Data/
    ├── RAG/
    ├── Agents/
    ├── APIs/
    ├── Cloud/
    ├── Network/
    └── Logging/

Master Architecture Review Checklist

Business

• Use case understood

• Owner identified

• Criticality defined

Architecture

• Architecture reviewed

• Components inventoried

• Data flows mapped

• Trust boundaries identified

Identity

• User authentication reviewed

• Service identities reviewed

• Agent identities reviewed

• Least privilege applied

Authorization

• Data access controlled

• RAG authorization enforced

• Agent actions authorized

• LLM not used as primary authorization control

Data

• Sensitive data identified

• Encryption reviewed

• Retention reviewed

• Third-party transfers reviewed

LLM

• Integration reviewed

• Output treated as untrusted

• High-risk actions validated

RAG

• Sources approved

• Ingestion controlled

• Retrieval authorized

• Vector store secured

Agents

• Tools inventoried

• Permissions restricted

• Human approval considered

• Actions logged

APIs

• Authentication defined

• Authorization defined

• Rate limiting considered

• Secrets protected

Cloud

• IAM reviewed

• Network segmentation reviewed

• Public exposure minimized

• Logging enabled

Containers / Kubernetes

• Images trusted

• Privileges minimized

• RBAC reviewed

• Secrets protected

Supply Chain

• Models trusted

• Dependencies reviewed

• Third parties assessed

Logging

• Security telemetry defined

• Central logging available

• Sensitive log data protected

Detection

• Abuse scenarios mapped

• Detection opportunities identified

• SOC ownership established

Response

• Containment options available

• Agent disable capability exists

• Credentials can be revoked

Resilience

• Dependencies identified

• Failure behavior defined

• Recovery considered

Governance

• Privacy reviewed

• Risk reviewed

• Human oversight defined

Decision

• Findings documented

• Security requirements created

• Owners assigned

• Production conditions documented

• Final decision recorded

Common Architecture Review Mistakes

Reviewing Only the LLM

The LLM is one component.

Architecture review must include:

Identity
+
Data
+
Application
+
API
+
RAG
+
Agent
+
Cloud
+
Network
+
Operations

Treating Prompt Instructions as Security Controls

Prompt instructions may influence model behavior.

They should not replace trusted controls such as authorization.

Ignoring Data Flows

If you do not know where information travels, you cannot reliably determine where it may leak.

Ignoring AI Agents

An AI system that can take actions introduces significantly different risk from a simple chatbot.

Ignoring Operations

Architecture must support:

• Logging

• Detection

• Investigation

• Containment

• Recovery

Reviewing Too Late

Architecture review provides the most value before major engineering decisions become difficult to change.

Architecture Review Mindset

For every component, ask:

Why Does It Exist?
        ↓
What Does It Access?
        ↓
Who Can Access It?
        ↓
What Trusts It?
        ↓
What Does It Trust?
        ↓
What Could Manipulate It?
        ↓
What Happens If It Is Compromised?
        ↓
What Prevents That?
        ↓
How Would We Detect It?
        ↓
How Would We Contain It?

This thought process is more important than memorizing a checklist.

Runbook Completion Criteria

The review is complete when:

• Business context is understood.

• Architecture is documented.

• Data flows are mapped.

• Trust boundaries are documented.

• Critical assets are identified.

• Identity is reviewed.

• Authorization is reviewed.

• Data security is reviewed.

• LLM integration is reviewed.

• RAG is reviewed.

• AI agents are reviewed.

• APIs are reviewed.

• Cloud and infrastructure are reviewed.

• Network security is reviewed.

• Supply-chain risks are reviewed.

• Logging is reviewed.

• Detection is reviewed.

• Incident response is reviewed.

• Resilience is reviewed.

• Threat scenarios are documented.

• Architecture gaps are identified.

• Security requirements are defined.

• Findings are prioritized.

• Owners are assigned.

• Architecture decision is documented.

Security Engineer Takeaway

The purpose of security architecture is not to make an AI system impossible to attack.

The purpose is to design the system so that:

Security Boundaries Are Clear

Access Is Restricted

Sensitive Data Is Protected

AI Capabilities Are Controlled

Failures Are Contained

Suspicious Activity Is Visible

Incidents Can Be Investigated

Risk Is Understood

The earlier these principles are incorporated into architecture, the stronger and easier the system becomes to secure.

Runbook Complete

You have completed:

Runbook 02 — Enterprise AI Security Architecture Review

You now have a structured methodology for reviewing an AI solution before production and translating security concerns into concrete architecture requirements.

This completes the practical assessment and architecture-review foundation for Module 01 — AI Security Foundations.

What’s Next?

➡️ Module 02 — LLM Security

You now understand the foundations required to assess AI systems, including:

• Enterprise AI architecture
• AI attack surfaces
• AI threat identification
• OWASP and MITRE ATLAS mapping
• AI security assessments
• Enterprise AI security architecture reviews

The next module focuses on one of the most important areas in modern AI Security Engineering:

Securing applications built with Large Language Models.

You will learn how LLM-enabled applications can be attacked, abused, misconfigured and manipulated, and how security engineers assess and defend these systems.

In the next module, you will explore:

• LLM security fundamentals
• Prompt injection
• Indirect prompt injection
• Jailbreaking and safety bypass
• Sensitive information disclosure
• Insecure output handling
• RAG security
• Vector database security
• AI agent and tool security
• Model and data poisoning
• Excessive agency
• Enterprise LLM security architecture

You will also complete practical labs where you will analyze and test LLM applications inside authorized environments.

The goal is to move from:

“I understand AI security risks.”

to:

“I can identify, assess and help secure real LLM-enabled applications.”

➡️ Next Module: 02 — LLM Security