Runbook 01 AI Security Assessment Checklist

Purpose

This runbook provides a repeatable process for performing an AI Security Assessment.

It is designed to help security engineers systematically review an AI-enabled system before deployment, during a security review, or as part of an ongoing assurance process.

The goal is to answer:

Is this AI system designed, configured and operated securely enough for its intended business use?

This runbook should help you move from an informal review to a structured enterprise assessment.

Runbook Objective

Use this runbook to:

• Understand the business use case.
• Understand the AI architecture.
• Identify critical assets.
• Review identity and access controls.
• Review AI data security.
• Assess LLM application security.
• Review RAG security.
• Review AI agent security.
• Review APIs and integrations.
• Review supporting infrastructure.
• Review software and AI supply-chain risk.
• Review logging and monitoring.
• Review governance and risk controls.
• Identify security gaps.
• Record evidence.
• Prioritize findings.
• Recommend remediation.

When to Use This Runbook

Use this runbook when:

• A new AI application is being introduced.
• An existing AI application is changing significantly.
• A new LLM provider is being integrated.
• RAG capabilities are being added.
• AI agents are being introduced.
• Sensitive enterprise data will be used.
• A cloud AI platform is being deployed.
• A security review is required before production.
• A risk assessment is requested.
• An incident reveals weaknesses in the existing design.
• An audit or governance review requires security evidence.

Typical Triggers

Examples include:

New AI Project
      ↓
Security Review Requested

Architecture Change
      ↓
AI Security Reassessment

New Data Source
      ↓
Data & RAG Security Review

AI Agent Enabled
      ↓
Permission & Tool Security Review

Security Incident
      ↓
Post-Incident AI Security Assessment

Roles Involved

An enterprise AI security assessment may involve:

• AI Security Engineer

• Cloud Security Engineer

• Application Security Engineer

• Security Architect

• DevSecOps Engineer

• AI / ML Engineer

• Software Developer

• Data Engineer

• Platform Engineer

• SOC / Incident Response

• Risk and Compliance

• Privacy

• Legal

• AI Governance

• Business Owner

The AI Security Engineer may coordinate the assessment, but many controls depend on other teams.

Required Inputs

Before starting, collect as much of the following as possible:

• Business requirements

• Architecture diagrams

• Data flow diagrams

• AI model information

• LLM provider details

• RAG design

• Vector database details

• AI agent design

• API documentation

• Identity architecture

• IAM roles and permissions

• Cloud architecture

• Container architecture

• Network diagrams

• Data classification

• Secrets management design

• Logging architecture

• Security controls

• Deployment pipeline details

• Third-party dependencies

• Risk assessments

• AI governance documentation

• Incident response procedures

If information is missing, record it as an assessment gap.

Assessment Workflow

Use the following sequence:

Understand Business Context
        ↓
Understand Architecture
        ↓
Identify Assets
        ↓
Identify Trust Boundaries
        ↓
Review Identity
        ↓
Review Data
        ↓
Review LLM Security
        ↓
Review RAG
        ↓
Review AI Agents
        ↓
Review APIs
        ↓
Review Infrastructure
        ↓
Review Supply Chain
        ↓
Review Logging & Monitoring
        ↓
Review Governance
        ↓
Identify Threats
        ↓
Validate Controls
        ↓
Document Findings
        ↓
Prioritize Risk
        ↓
Recommend Remediation
        ↓
Retest / Close

Phase 1 — Understand the Business Context

Before reviewing technology, understand why the AI system exists.

Record:

Business Use Case

What is the system designed to do?

Examples:

• Employee assistant

• Customer chatbot

• Security analyst assistant

• Code generation

• Document summarization

• Decision support

• Threat intelligence analysis

• Automated workflow execution

Business Owner

Who owns the system?

User Population

Who will use it?

Examples:

• Employees

• Administrators

• Developers

• Customers

• Partners

• Public users

Business Criticality

Classify the system:

• Low

• Medium

• High

• Mission Critical

Security Questions

Ask:

• What happens if the system becomes unavailable?

• What happens if it produces incorrect information?

• What happens if sensitive data is disclosed?

• What happens if an AI agent performs an unauthorized action?

• What regulatory requirements apply?

Business Context Checklist

• Business use case documented

• System owner identified

• User population identified

• Business criticality defined

• Sensitive operations identified

• Regulatory requirements identified

• Acceptable use defined

• Known business risks documented

Phase 2 — Understand the Architecture

Do not perform the assessment without understanding the architecture.

Identify components such as:

Users
  │
  ▼
Application
  │
  ▼
API
  │
  ▼
AI / LLM Layer
  │
  ├── Model
  ├── RAG
  ├── Vector Database
  ├── Enterprise Data
  ├── AI Agent
  └── External Tools

Supporting infrastructure may include:

Cloud
IAM
Containers
Kubernetes
Databases
Storage
Secrets
CI/CD
Logging
Monitoring
SIEM

Architecture Checklist

• Architecture diagram available

• Major components identified

• AI model identified

• LLM provider identified

• RAG components identified

• Vector database identified

• AI agents identified

• APIs identified

• External integrations identified

• Supporting cloud services identified

• Trust boundaries identified

• Data flows identified

• Internet-facing components identified

Phase 3 — Identify Critical Assets

Identify what needs protection.

Possible assets include:

• Models

• Prompts

• System instructions

• Enterprise data

• Embeddings

• Vector database

• API keys

• Secrets

• Service identities

• AI agent credentials

• Training data

• Fine-tuning data

• Logs

• User conversations

• Model outputs

• Cloud resources

• Source code

Asset Classification

Classify each asset.

Example:

Asset	Classification
Public model metadata	Public
Internal documentation	Internal
Security architecture	Confidential
Customer data	Confidential
API keys	Restricted
Credentials	Restricted

Asset Checklist

• Assets identified

• Data owner identified

• Classification assigned

• Confidentiality requirement understood

• Integrity requirement understood

• Availability requirement understood

• Retention requirements identified

• Regulatory requirements identified

Phase 4 — Review Identity & Access Management

Identity is a critical control layer.

Review:

Human Users

• How are users authenticated?

• Is MFA required?

• Are roles defined?

• Are users appropriately authorized?

Workload Identities

Review:

• Service accounts

• Managed identities

• Application identities

• API identities

AI Agent Identities

Ask:

• Does the agent have its own identity?

• What permissions does it have?

• Can it access sensitive systems?

• Can it execute actions?

IAM Checklist

• Strong authentication implemented

• MFA used where appropriate

• Least privilege applied

• Role-based access defined

• Service identities separated

• AI agent identities separated

• Excessive permissions reviewed

• Privileged access monitored

• Access lifecycle defined

• Dormant identities removed

• Authorization enforced outside the LLM

• Access decisions are logged

Critical Principle

The LLM should not be treated as an authorization engine.

Authorization should be enforced by trusted application and identity controls.

Phase 5 — Review Data Security

AI systems frequently access sensitive data.

Identify:

• What data enters the system?

• Where does it come from?

• Where is it stored?

• Where is it processed?

• Where is it sent?

• Who can access it?

Data Checklist

• Data sources identified

• Sensitive data classified

• Personal data identified

• Data access restricted

• Encryption in transit enabled

• Encryption at rest enabled

• Retention defined

• Data minimization considered

• Data deletion process defined

• Sensitive data excluded where unnecessary

• External provider data handling reviewed

• AI conversation storage reviewed

Questions to Ask

Does the model need access to this data?

Does the application need to retain this data?

Can the AI expose this data to another user?

Is data being sent to a third-party model provider?

Are users aware of data-handling expectations?

Phase 6 — Review LLM Security

Assess LLM-specific risks.

Review areas such as:

• Prompt injection

• Indirect prompt injection

• System prompt exposure

• Sensitive information disclosure

• Improper output handling

• Excessive agency

• Misinformation

• Resource abuse

• Unsafe model behavior

Use current AI/LLM security guidance when performing the review.

LLM Security Checklist

• Prompt injection risk assessed

• Indirect prompt injection considered

• System instructions protected where possible

• Sensitive output risk assessed

• Model output treated as untrusted

• Output validation implemented

• Downstream actions validated

• Resource limits implemented

• Rate limiting implemented

• Error handling reviewed

• High-risk actions require stronger validation

• Human approval used where appropriate

Important Principle

Model output is untrusted input to the next component.

If an LLM generates:

• SQL

• Shell commands

• Code

• URLs

• API parameters

• Business actions

those outputs should be validated before use.

Phase 7 — Review RAG Security

RAG introduces additional security boundaries.

Review:

Enterprise Documents
        ↓
Ingestion
        ↓
Chunking
        ↓
Embedding
        ↓
Vector Database
        ↓
Retrieval
        ↓
LLM Context

Security concerns may exist at every stage.

RAG Checklist

• Data sources are approved

• Document ownership defined

• Ingestion permissions restricted

• Malicious content risk assessed

• Source integrity protected

• Unauthorized document insertion prevented

• Vector database access restricted

• Retrieval authorization enforced

• User-level data access respected

• Sensitive documents appropriately segmented

• Retrieved content treated as untrusted

• Changes to knowledge sources logged

• Removal process defined

Key Question

Can a user retrieve information they would not normally be authorized to access?

If yes, the RAG design may be bypassing enterprise authorization controls.

Phase 8 — Review AI Agent Security

AI agents can increase risk because they can perform actions.

An agent might access:

Email
Cloud Storage
Databases
Ticketing Systems
Code Repositories
APIs
Administrative Systems

Review each tool and permission.

Agent Security Checklist

• Agent identity defined

• Agent permissions documented

• Least privilege applied

• Allowed tools restricted

• High-risk tools identified

• Input validation implemented

• Output / action validation implemented

• Sensitive actions require approval

• Tool calls logged

• Failed tool calls logged

• Agent actions auditable

• Credential access minimized

• Transaction limits defined

• Emergency disable mechanism available

High-Risk Actions

Examples include:

• Sending email

• Deleting data

• Creating accounts

• Changing permissions

• Executing code

• Modifying cloud resources

• Making financial transactions

• Accessing production systems

For high-risk actions, consider:

AI Recommendation
       ↓
Policy Validation
       ↓
Human Approval
       ↓
Action Execution

Phase 9 — Review API Security

Most AI systems rely heavily on APIs.

Review:

• Authentication

• Authorization

• Tokens

• Rate limiting

• Input validation

• Output validation

• Error handling

• TLS

• Logging

• Secrets

API Security Checklist

• Authentication required

• Authorization enforced

• TLS enabled

• Tokens protected

• API keys not exposed client-side

• Rate limits defined

• Input validation implemented

• Output handling reviewed

• Error messages sanitized

• APIs inventoried

• Deprecated APIs removed

• API activity logged

• Privileged API operations restricted

Phase 10 — Review Secrets Management

Identify:

• API keys

• Database passwords

• Cloud credentials

• Certificates

• Service tokens

• Model provider credentials

Secrets Checklist

• Secrets stored in approved secret management system

• Secrets not hardcoded

• Secrets excluded from source control

• Rotation process exists

• Access restricted

• Access logged

• Expired secrets removed

• Environment-specific credentials used

• Production secrets separated from development

• AI agents receive only required credentials

Phase 11 — Review Infrastructure Security

AI workloads still depend on traditional infrastructure security.

Review:

Cloud

• IAM

• Networks

• Storage

• Logging

• Encryption

• Security services

Containers

• Base images

• Vulnerabilities

• Runtime permissions

• Secrets

• Image provenance

Kubernetes

• RBAC

• Namespaces

• Network policies

• Workload identities

• Admission controls

• Secrets

Infrastructure Checklist

• Environment separated appropriately

• Network access restricted

• Public exposure reviewed

• Firewall rules reviewed

• Cloud IAM reviewed

• Storage access restricted

• Encryption enabled

• Containers scanned

• Images sourced from trusted registries

• Kubernetes RBAC reviewed

• Workloads use least privilege

• Security updates applied

• Infrastructure logging enabled

Phase 12 — Review AI Supply Chain

AI systems often depend on:

• Models

• Model repositories

• Libraries

• Open-source packages

• Containers

• Datasets

• Plugins

• External APIs

Each creates supply-chain risk.

Supply-Chain Checklist

• Model source verified

• Model provenance understood

• Dependencies inventoried

• Dependency vulnerabilities scanned

• Packages sourced from trusted repositories

• Container provenance verified

• Dataset source reviewed

• External AI provider reviewed

• Third-party risk assessment completed

• Updates controlled

• Integrity validation considered

• Software Bill of Materials available where appropriate

Phase 13 — Review Development & CI/CD Security

AI security should begin before production.

Review:

Developer
    ↓
Source Code
    ↓
CI/CD
    ↓
Security Testing
    ↓
Artifact
    ↓
Deployment

DevSecOps Checklist

• Source control protected

• Branch protections implemented

• Code review required

• Secrets scanning enabled

• Dependency scanning enabled

• Container scanning enabled

• Security tests integrated

• Deployment approvals defined

• Production deployment restricted

• Artifacts validated

• Environment separation implemented

• Audit logs retained

Phase 14 — Review Logging & Monitoring

Ask:

If this AI system were attacked today, would we know?

Review telemetry from:

• Authentication

• Application

• APIs

• LLM interactions

• RAG retrieval

• Vector database

• AI agents

• Cloud

• Containers

• Infrastructure

Logging Checklist

• Authentication events logged

• Authorization failures logged

• API requests logged

• Administrative actions logged

• Agent tool usage logged

• RAG ingestion events logged

• Knowledge-source changes logged

• Cloud activity logged

• Security events centralized

• Time synchronization implemented

• Log retention defined

• Sensitive data protected in logs

Avoid Logging Sensitive Data Blindly

Prompts and model outputs may contain:

• Personal information

• Credentials

• Customer data

• Business secrets

Logging should balance:

Security Visibility

with

Privacy and Data Protection

Phase 15 — Review Detection Capabilities

Identify what suspicious behavior should trigger detection.

Examples:

• Repeated prompt manipulation attempts

• Unusual data retrieval

• Abnormal token consumption

• Unexpected AI agent actions

• Unauthorized knowledge-source changes

• Privilege escalation

• Large data access

• New API credentials

• Model configuration changes

Detection Checklist

• Important abuse scenarios identified

• Detection requirements documented

• Relevant telemetry available

• Alerts configured

• Alert ownership defined

• False-positive handling defined

• Escalation process documented

• SIEM integration considered

• Threat hunting opportunities identified

Phase 16 — Review Incident Response Readiness

Ask:

What happens if this AI system is compromised?

Possible response actions may include:

• Disable users

• Disable AI agents

• Revoke tokens

• Rotate credentials

• Remove malicious documents

• Disable models

• Restrict external access

• Isolate workloads

• Preserve logs

• Notify stakeholders

Incident Response Checklist

• AI incident scenarios defined

• Incident owner identified

• Escalation path documented

• Evidence sources identified

• Credential revocation process tested

• Agent disable mechanism available

• Malicious knowledge removal process defined

• Data breach process integrated

• Communications process defined

• Lessons learned process defined

Phase 17 — Review Governance & Risk

AI systems may introduce risk beyond technical vulnerabilities.

Review:

• Responsible AI

• Privacy

• Risk management

• Regulatory requirements

• Model governance

• Data governance

• Third-party risk

• Acceptable use

Governance Checklist

• AI owner assigned

• Risk owner assigned

• AI use case approved

• Data use approved

• Privacy assessment completed where required

• AI risk assessment completed

• Third-party AI providers reviewed

• Acceptable use defined

• Human oversight defined

• Security responsibilities documented

• Exception process defined

• Periodic review scheduled

Phase 18 — Map Threats

Use your architecture and assessment findings to identify realistic threats.

Consider:

• Prompt injection

• Indirect prompt injection

• Unauthorized data access

• RAG poisoning

• Model manipulation

• Supply-chain compromise

• Agent misuse

• Credential compromise

• API abuse

• Resource exhaustion

• Data leakage

• Infrastructure compromise

Use relevant frameworks to support your analysis.

Examples may include:

• OWASP AI / LLM security guidance

• MITRE ATLAS

• NIST AI risk guidance

• Existing enterprise security standards

Threat Mapping Checklist

• Threat scenarios documented

• Relevant framework mappings validated

• Attack paths documented

• Affected assets identified

• Threat actors identified

• Existing controls documented

• Control gaps identified

• Detection opportunities identified

• Response requirements identified

Phase 19 — Validate Security Controls

Do not assume a control exists because documentation says it exists.

Where authorized, validate.

Examples:

Documentation Says:
"Only HR users can retrieve HR documents."

Validation:
Test authorization using a non-HR account.

Documentation Says:
"Agent has read-only permissions."

Validation:
Inspect actual IAM permissions.

Documentation Says:
"Secrets are secured."

Validation:
Verify no secrets exist in code or configuration files.

Security assurance requires evidence.

Phase 20 — Document Evidence

For every important observation, collect appropriate evidence.

Possible evidence:

• Architecture screenshots

• IAM configurations

• API configurations

• Policy documents

• Cloud configurations

• Logs

• Test output

• Security tool output

• Source configuration

• Threat models

Evidence Template

## Evidence ID

EV-001

## Control

AI Agent Least Privilege

## Evidence

IAM role configuration reviewed.

## Observation

Agent has permission to access resources beyond its required function.

## Result

Control Not Effective

Phase 21 — Create Findings

A professional finding should include:

Finding
   ↓
Affected Asset
   ↓
Evidence
   ↓
Risk
   ↓
Business Impact
   ↓
Recommendation

Finding Template

# Finding

## Title

## Severity

## Affected Asset

## Description

## Evidence

## Attack Scenario

## Security Impact

## Business Impact

## Recommendation

## Validation / Retest

Phase 22 — Prioritize Findings

Use an agreed risk methodology.

A simple model can consider:

Likelihood

• Low

• Medium

• High

Impact

• Low

• Medium

• High

• Critical

Consider:

• Data sensitivity

• Exploitability

• User exposure

• Privileges

• Business criticality

• Existing controls

• Detection capability

Do not assign severity based on fear.

Assign severity based on evidence and realistic impact.

Example Risk Register

ID	Finding	Likelihood	Impact	Priority
F01	Excessive AI agent permissions	High	Critical	Critical
F02	RAG authorization weakness	Medium	Critical	Critical
F03	Missing API rate limiting	High	Medium	High
F04	Insufficient AI activity logging	Medium	High	High

Phase 23 — Recommend Remediation

Recommendations should be:

• Actionable

• Specific

• Technically realistic

• Prioritized

• Proportionate to risk

Avoid vague recommendations such as:

Improve security.

Instead:

Restrict the AI agent service identity to read-only access to the approved document repository and require human approval for all write operations.

That gives the engineering team something they can implement.

Phase 24 — Produce the Assessment Summary

Create a concise summary for stakeholders.

Suggested structure:

# AI Security Assessment Summary

## System

## Business Use Case

## Assessment Scope

## Overall Risk

## Critical Findings

## High-Risk Findings

## Positive Security Controls

## Key Recommendations

## Residual Risk

## Assessment Decision

Possible Assessment Decisions

Depending on organizational process:

• Approved

• Approved with Conditions

• Remediation Required

• Risk Acceptance Required

• Not Approved for Production

The AI Security Engineer may provide the security recommendation, while the formal risk decision may belong to the appropriate business or risk owner.

Phase 25 — Remediation Tracking

Findings should not disappear after the report is delivered.

Track:

Finding	Owner	Priority	Target Date	Status
F01	Platform Team	Critical	TBD	Open
F02	AI Engineering	High	TBD	In Progress

Possible statuses:

• Open

• Accepted

• In Progress

• Ready for Retest

• Closed

• Risk Accepted

Phase 26 — Retest

After remediation:

1. Review the proposed fix.

2. Repeat the original validation.

3. Confirm the weakness is resolved.

4. Check for unintended impact.

5. Update evidence.

6. Close or reopen the finding.

Do not close a finding based only on:

“The development team said it is fixed.”

Validate where possible.

Assessment Output Structure

A completed assessment could look like:

AI-Security-Assessment/
│
├── 01-Scope.md
├── 02-Business-Context.md
├── 03-Architecture.md
├── 04-Asset-Inventory.md
├── 05-Data-Flows.md
├── 06-Threat-Model.md
├── 07-Control-Assessment.md
├── 08-Findings.md
├── 09-Risk-Register.md
├── 10-Recommendations.md
├── 11-Executive-Summary.md
│
└── Evidence/
    ├── Identity/
    ├── Data/
    ├── LLM/
    ├── RAG/
    ├── Agents/
    ├── APIs/
    ├── Cloud/
    ├── Logging/
    └── Governance/

Master AI Security Assessment Checklist

Business

• Business use case understood

• Business owner identified

• Criticality defined

• Users identified

Architecture

• Architecture reviewed

• Data flows mapped

• Trust boundaries identified

• External integrations identified

Identity

• Authentication reviewed

• Authorization reviewed

• Least privilege validated

• Agent permissions reviewed

Data

• Data classified

• Sensitive data identified

• Data access restricted

• Encryption reviewed

• Retention reviewed

LLM

• Prompt injection considered

• Sensitive disclosure considered

• Output handling reviewed

• Resource controls reviewed

RAG

• Data sources approved

• Ingestion secured

• Retrieval authorization reviewed

• Vector database secured

• Poisoning risks assessed

Agents

• Agent tools inventoried

• Permissions reviewed

• High-risk actions restricted

• Human approval considered

• Agent activity logged

APIs

• Authentication reviewed

• Authorization reviewed

• Rate limiting reviewed

• API secrets protected

• Logging enabled

Infrastructure

• Cloud controls reviewed

• Network exposure reviewed

• Containers reviewed

• Kubernetes reviewed where applicable

• Security updates reviewed

Supply Chain

• Models reviewed

• Dependencies reviewed

• Third parties reviewed

• Package provenance considered

Logging

• Required telemetry identified

• Logs centralized

• Sensitive data protected

• Retention defined

Detection

• Abuse scenarios identified

• Detection opportunities defined

• Alerts mapped

• SOC ownership defined

Incident Response

• AI incident procedures exist

• Evidence sources identified

• Containment actions defined

• Escalation path defined

Governance

• AI risk review completed

• Privacy considered

• Third-party risk reviewed

• Acceptable use defined

• Human oversight defined

Reporting

• Findings documented

• Evidence retained

• Risk prioritized

• Remediation assigned

• Retest planned

Decision Points

During the assessment, escalate when:

Critical Data Exposure

If the AI system may expose highly sensitive or regulated information.

Excessive Agent Capability

If an AI agent can execute high-risk actions without adequate controls.

Missing Authorization

If access control depends primarily on model instructions.

Uncontrolled Production Access

If AI components have broad production permissions.

Unknown Data Handling

If the organization cannot determine where sensitive data is processed or retained.

Supply-Chain Concern

If model or dependency provenance cannot be established.

Missing Logging

If high-risk activity cannot be investigated.

In these situations, production deployment may require remediation or formal risk acceptance.

Common Assessment Mistakes

Reviewing Only the Model

AI security includes:

Application
+
Identity
+
Data
+
Infrastructure
+
Model
+
RAG
+
Agents
+
APIs
+
Operations

Treating Prompt Filtering as the Main Defense

Prompt controls are only one layer.

Critical security boundaries should rely on trusted security controls.

Ignoring Agent Permissions

Agent permissions can turn an AI weakness into an enterprise-impacting incident.

Ignoring RAG Authorization

Retrieval systems must respect the user’s access rights.

Ignoring Traditional Security

AI does not replace:

• IAM

• Cloud security

• Application security

• Network security

• Data protection

• Secure development

Producing Findings Without Evidence

Every important finding should be supported by defensible evidence.

Runbook Completion Criteria

The runbook is complete when:

• Scope is defined

• Architecture is understood

• Assets are identified

• Data is classified

• Identity controls are reviewed

• LLM security is reviewed

• RAG security is reviewed

• Agent security is reviewed

• APIs are reviewed

• Infrastructure is reviewed

• Supply chain is reviewed

• Logging is reviewed

• Detection capability is reviewed

• Incident response readiness is reviewed

• Governance is reviewed

• Threats are mapped

• Controls are validated

• Evidence is captured

• Findings are prioritized

• Recommendations are provided

• Remediation owners are identified

• Retest requirements are defined

Security Engineer Takeaway

A professional AI Security Assessment is not:

Run a tool and produce a vulnerability report.

It is:

Understand the Business
        +
Understand the Architecture
        +
Understand the Data
        +
Understand the Threats
        +
Validate Security Controls
        +
Evaluate Business Risk
        +
Provide Actionable Guidance

The tools and frameworks help you.

They do not replace engineering judgment.

Runbook Complete

You have completed:

Runbook 01 — AI Security Assessment Checklist

You now have a reusable methodology for assessing an enterprise AI system from business context through technical controls, operations, governance and remediation.

This runbook can be reused throughout later modules as the AI systems become more complex.

What’s Next?

➡️ Runbook 02 — Enterprise AI Security Architecture Review

The AI Security Assessment Checklist gives you the broad assessment process.

The next runbook focuses specifically on one of the most important responsibilities of an AI Security Engineer:

Reviewing an AI architecture before it reaches production.

You will learn how to systematically review:

• Business requirements

• Architecture components

• Trust boundaries

• Identity

• Data flows

• LLM integration

• RAG

• AI agents

• APIs

• Cloud infrastructure

• Security controls

• Logging

• Resilience

• Threat scenarios

• Architecture risks

• Security design recommendations

The goal is to move from:

“Can I assess an AI system?”

to:

“Can I review and challenge an enterprise AI security architecture?”

➡️ Next: Runbook 02 — Enterprise AI Security Architecture Review