# AI Security Audit Checklist — Complete Enterprise Assessment Framework

*GeniusTechLab Digital Guide*
*Version 1.0 — August 2026*

---

## About This Checklist

This checklist covers the full OWASP LLM Top 10 (2025) plus infrastructure, data, and operational security concerns specific to AI/ML deployments. Use it for pre-deployment audits, quarterly reviews, or vendor assessments. Each item has a priority (Critical/High/Medium/Low) and implementation guidance.

**Audit methodology**: Work through each section. Mark items as ✅ Pass, ⚠️ Partial, ❌ Fail, or N/A. Document evidence for each finding. Items marked Critical must be resolved before production deployment.

---

## Section 1: OWASP LLM Top 10 (2025)

### 1.1 LLM01: Prompt Injection

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | System prompts are separated from user input (not concatenated) | Critical | ☐ |
| 2 | Input sanitization filters known injection patterns | High | ☐ |
| 3 | Output validation prevents model from executing injected instructions | Critical | ☐ |
| 4 | Model is sandboxed — cannot access filesystem, network, or execute code | Critical | ☐ |
| 5 | Indirect prompt injection (from web pages, documents) is mitigated | High | ☐ |
| 6 | Jailbreak detection is implemented for high-risk deployments | Medium | ☐ |
| 7 | Rate limiting prevents brute-force prompt manipulation | Medium | ☐ |
| 8 | Logs capture all prompts for forensic analysis | High | ☐ |
| 9 | System prompt is not exposed to end users | Critical | ☐ |
| 10 | Fallback behavior is defined for injection detection | High | ☐ |

**Implementation notes**:
- Use a system prompt that explicitly instructs the model to ignore injected instructions
- Implement input/output filtering layers (not just rely on the model to self-censor)
- Consider using a secondary "guardrail" model to review outputs before delivery

### 1.2 LLM02: Insecure Output Handling

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Model output is treated as untrusted data (never rendered as HTML without escaping) | Critical | ☐ |
| 2 | Output is validated against expected schema before use | High | ☐ |
| 3 | Code generated by the model is reviewed before execution | Critical | ☐ |
| 4 | SQL/commands generated by the model are parameterized or rejected | Critical | ☐ |
| 5 | Output length is capped to prevent DoS via large responses | Medium | ☐ |
| 6 | Output is sanitized before display in web UI | High | ☐ |
| 7 | File paths in output are validated and sandboxed | High | ☐ |
| 8 | URLs in output are validated against allowlist | Medium | ☐ |

### 1.3 LLM03: Training Data Poisoning

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Training data provenance is documented and verified | High | ☐ |
| 2 | Data validation detects anomalous entries before training | High | ☐ |
| 3 | Training pipeline has access controls | Critical | ☐ |
| 4 | Training data is versioned and reproducible | High | ☐ |
| 5 | Model card documents training data composition | Medium | ☐ |
| 6 | Fine-tuning data is reviewed for malicious content | High | ☐ |
| 7 | RAG document sources are verified and access-controlled | High | ☐ |
| 8 | Model behavior is tested against known poison patterns | Medium | ☐ |

### 1.4 LLM04: Model DoS

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Per-user rate limiting is implemented | High | ☐ |
| 2 | Max token limit per request is enforced | High | ☐ |
| 3 | Max concurrent requests per user/IP is limited | High | ☐ |
| 4 | Request queue has timeout and overflow handling | High | ☐ |
| 5 | GPU/memory usage is monitored and capped | Critical | ☐ |
| 6 | Auto-scaling has bounds (cost DoS prevention) | High | ☐ |
| 7 | Long-running requests are killed after timeout | Medium | ☐ |
| 8 | Input size is validated before processing | Medium | ☐ |

### 1.5 LLM05: Supply Chain

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Model weights are downloaded from official sources only | Critical | ☐ |
| 2 | Model file hashes are verified after download | High | ☐ |
| 3 | Hugging Face models are scanned for known issues | High | ☐ |
| 4 | Dependencies (transformers, torch, etc.) are pinned and scanned | High | ☐ |
| 5 | Container images are scanned for vulnerabilities | High | ☐ |
| 6 | Base images are from trusted registries | High | ☐ |
| 7 | Plugin/tool dependencies are reviewed for malicious code | Critical | ☐ |
| 8 | SBOM (Software Bill of Materials) is generated | Medium | ☐ |

### 1.6 LLM06: Sensitive Information Disclosure

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | System prompt does not contain secrets/API keys | Critical | ☐ |
| 2 | PII is redacted before sending to external LLM APIs | Critical | ☐ |
| 3 | Model is not trained on sensitive user data without consent | Critical | ☐ |
| 4 | Output does not echo back sensitive input | High | ☐ |
| 5 | Logging does not capture full prompts (or redacts PII) | High | ☐ |
| 6 | RAG retrieval does not expose documents user shouldn't access | Critical | ☐ |
| 7 | DLP (Data Loss Prevention) scans model output | High | ☐ |
| 8 | Data retention policy is defined and enforced | Medium | ☐ |
| 9 | Training data is scrubbed of secrets before use | Critical | ☐ |

### 1.7 LLM07: Insecure Plugin Design

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Plugins/tools have least-privilege access | Critical | ☐ |
| 2 | Plugin inputs are validated and sanitized | High | ☐ |
| 3 | Plugin outputs are validated before use | High | ☐ |
| 4 | Plugins run in isolated environments | High | ☐ |
| 5 | Plugin authentication is required | High | ☐ |
| 6 | Plugin API keys are scoped and rotated | High | ☐ |
| 7 | Plugin error messages don't leak sensitive data | Medium | ☐ |
| 8 | Plugin timeouts prevent hanging | Medium | ☐ |

### 1.8 LLM08: Excessive Agency

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Agent cannot take irreversible actions without human approval | Critical | ☐ |
| 2 | Agent actions are logged with full context | High | ☐ |
| 3 | Agent has a defined scope of allowed actions | Critical | ☐ |
| 4 | Agent can be stopped/killed at any time | High | ☐ |
| 5 | Agent cannot modify its own permissions | Critical | ☐ |
| 6 | Agent cannot create new agents | High | ☐ |
| 7 | Agent actions have rate limits | Medium | ☐ |
| 8 | Agent has circuit breaker for repeated failures | Medium | ☐ |
| 9 | Human-in-the-loop is required for high-impact actions | Critical | ☐ |

### 1.9 LLM09: Overreliance

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Users are informed they're interacting with AI | High | ☐ |
| 2 | AI-generated content is labeled | High | ☐ |
| 3 | Critical decisions require human verification | Critical | ☐ |
| 4 | Model confidence is displayed where applicable | Medium | ☐ |
| 5 | Model limitations are documented and communicated | High | ☐ |
| 6 | Fallback to human expert is defined for low-confidence outputs | High | ☐ |
| 7 | Feedback mechanism allows users to report errors | Medium | ☐ |

### 1.10 LLM10: Model Theft

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Model endpoints require authentication | Critical | ☐ |
| 2 | Rate limiting prevents mass extraction | High | ☐ |
| 3 | API access is logged and monitored for extraction patterns | High | ☐ |
| 4 | Model weights are stored in access-controlled storage | Critical | ☐ |
| 5 | Watermarking or fingerprinting is considered | Low | ☐ |
| 6 | Model distribution is restricted (not public) | High | ☐ |
| 7 | NDAs/licensing restrict redistribution | Medium | ☐ |

---

## Section 2: Infrastructure Security

### 2.1 API Security

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | API endpoints use HTTPS only (TLS 1.2+) | Critical | ☐ |
| 2 | Authentication is required (OAuth2/API key/mTLS) | Critical | ☐ |
| 3 | Authorization is enforced per-request (not just at login) | Critical | ☐ |
| 4 | API keys are rotated regularly | High | ☐ |
| 5 | API rate limiting is implemented | High | ☐ |
| 6 | Request/response logging captures security events | High | ☐ |
| 7 | CORS is restricted to known origins | High | ☐ |
| 8 | API versioning allows security patching without breaking clients | Medium | ☐ |
| 9 | Input validation on all parameters | High | ☐ |
| 10 | Output doesn't leak internal errors/stack traces | High | ☐ |

### 2.2 Container Security

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Container runs as non-root user | Critical | ☐ |
| 2 | Container filesystem is read-only (writable volumes only where needed) | High | ☐ |
| 3 | No privileged mode | Critical | ☐ |
| 4 | No host network/PID/IPC namespace sharing | High | ☐ |
| 5 | Resource limits (CPU/memory) are set | High | ☐ |
| 6 | Container image is scanned for vulnerabilities | High | ☐ |
| 7 | Base image is minimal (distroless/scratch preferred) | Medium | ☐ |
| 8 | Image is pulled from trusted registry with digest pinning | High | ☐ |
| 9 | No secrets in image layers | Critical | ☐ |
| 10 | Security context sets capabilities to DROP all, add only needed | High | ☐ |

### 2.3 Network Security

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Model inference endpoint is not publicly accessible (VPN/private network) | Critical | ☐ |
| 2 | If public, behind WAF with bot protection | High | ☐ |
| 3 | Internal service mesh uses mTLS | Medium | ☐ |
| 4 | Egress filtering prevents data exfiltration | High | ☐ |
| 5 | Network policies restrict pod-to-pod communication | High | ☐ |
| 6 | DNS is monitored for exfiltration | Medium | ☐ |

### 2.4 Secrets Management

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | No secrets in code, config files, or environment variables in repos | Critical | ☐ |
| 2 | Secrets stored in vault (HashiCorp Vault, AWS Secrets Manager, etc.) | Critical | ☐ |
| 3 | Secrets are rotated on a schedule | High | ☐ |
| 4 | Secret access is logged and auditable | High | ☐ |
| 5 | Different secrets for dev/staging/prod | Critical | ☐ |
| 6 | Model API keys (OpenAI, Anthropic, etc.) are in vault, not code | Critical | ☐ |

---

## Section 3: Data Security & Privacy

### 3.1 Data Handling

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Data classification policy defines sensitivity levels | High | ☐ |
| 2 | PII is identified and tagged in all data stores | High | ☐ |
| 3 | Encryption at rest (AES-256) for all data stores | Critical | ☐ |
| 4 | Encryption in transit (TLS 1.2+) for all data flows | Critical | ☐ |
| 5 | Data retention policy is defined and automated | High | ☐ |
| 6 | Data deletion is verified (cryptographic erasure) | Medium | ☐ |
| 7 | Backup encryption and access controls | High | ☐ |
| 8 | Data residency requirements are met (e.g., AU data stays in AU) | High | ☐ |

### 3.2 Privacy Compliance

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Privacy policy covers AI/data processing | High | ☐ |
| 2 | User consent is obtained before processing with AI | High | ☐ |
| 3 | Right to opt-out of AI processing is provided | High | ☐ |
| 4 | Data subject access requests can be fulfilled | High | ☐ |
| 5 | Data processing records (Article 30 GDPR-style) are maintained | Medium | ☐ |
| 6 | DPIA (Data Protection Impact Assessment) is completed for high-risk processing | High | ☐ |
| 7 | Cross-border data transfer is documented and lawful | High | ☐ |
| 8 | Australian Privacy Act compliance (APPs) is verified | High | ☐ |

---

## Section 4: Operational Security

### 4.1 Monitoring & Logging

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | All API requests are logged (method, path, user, timestamp, status) | High | ☐ |
| 2 | Prompt inputs are logged (with PII redaction) for audit | High | ☐ |
| 3 | Model outputs are logged for audit and incident response | High | ☐ |
| 4 | Anomaly detection alerts on unusual usage patterns | Medium | ☐ |
| 5 | Logs are tamper-proof (append-only or WORM storage) | Medium | ☐ |
| 6 | Log retention meets compliance requirements | Medium | ☐ |
| 7 | Real-time alerting for security events (injection attempts, DoS) | High | ☐ |
| 8 | Dashboard shows key security metrics (requests, blocked, errors) | Medium | ☐ |

### 4.2 Incident Response

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Incident response plan covers AI-specific incidents | High | ☐ |
| 2 | Model kill switch is documented and tested | Critical | ☐ |
| 3 | Rollback procedure for model updates is tested | High | ☐ |
| 4 | Data breach notification process is defined | Critical | ☐ |
| 5 | Contact list for AI vendor incidents is maintained | Medium | ☐ |
| 6 | Post-incident review template covers AI failure modes | Medium | ☐ |

### 4.3 Access Control

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | RBAC for all AI system components | Critical | ☐ |
| 2 | MFA for all admin interfaces | Critical | ☐ |
| 3 | Service accounts use least privilege | High | ☐ |
| 4 | Access reviews are conducted quarterly | Medium | ☐ |
| 5 | Privileged access is logged and alerted | High | ☐ |
| 6 | JIT (Just-in-Time) access for sensitive operations | Medium | ☐ |

---

## Section 5: Model Governance

### 5.1 Model Documentation

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Model card documents capabilities, limitations, and intended use | High | ☐ |
| 2 | Datasheet documents training data composition and processing | High | ☐ |
| 3 | Evaluation results are documented (accuracy, bias, robustness) | High | ☐ |
| 4 | Known failure modes are documented and communicated to users | High | ☐ |
| 5 | Version history is maintained with change logs | Medium | ☐ |

### 5.2 Evaluation & Testing

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Adversarial testing includes prompt injection attempts | Critical | ☐ |
| 2 | Bias testing across protected attributes | High | ☐ |
| 3 | Hallucination rate is measured and benchmarked | High | ☐ |
| 4 | Performance regression tests run on each model update | High | ☐ |
| 5 | Red team exercises are conducted periodically | Medium | ☐ |
| 6 | Safety guardrails are tested for bypass attempts | High | ☐ |

### 5.3 Compliance & Audit

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | AI governance framework is documented | High | ☐ |
| 2 | Compliance with sector-specific regulations (healthcare, finance) is verified | High | ☐ |
| 3 | Audit trail exists for all model decisions in production | Medium | ☐ |
| 4 | Third-party AI vendor risk assessment is completed | High | ☐ |
| 5 | Insurance coverage includes AI-related risks | Medium | ☐ |

---

## Section 6: RAG-Specific Security

| # | Check | Priority | Status |
|---|-------|----------|--------|
| 1 | Vector database access is authenticated and authorized | Critical | ☐ |
| 2 | Document embeddings don't leak across tenant boundaries | Critical | ☐ |
| 3 | Retrieved documents are filtered by user permissions before presentation | Critical | ☐ |
| 4 | Embedding model is versioned and pinned | High | ☐ |
| 5 | Document ingestion validates file types and scans for malware | High | ☐ |
| 6 | RAG pipeline logs which documents were retrieved for each query | High | ☐ |
| 7 | Poisoned document detection is implemented | Medium | ☐ |
| 8 | Document access controls are enforced at retrieval time, not just ingestion | Critical | ☐ |

---

## Audit Summary Template

```
AUDIT DATE: _____________________
AUDITOR: _______________________
SYSTEM: ________________________

CRITICAL FINDINGS: _____
HIGH FINDINGS: _____
MEDIUM FINDINGS: _____
LOW FINDINGS: _____

OVERALL RISK ASSESSMENT: [ ] LOW  [ ] MODERATE  [ ] HIGH  [ ] CRITICAL

TOP 5 FINDINGS:
1. ____________________________________________________
2. ____________________________________________________
3. ____________________________________________________
4. ____________________________________________________
5. ____________________________________________________

RECOMMENDATION:
[ ] Deploy to production
[ ] Deploy with remediation plan
[ ] DO NOT DEPLOY — critical issues must be resolved first

REMEDIATION TIMELINE:
Critical: ______ days
High: ______ days
Medium: ______ days

SIGN-OFF:
Auditor: __________________  Date: _________
Owner: ____________________  Date: _________
```

---

## Quick Reference: Critical Items (Must Fix Before Production)

1. **Prompt injection**: Input/output sanitization + sandboxing
2. **Output handling**: Treat all model output as untrusted
3. **Sensitive data**: No secrets in prompts, PII redaction
4. **Excessive agency**: Human approval for irreversible actions
5. **Authentication**: All endpoints require auth
6. **Container security**: Non-root, read-only FS, no privileged mode
7. **Secrets management**: Vault-based, no secrets in code
8. **Encryption**: At rest and in transit
9. **RAG access control**: Per-user document filtering
10. **Kill switch**: Tested and documented

---

*© 2026 GeniusTechLab. This guide is for the purchaser's personal use. Do not redistribute. Contact us for team/site licensing.*