# Mini AI Security Deliverable Example
Sample Deliverable
Executive Summary
This mini deliverable shows how prose, findings, evidence, and data-backed blocks fit together.
info
Buyer context
Enterprise buyers are not asking whether the product uses AI. They are asking whether the AI system is controlled, evidenced, and safe to review.
Metrics
Review Snapshot
Critical risks
2
High risks
4
Evidence gaps
5
Review blockers
3
Finding · critical
Retrieval can expose restricted customer context
Evidence: rag-authz-test
The retrieval layer does not yet prove that source authorization survives indexing, chunking, semantic search, and prompt assembly.
warning
Why it matters
A user may receive a generated summary containing information they cannot access directly.
Risk register
Sample Risk Register
content/deliverables/data/ai-risk-register.sample.json
Synthetic sample AI risk register for a customer-facing AI copilot using retrieval, model routing, tool access, approval workflows, and AI trace logging.
Risks
8
Open
7
Critical
2
Decisions
3
Roadmap
5
Controls
0
| Risk | Domain | Severity | Decision | Owner | Status |
|---|---|---|---|---|---|
Retrieval can expose content the user cannot access directly The retrieval layer uses tenant and source filters, but the evidence does not yet prove authorization survives indexing, chunking, semantic retrieval, reranking, and prompt assembly. | RAG and data access | critical | mitigate | Search Platform | open |
Agent tool authority can exceed the intended user action Tool access is not yet consistently separated into read, suggest, draft, queue, approve, and execute action classes. | Agentic workflow controls | critical | mitigate | AI Platform Engineering | open |
Human approval lacks enough context to be meaningful Approval screens do not always show evidence, target object, before/after diff, model rationale, blast radius, and rollback path. | Oversight | high | mitigate | Product Operations | open |
AI traces may store sensitive customer and operational data Prompts, retrieved snippets, model outputs, tool calls, and approval records may contain sensitive information but do not yet have AI-specific classification, retention, and access rules. | Logging and evidence | high | mitigate | Security Engineering | open |
Model provider boundary is not expressed clearly enough for buyers The provider contract may be acceptable, but the current buyer-facing language is too scattered to answer procurement questions quickly. | Third-party risk | high | mitigate | Vendor Management | open |
Prompt injection and retrieval abuse tests are not release gates AI abuse tests exist as a draft plan but are not enforced as release gates for prompt, retrieval, and tool changes. | Security testing | high | mitigate | Product Security | open |
AI incident response is not yet operationalized The incident response process does not yet define AI-specific triggers, evidence preservation, user notification triggers, or trace reconstruction steps. | Operations | medium | mitigate | Security Operations | planned |
Sales answers may drift from engineering reality AI security questionnaire answers are not yet controlled through a single evidence pack, creating risk of inconsistent customer-facing claims. | Enterprise review | medium | mitigate | Trust and Security | open |
Prove retrieval authorization
P1
Search Platform · 2026-06-15
Enforce agent action classes
P2
AI Platform Engineering · 2026-06-20
Upgrade approval context
P3
Product Operations · 2026-06-25
Classify AI traces
P4
Security Engineering · 2026-06-30
Decision · conditional
Recommended Decision
Proceed with controlled pilot expansion only after retrieval authorization tests and approval context bundles are implemented.
Page break