Enterprise AI Security Architecture: A CISO's Field Manual
The threat model, data-flow controls and audit trails your CISO will demand before an AI copilot touches production data — and how to build them in.
The AI threat model, in plain English
AI systems introduce three security surfaces classical apps don't have: prompt injection (untrusted inputs coerce the model), data exfiltration through the model (sensitive context leaks into a response or a training log), and tool misuse (an agent invokes a legitimate tool with malicious intent). Every enterprise AI architecture we ship maps controls to these three surfaces explicitly. Anything less is theatre.
Data-flow controls come first
Before a single prompt is written, we map the data flow: what data enters the model context, from what source, under what identity, and where the response can be persisted. Sensitive-data classes get residency, redaction and retention policies before the model sees anything. This work is unsexy and is the single most durable control you can put in place.
Prompt injection is a design problem
Prompt injection cannot be fully solved with a filter. It is mitigated with architecture: separate untrusted content (documents, web pages, user messages from external parties) from trusted instructions using structural markers, run tool calls under the least-privilege identity, and require human confirmation for any high-impact action. The moment an agent can act autonomously on untrusted input, you have a security incident waiting for a date.
Identity is the new perimeter
Every AI action should execute under a real, auditable identity — the end-user's for interactive copilots, a scoped service identity for background jobs — never a shared 'AI system' account. Row-level security in your data layer must be respected by retrieval. If a user cannot see a document in your app, retrieval must not surface it to the model on their behalf.
Audit trails auditors will accept
Log every prompt, every retrieved document ID, every tool call, every response and every user identity. Immutable, queryable, retained per compliance regime. When (not if) something goes wrong, your incident response depends on being able to reconstruct exactly what the model saw and did. We use append-only logs with cryptographic integrity and a tamper-evident index.
Red-teaming is a schedule, not a project
Standing red-team exercises against your AI surfaces — injection, jailbreak, data-exfiltration attempts, tool-abuse scenarios — should run monthly, with findings tracked like production bugs. A one-off pentest at launch ages badly as models, prompts and tools evolve.
Model and vendor governance
Every model in production has an owner, a data-processing agreement, a documented retention policy and an approved list of workloads. Adding a new model is a change-management event, not a Slack message. This is table stakes for any regulated industry and increasingly the default in unregulated ones.
Key takeaways
- Map the three AI-specific attack surfaces before writing code
- Solve prompt injection with architecture, not filters
- Run AI actions under real, least-privileged user identities
- Ship audit-grade, tamper-evident logs from day one
T7 Research
Enterprise AI Research Group
T7 Research is the research arm of T7 Solution, focused on benchmarking LLMs, evaluating RAG patterns, and compiling implementation playbooks for enterprise technology leaders.