Runbook 03 — Enterprise LLM Security Review

An enterprise LLM security review is broader than penetration testing.

A penetration test may ask:

Can this AI application be exploited?

An enterprise security review asks:

Should this AI system be approved for production?

That requires understanding not only vulnerabilities, but also:

Business Purpose
+
Architecture
+
Data
+
Identity
+
Authorization
+
RAG
+
AI Agents
+
Models
+
Supply Chain
+
Monitoring
+
Incident Response
+
Governance

The goal is to determine whether the complete AI system has appropriate controls for the risk it introduces.

This runbook provides a repeatable methodology for performing that review.

Runbook Information

Item	Details
Runbook	Runbook 03 — Enterprise LLM Security Review
Learning Path	AI Security Engineer
Module	02 — LLM Security
Type	Enterprise Architecture & Production Readiness Runbook
Primary Use	Enterprise AI Security Review
Audience	AI Security, Security Architecture, AppSec, Cloud Security, GRC, Engineering
Output	Security Review + Risk Register + Production Recommendation

Purpose

Use this runbook to determine whether an enterprise AI application has sufficient security controls to move into:

Pilot
Production
Expanded Enterprise Use

It can be used for:

• Enterprise copilots

• Internal AI assistants

• RAG applications

• AI agents

• Security assistants

• Coding assistants

• Customer-facing AI

• Cloud AI solutions

• Fine-tuned enterprise models

When to Use This Runbook

Use this runbook:

• Before production deployment

• Before connecting sensitive enterprise data

• Before giving an AI agent write permissions

• Before expanding a pilot to more users

• When adding new RAG sources

• When changing foundation models

• When adding external AI providers

• After significant security incidents

• During periodic enterprise AI security reviews

Core Review Question

The final review should answer:

Is the AI system secure enough
for its intended business use
and risk level?

The answer may be:

Approved

Approved With Conditions

Pilot Only

Not Ready for Production

Enterprise Review Principles

Principle 1 — Business Purpose Drives Security

Every capability should trace back to a legitimate requirement.

Ask:

Why does this AI need this data?

Why does it need this tool?

Why does it need write access?

Why does it need autonomy?

If there is no business requirement, remove the capability.

Principle 2 — Assume the Model Can Fail

The architecture should remain secure even if the LLM:

• Misunderstands a request

• Hallucinates

• Is prompt injected

• Is influenced by malicious content

Critical controls must remain outside the model.

Principle 3 — Protect Data Before Model Context

Use:

Identity
 ↓
Authorization
 ↓
Allowed Data
 ↓
LLM

not:

All Data
 ↓
LLM
 ↓
"Do not reveal restricted information"

Principle 4 — Minimize Agent Authority

AI agents should receive:

Minimum Tools
+
Minimum Permissions
+
Minimum Autonomy

Principle 5 — Enterprise AI Requires Ownership

Every AI system should have defined owners for:

• Business

• Application

• Security

• Data

• Model

• Operations

Enterprise Review Workflow

Use this sequence:

1. Review Initiation
      ↓
2. Business Use Case
      ↓
3. Ownership
      ↓
4. AI System Inventory
      ↓
5. Architecture
      ↓
6. Data Classification
      ↓
7. Identity & Authorization
      ↓
8. Model Review
      ↓
9. RAG Review
      ↓
10. AI Agent Review
      ↓
11. Supply Chain
      ↓
12. Logging & Monitoring
      ↓
13. Incident Response
      ↓
14. Governance & Risk
      ↓
15. Production Readiness
      ↓
16. Sign-Off

Phase 1 — Review Initiation

Document:

Application Name:

Business Owner:

Technical Owner:

Security Owner:

Environment:

Review Date:

Target Deployment Date:

Requested Decision:

Possible decisions:

Pilot Approval

Production Approval

Expansion Approval

Periodic Revalidation

Phase 2 — Business Use Case Review

Document the intended purpose.

Example:

Application:
Enterprise Security Copilot

Purpose:
Help SOC analysts search runbooks,
analyze security alerts and draft
incident-response recommendations.

Ask:

Who uses it?

What business problem does it solve?

What decisions does it influence?

Can it perform actions?

What would happen if it is wrong?

Business Impact Classification

Classify the application.

Low Impact

Example:

Public FAQ Assistant

No sensitive data or enterprise actions.

Moderate Impact

Example:

Internal Knowledge Assistant

Processes internal enterprise data.

High Impact

Example:

Security Operations AI Assistant

Processes sensitive data or influences important decisions.

Critical Impact

Example:

Autonomous Production Agent

Can modify critical systems.

Higher impact should require stronger controls.

Phase 3 — Define Ownership

Every enterprise AI application should have identifiable owners.

Create:

Area	Owner
Business
Application
Model
Data
Security
Operations
Incident Response

Ownership Questions

Ask:

Who approves new AI capabilities?

Who approves new data sources?

Who approves model changes?

Who owns incidents?

Who can disable the system?

If ownership is unclear, production risk increases.

Phase 4 — AI System Inventory

Inventory the complete solution.

Include:

AI Application

Foundation Model

Embedding Model

RAG

Vector Database

Memory

AI Agents

Tools

External APIs

Datasets

Model Registry

Logging

Component Inventory

Component	Version	Owner	Source	Environment
AI Application
Foundation Model
Embedding Model
Vector DB
Agent Framework

This inventory becomes the basis for future reviews.

Phase 5 — Architecture Review

Create an architecture diagram.

Example:

                         Enterprise User
                               │
                               ▼
                       Identity Provider
                               │
                               ▼
                       AI Application
                               │
                               ▼
                              LLM
                  ┌────────────┼────────────┐
                  │            │            │
                  ▼            ▼            ▼
                 RAG         Memory       AI Agent
                  │                           │
                  ▼                           ▼
           Vector Database                Tool Layer
                  │                           │
                  ▼                           ▼
          Enterprise Knowledge         Enterprise Systems

Include:

• Trust boundaries

• External providers

• Network boundaries

• Security controls

• Logging

Architecture Review Questions

Ask:

Where does user input enter?

Where is identity verified?

Where is authorization enforced?

What data reaches the LLM?

Where is sensitive information stored?

What systems can the AI agent access?

Which components are externally hosted?

Phase 6 — Asset Identification

Document critical assets.

Examples:

Customer Data

Employee Data

Security Incidents

Source Code

Cloud Infrastructure

Agent Credentials

Models

Vector Database

Logs

Asset Register

Asset	Classification	Owner	Impact
Security Runbooks	Confidential	Security	Medium
Incident Data	Restricted	SOC	High
Agent Credentials	Restricted	Platform	Critical
Production Cloud	Critical	Cloud	Critical

Phase 7 — Data Classification Review

Determine what data the AI processes.

Classify:

Public

Internal

Confidential

Restricted

Document:

Source

Classification

Purpose

Users

External Processing

Retention

Data Review Questions

Ask:

Does the model actually need this data?

Can less data be used?

Can sensitive fields be removed?

Does data leave the enterprise?

How long is it retained?

Phase 8 — Data Minimization

Identify excessive data exposure.

Weak:

AI Needs Department
      ↓
Receives Full Employee Record

Better:

AI Needs Department
      ↓
Receives Department Only

Data minimization reduces both privacy and security risk.

Phase 9 — Sensitive Data Controls

Verify:

• Secrets are excluded from prompts

• Credentials are excluded from RAG

• Logs are protected

• Sensitive context is minimized

• Retention is defined

• Data is encrypted appropriately

Phase 10 — Identity Review

Document all identities.

Include:

Human Users

Service Accounts

Agent Identities

Ingestion Identities

Retrieval Identities

Deployment Identities

Identity Matrix

Identity	Purpose	Permission Level
User	Access AI application	Role Based
Retrieval Service	Search vector DB	Read
Ingestion Service	Update vector DB	Write
Agent	Tool access	Restricted
Admin	Management	Privileged

Phase 11 — Authentication Review

Verify:

SSO

MFA

Session Management

API Authentication

Service Identity Authentication

High-impact AI systems should not depend on weak or shared credentials.

Phase 12 — Authorization Review

Assess authorization for:

Application

RAG

Data

Tools

Agents

Tenants

Resources

The security rule is:

Natural-language instructions must never create authorization.

Authorization Decision

Expected:

Trusted Identity
      +
Policy
      ↓
Allow / Deny

not:

LLM Believes User Is Admin
      ↓
Allow

Phase 13 — User-to-Agent Privilege Review

A common concern is:

Low-Privilege User
      ↓
Powerful AI Agent
      ↓
High-Privilege Action

Review whether the agent allows users to exceed their normal authorization.

Key Question

Ask:

Can a user do something through the AI that they could not do directly?

If yes, determine whether this is:

Intentional Delegation

or:

Privilege Escalation

Phase 14 — Model Review

Document:

Model Name

Version

Provider

Hosting

Approval Status

Purpose

Determine whether the model is appropriate for the use case.

Model Review Questions

Ask:

Where did the model come from?

Is it approved?

How is the version controlled?

Can the provider change it?

Can the organization roll back?

Phase 15 — Model Provenance

Verify:

Source

Version

Publisher

Approval

Integrity

for production models.

Unknown model provenance is a supply-chain risk.

Phase 16 — Hosted Model Review

If using an external provider, assess:

What data is sent?

Where is it processed?

Is it retained?

Is it used for training?

What contractual controls exist?

What happens during provider outage?

Phase 17 — Self-Hosted Model Review

Review:

Model Storage

Runtime Security

GPU Infrastructure

IAM

Network Controls

Patching

Monitoring

Self-hosting moves more security responsibility to the organization.

Phase 18 — Prompt and System Instruction Review

Review system instructions for:

Secrets

Credentials

Sensitive Configuration

Unnecessary Internal Details

Prompts may guide behavior.

They should not become:

Access Control

Secret Management

Tool Authorization

Phase 19 — Prompt Injection Readiness

Review whether the system assumes model safeguards will always work.

Ask:

What happens if Prompt Injection succeeds?

Expected answer:

Sensitive Data Still Protected

Tools Still Authorized

Agent Still Least Privileged

Phase 20 — RAG Review

If RAG is present, assess:

Knowledge Sources

Ingestion

Provenance

Classification

Permissions

Vector Database

Retrieval Authorization

Tenant Isolation

Deletion

RAG Production Requirement

A production RAG system should preserve:

Source Security
      ↓
AI Security

rather than weakening it.

Phase 21 — RAG Source Approval

Document approved sources.

Source	Owner	Classification	Approved
Corporate Policies	IT	Internal	Yes
HR Repository	HR	Confidential	Yes
Security Runbooks	Security	Confidential	Yes
User Uploads	User	Variable	Controlled
Internet	External	Untrusted	Controlled

Phase 22 — RAG Authorization

Verify:

Authenticated User
      ↓
Trusted Groups / Tenant
      ↓
Authorized Retrieval

Unauthorized documents should not enter model context.

Phase 23 — Tenant Isolation

If multi-tenant:

Tenant A
      ↓
Tenant A Data Only

Validate tenant identity comes from authentication.

Never trust:

Prompt-Supplied Tenant ID

Phase 24 — RAG Poisoning Controls

Review:

Who can add content?

Who can modify content?

How is provenance maintained?

Can untrusted content enter production?

How are changes monitored?

Phase 25 — AI Agent Review

If the application has agent capabilities, inventory every tool.

Example:

Tool	Business Required	Risk	Approval
Search Runbook	Yes	Low	No
Read Alert	Yes	Medium	No
Disable User	Maybe	High	Yes
Delete Resource	No	Critical	N/A

Phase 26 — Excessive Agency Review

Assess:

Functionality

Permissions

Autonomy

Ask:

Does the agent have tools it does not need?

Does it use permissions broader than required?

Can it perform high-impact actions without approval?

Phase 27 — Agent Identity Review

Document:

Agent Identity

Credential Type

Permissions

Resource Scope

Environment Scope

Revocation Process

Avoid:

Shared Administrator Credential

Phase 28 — Read vs Write Separation

Prefer:

AI Investigation Agent
      ↓
Read-Only
      ↓
Recommendation

and:

Response Workflow
      ↓
Approval
      ↓
Restricted Write

where possible.

Phase 29 — Tool Authorization

Every sensitive tool request should pass through:

LLM
 ↓
Proposed Action
 ↓
Validation
 ↓
Authorization
 ↓
Policy
 ↓
Approval
 ↓
Execution

The LLM should not authorize itself.

Phase 30 — Human Approval

Define which actions require approval.

Example:

Action	Approval
Search Logs	No
Read Alert	No
Create Draft	No
Disable User	Yes
Change Firewall	Yes
Delete Resource	Strong Change Approval

Phase 31 — Tool Parameter Security

Review whether approved tools can target unauthorized resources.

Example:

query_logs(account_id)

Ensure:

Authorized Account

is validated outside the model.

Phase 32 — Tool Chaining

Review capabilities created by combinations.

Example:

Read Sensitive Data
      +
External Email
      =
Potential Data Exfiltration

Document dangerous combinations.

Phase 33 — AI Memory Review

If memory is enabled, assess:

Data Stored

Purpose

Retention

User Isolation

Tenant Isolation

Deletion

Security Impact

Memory should never become an authorization store.

Phase 34 — Insecure Output Handling

Identify where model output enters:

SQL

Shell

HTML

Code

API

Cloud Tools

Verify validation occurs before execution.

Phase 35 — Supply Chain Review

Inventory:

Foundation Models

Embedding Models

Packages

Frameworks

Containers

Datasets

Registries

External APIs

Supply Chain Questions

Ask:

Do we know where every critical component came from?

Is every production version known?

Are vulnerabilities monitored?

Can production artifacts be replaced without approval?

Phase 36 — Model Registry Review

Assess:

Who can upload?

Who can promote?

Who can delete?

Are versions immutable?

Are changes logged?

Phase 37 — Dataset Governance

Review:

Training Data

Fine-Tuning Data

Evaluation Data

RAG Data

Document:

Owner

Source

Version

Classification

Approval

Phase 38 — Poisoning Readiness

Assess whether attackers or compromised users can modify:

Dataset

RAG Source

Vector Index

Model Artifact

Write access is a major integrity risk.

Phase 39 — Logging Review

Review:

Identity Logs

Application Logs

Model Logs

RAG Logs

Vector Logs

Agent Logs

Cloud Logs

Logging Principle

Log enough to investigate.

Do not create a second uncontrolled copy of sensitive AI data.

Phase 40 — Privacy-Aware Logging

Determine whether complete prompts and responses are required.

Prefer, where appropriate:

Request ID

User

Model Version

Risk Result

Retrieved Document IDs

Tool Calls

Authorization Decisions

with sensitive content minimized.

Phase 41 — Correlation

Verify one AI interaction can be traced:

User
 ↓
Request
 ↓
RAG
 ↓
Agent
 ↓
Tool
 ↓
Enterprise Action

using a correlation ID.

Phase 42 — Monitoring and Detection

Review detections for:

Repeated Prompt Abuse

Restricted Data Retrieval

Cross-Tenant Access

Unexpected Agent Tools

Model Replacement

RAG Source Change

Bulk Vector Export

Agent Write Activity

Phase 43 — SIEM Integration

Determine whether AI security events reach the organization’s normal SOC workflow.

Avoid creating an isolated AI monitoring environment that the SOC never sees.

Phase 44 — Incident Response Review

Verify the organization has procedures for:

Prompt Injection Incident

Sensitive Data Exposure

RAG Poisoning

Agent Misuse

Model Compromise

Dataset Poisoning

Phase 45 — Emergency Containment

Verify teams can:

Disable AI Application

Disable Agent

Revoke Agent Identity

Disable Tools

Block External Model Access

Remove RAG Source

Phase 46 — Recovery Capabilities

Verify:

Model Rollback

Dataset Restore

RAG Index Rebuild

Credential Rotation

Cache Invalidation

Phase 47 — Security Testing Evidence

Review whether technical assessment has been completed.

Evidence may include:

Prompt Injection Testing

Sensitive Data Testing

RAG Authorization Testing

Tenant Isolation Testing

Agent Permission Testing

Supply-Chain Validation

If high-risk functionality has never been tested, production approval should reflect that uncertainty.

Phase 48 — Governance Review

Determine whether the system has defined policies for:

Approved Use

Prohibited Use

Sensitive Data

External AI Providers

Agent Autonomy

Model Changes

Data Retention

Incident Reporting

Phase 49 — Risk Ownership

Every unresolved risk should have:

Risk Owner

Severity

Remediation

Due Date

Acceptance Decision

Avoid:

Known Risk
Owner: Unknown

Risk Register

ID	Risk	Severity	Owner	Decision
AI-R01	Agent Excessive Privilege	Critical	Platform	Remediate
AI-R02	Missing RAG Authorization	High	App Team	Remediate
AI-R03	Sensitive Prompt Logging	Medium	Operations	Accept / Remediate

Phase 50 — Security Control Matrix

Use a summary matrix.

Area	Control	Status
Identity	SSO + MFA	Pass
Authorization	RAG Document ACL	Fail
Agent	Least Privilege	Fail
RAG	Controlled Ingestion	Pass
Logging	Correlation IDs	Partial
IR	Agent Kill Switch	Pass

Possible statuses:

Pass

Partial

Fail

Not Applicable

Not Tested

Phase 51 — Production Readiness Criteria

Before approval, verify critical controls.

Identity

• Authentication is reliable.

• Privileged access is controlled.

Authorization

• Sensitive data access is deterministic.

• Tenant isolation is enforced.

RAG

• Source permissions are preserved.

• Untrusted ingestion is controlled.

Agents

• Least privilege is implemented.

• High-risk actions are controlled.

Models

• Production models are approved and traceable.

Supply Chain

• Critical dependencies are inventoried.

Monitoring

• Important security actions are visible.

Incident Response

• High-risk AI functionality can be contained.

Phase 52 — Production Decision Model

Use one of four outcomes.

Decision 1 — Approved

Use when:

No unresolved Critical risks

High risks appropriately remediated

Core security boundaries validated

Monitoring and response operational

Decision 2 — Approved With Conditions

Use when:

Remaining risks are understood

Temporary controls exist

Risk owners assigned

Clear remediation deadlines exist

Decision 3 — Pilot Only

Use when:

Architecture requires additional validation

Access scope is limited

Sensitive or write capabilities remain disabled

Decision 4 — Not Ready for Production

Use when:

Critical security boundaries fail

Examples:

Missing RAG Authorization

Cross-Tenant Data Exposure

Uncontrolled Privileged Agent

Unknown Production Model Provenance

Phase 53 — Example Production Decision

Decision:
Not Ready for Production

Critical Concern:
AI agent uses administrator privileges.

High Concern:
RAG does not enforce document-level authorization.

Business Impact:
Prompt Injection or unauthorized retrieval could
result in privileged enterprise action or sensitive
information disclosure.

Required Before Production:
1. Implement RAG authorization.
2. Replace agent administrator permissions.
3. Add deterministic tool authorization.
4. Complete retesting.

Phase 54 — Conditional Approval Example

Decision:
Approved for Limited Pilot

Conditions:

Maximum 25 internal users.

No production write tools.

No customer data.

RAG restricted to approved internal documentation.

Security monitoring enabled.

Reassessment required before production expansion.

This is often more realistic than binary approval.

Phase 55 — Executive Summary

The final review should include a concise executive summary.

Sample Executive Summary

The Enterprise Security Copilot was reviewed across
business use case, architecture, sensitive data, identity,
RAG, AI agents, supply chain, monitoring and incident response.

The platform demonstrates appropriate foundational controls
including enterprise authentication, controlled knowledge
sources and centralized audit logging.

Two material security gaps remain. RAG retrieval does not
consistently preserve document-level authorization, and the
AI agent currently operates with permissions broader than
required for its approved investigation use case.

These weaknesses create attack paths where model manipulation
or unauthorized queries could result in sensitive information
exposure or privileged enterprise actions.

Production approval should remain conditional on remediation
and successful security retesting of these controls.

Phase 56 — Detailed Finding Template

Use:

Finding:

Severity:

Affected Component:

Business Requirement:

Expected Security Control:

Observed State:

Attack Path:

Business Impact:

Root Cause:

Recommendation:

Owner:

Target Date:

Retest Required:
Yes / No

Example Finding — Excessive Agent Privilege

Finding:
AI Security Agent Uses Excessive Cloud Permissions

Severity:
Critical

Business Requirement:
Read security alerts and recommend remediation.

Observed State:
Agent uses a cloud administrator identity.

Attack Path:
Prompt Injection
→ AI Agent
→ Privileged Tool
→ Production Cloud

Potential Impact:
Unauthorized infrastructure changes.

Recommendation:
Replace the administrator role with a dedicated
read-only identity and route all state-changing
actions through separately authorized workflows.

Retest Required:
Yes

Example Finding — RAG Authorization

Finding:
RAG Does Not Preserve Document-Level Authorization

Severity:
High

Observed State:
Standard employees can retrieve synthetic
HR-restricted information.

Root Cause:
Vector retrieval is based on semantic relevance
without trusted user authorization filtering.

Recommendation:
Preserve source ACL metadata and enforce identity-aware
authorization before content reaches the LLM.

Retest Required:
Yes

Example Finding — Logging

Finding:
Sensitive AI Prompts Are Retained in Debug Logs

Severity:
Medium

Observed State:
Complete prompts containing synthetic restricted
values are retained in application logs.

Recommendation:
Implement privacy-aware logging, redaction,
restricted access and appropriate retention.

Phase 57 — Positive Control Documentation

Document controls that work.

Example:

Control:
Independent Tool Authorization

Test:
Prompt Injection caused the model to request
a restricted test action.

Result:
Authorization service denied the request.

Assessment:
Pass

Positive controls provide confidence that the architecture has effective defense in depth.

Phase 58 — Remediation Roadmap

Group work into phases.

Immediate — Critical

Remove Agent Admin Privileges

Fix Cross-Tenant Exposure

Implement Sensitive Data Authorization

Short Term — High

Control RAG Ingestion

Protect Model Registry

Implement Approval Workflows

Medium Term

Improve Logging

Improve Detection

Improve Model and Dataset Lineage

Continuous

Security Regression Testing

Periodic AI Security Review

Threat Model Updates

Red Team Exercises

Phase 59 — Retesting

Every material remediation should be validated.

Record:

Finding ID:

Original Risk:

Remediation:

Retest Method:

Observed Result:

Status:
Closed / Open

Retesting Rule

Do not verify only:

The original test input no longer works.

Verify:

The underlying security boundary
is now enforced consistently.

Enterprise Review Checklist

Business

• Business use case documented.

• Business impact classified.

• Intended users identified.

• Autonomous decisions identified.

Ownership

• Business owner assigned.

• Technical owner assigned.

• Security owner assigned.

• Data owner assigned.

• Incident owner assigned.

Inventory

• AI application inventoried.

• Models inventoried.

• RAG identified.

• Vector stores identified.

• Agents inventoried.

• External providers identified.

Architecture

• Architecture documented.

• Trust boundaries mapped.

• External data flows mapped.

• Enterprise systems identified.

Data

• Data classified.

• Data minimization reviewed.

• Sensitive context reviewed.

• Retention documented.

• External processing reviewed.

Identity

• User authentication reviewed.

• Service identities reviewed.

• Agent identities reviewed.

• Shared privileged credentials avoided.

Authorization

• RAG authorization reviewed.

• Tenant isolation reviewed.

• Tool authorization reviewed.

• Resource authorization reviewed.

• Natural-language claims do not affect access.

Model

• Model source known.

• Model version known.

• Production model approved.

• Model rollback supported.

RAG

• Sources approved.

• Provenance maintained.

• Source permissions preserved.

• Ingestion controlled.

• Poisoning considered.

• Secure deletion supported.

Vector Database

• Authentication enabled.

• Least privilege applied.

• Public exposure minimized.

• Tenant isolation enforced.

• Backups protected.

Agents

• Business purpose defined.

• Tool inventory completed.

• Excessive tools removed.

• Least privilege applied.

• High-risk actions approved.

• Tool parameters validated.

• Kill switch available.

Supply Chain

• Foundation model provenance known.

• Dependencies inventoried.

• Model registry protected.

• Dataset provenance maintained.

• Vulnerability management exists.

Logging

• User identity logged.

• Model version logged.

• RAG retrieval visible.

• Tool activity logged.

• Sensitive content minimized.

• Correlation IDs present.

Monitoring

• AI security detections defined.

• SIEM integration reviewed.

• Privileged tool activity monitored.

• Model changes monitored.

• RAG changes monitored.

Incident Response

• AI application can be disabled.

• Agent can be disabled.

• Credentials can be revoked.

• RAG content can be removed.

• Vector index can be rebuilt.

• Model can be rolled back.

Governance

• Approved use documented.

• Sensitive-data rules defined.

• Agent autonomy policy defined.

• Model-change process defined.

• Risk owners identified.

Production Readiness

• Critical findings resolved.

• High risks understood.

• Required retesting completed.

• Risk acceptance documented.

• Final decision recorded.

Production Readiness Summary

Complete:

Overall Risk:
Low / Moderate / High / Critical

Critical Findings:

High Findings:

Open Risks:

Compensating Controls:

Production Decision:

Conditions:

Required Retest:

Next Review Date:

Recommended Final Report Structure

Enterprise LLM Security Review

1. Executive Summary

2. Production Decision

3. Business Use Case

4. Scope

5. Ownership

6. AI System Inventory

7. Architecture

8. Asset Classification

9. Data Security

10. Identity & Authorization

11. Model Security

12. RAG Security

13. Vector Database Security

14. AI Agent Security

15. Supply Chain

16. Logging & Monitoring

17. Incident Response

18. Governance

19. Security Control Matrix

20. Findings

21. Risk Register

22. Remediation Roadmap

23. Retest Results

24. Production Conditions

25. Final Sign-Off

Sign-Off Template

Application:

Review Date:

Business Owner:

Technical Owner:

Security Reviewer:

Overall Risk:

Decision:

[ ] Approved

[ ] Approved With Conditions

[ ] Pilot Only

[ ] Not Ready for Production

Required Conditions:

Open Risks:

Risk Acceptance Owner:

Next Security Review:

Common Review Mistakes

Mistake 1 — Reviewing Only the Model

The enterprise AI system includes far more than the LLM.

Mistake 2 — Treating Prompt Injection as the Entire Risk

Prompt Injection becomes serious mainly when architecture gives it something valuable to affect.

Mistake 3 — Approving Tools Because They May Be Useful Later

Unused capability increases risk.

Mistake 4 — Giving the AI Broad Data Access

Data access should follow actual user and business requirements.

Mistake 5 — Treating RAG as a Search Feature

RAG becomes an enterprise data-access layer.

Mistake 6 — Ignoring Supply Chain

Models, frameworks and datasets require trust.

Mistake 7 — No Production Decision Criteria

A review should result in a clear deployment recommendation.

Mistake 8 — No Risk Ownership

Unresolved risks require accountable owners.

Mistake 9 — No Incident Containment

Security teams must know how to stop the AI quickly.

Mistake 10 — One-Time Review

AI applications change frequently and require periodic reassessment.

AI Security Engineer Perspective

During an enterprise review, think in this sequence:

Why does this AI exist?

What does it need?

What data does it see?

What authority does it have?

Which model does it trust?

Which external systems does it depend on?

What happens if the model is manipulated?

What prevents data exposure?

What prevents unauthorized action?

Can we detect abnormal behavior?

Can we stop it?

Can we recover?

Who owns the risk?

This is the transition from:

AI Penetration Tester

to:

Enterprise AI Security Engineer

Interview Perspective

You may be asked:

How would you decide whether an enterprise AI system is ready for production?

A strong answer is:

I would evaluate the business use case, architecture, sensitive data, identity, authorization, model provenance, RAG, agent functionality, supply chain, logging and incident-response readiness. I would verify that critical security boundaries remain deterministic even if the model is manipulated, ensure unresolved risks have owners and then provide a clear decision such as approved, approved with conditions, pilot only or not ready for production.

Another question may be:

What are the biggest production-readiness concerns for AI agents?

A strong answer is:

The main concerns are excessive functionality, excessive permissions and excessive autonomy. I would ensure the agent has only necessary tools, uses a least-privileged identity, independently validates and authorizes tool calls and requires approval for high-impact actions.

Another question may be:

How does enterprise AI security differ from normal application security?

A strong answer is:

Traditional application-security principles still apply, including identity, authorization, secure coding, logging and least privilege. AI adds new trust boundaries involving model behavior, RAG, vector databases, prompt manipulation, model and data supply chains and autonomous tools. The key is integrating those AI-specific risks into existing enterprise security architecture rather than treating AI as a completely separate discipline.

Another question may be:

When would you reject an AI application for production?

A strong answer is:

I would recommend against production when critical security boundaries fail, such as cross-tenant data exposure, missing authorization for sensitive RAG data, an uncontrolled privileged agent, unknown production model provenance or an inability to contain high-risk AI actions during an incident.

Key Takeaways

An Enterprise LLM Security Review asks:

Should This AI System
Be Trusted in Production?

The answer depends on the complete environment:

Business
+
Architecture
+
Data
+
Identity
+
Authorization
+
Models
+
RAG
+
Agents
+
Supply Chain
+
Monitoring
+
Incident Response
+
Governance

A secure production architecture assumes:

The LLM May Fail

while ensuring:

Identity Holds

Authorization Holds

Data Boundaries Hold

Tool Permissions Hold

Enterprise Systems Remain Protected

Most importantly:

Enterprise AI security is not achieved when the model behaves perfectly. It is achieved when the organization can safely operate the AI system even when model behavior is imperfect.

Module 02 — Labs and Runbooks Complete

You have now completed the practical operating layer for:

Module 02 — LLM Security

Labs

Lab 01 — Prompt Injection Assessment

Lab 02 — Test an LLM for Sensitive Data Leakage

Lab 03 — Secure a RAG Application

Lab 04 — Assess AI Agent Permissions

Lab 05 — Enterprise LLM Security Assessment

Runbooks

Runbook 01 — LLM Security Testing Methodology

Runbook 02 — RAG Security Assessment

Runbook 03 — Enterprise LLM Security Review

You have moved from:

Understanding LLM Security Risks

to:

Testing Them

to:

Engineering Controls

to:

Making Enterprise
Production-Readiness Decisions

What’s Next?

➡️ Module 03 — AI Threat Modeling

The next module will teach you how to identify these risks systematically before testing and before production.

You will move into:

AI Architecture
      ↓
Assets
      ↓
Trust Boundaries
      ↓
Threat Actors
      ↓
Threat Scenarios
      ↓
Attack Paths
      ↓
Risk Prioritization
      ↓
Security Requirements

This is where the AI Security Engineer starts designing security before vulnerabilities become incidents.

➡️ Next: Module 03 — AI Threat Modeling