AI Security Architecture
Secure-by-design architecture for enterprise AI — threat models mapped to enforceable mitigations, deny-by-default gateway policies, and reusable control baselines across LLM, RAG, and agentic deployment patterns.
AIUC-1 Consortium whitepaper: The End of Vibe Adoption (co-author)
Executive Outcome
Security and architecture stakeholders cleared the production pattern after review of the threat model, gateway policies, retrieval controls, and runtime guardrails.
Rolled out to 2,000+ internal users with permissioned retrieval, deny-by-default gateway mediation, runtime guardrails, and end-to-end traceability built into the serving path.
Established a reusable security baseline for subsequent RAG and agent-enabled deployments, with local adaptations by use case and platform team.
Reusable security architecture for enterprise AI in a federated delivery landscape — threat models, deny-by-default policies, control baselines, and runtime guardrails across LLM, RAG, and agentic patterns.
- Threat modeling mapped to enforceable mitigations (MITRE ATLAS, OWASP, CSA MAESTRO)
- Deny-by-default gateway policies and security baselines for LLM, RAG, agentic, and pipeline patterns
- Runtime guardrails, observability, and end-to-end traceability for release evidence and audit sampling
Context
A regulated European energy group was scaling its first group-wide GenAI platform patterns for internal knowledge search and emerging agent-enabled workflows. The immediate requirement was not just to enable usage, but to do so with enforceable security boundaries: sensitive documentation had to remain permission-scoped, tool access had to be governed, and every control decision had to leave usable evidence for audit and incident response. Because delivery sat across multiple teams and platforms, the architecture had to work as a reusable control baseline with standard defaults, explicit exception paths, and evidence capture that could scale with adoption — not as a one-off security review.
The Challenge
- 01AI-specific threat model needed before architecture decisions. Generic cloud controls did not cover prompt injection, retrieval leakage, unsafe tool execution, or privilege escalation via agents.
- 02Trust boundaries and gateway policies had to be designed for AI traffic patterns — deny-by-default enforcement, identity scoping, and isolated trust boundaries with controlled ingress/egress paths.
- 03Retrieval security had to be defined: eligibility enforcement, permission checks before content reaches the model, citation provenance, and sensitivity classification.
- 04Agentic workflows required governed tool access, scoped identity, and approval boundaries for high-impact actions.
- 05Observability and traceability had to be built in so every request, retrieval decision, guardrail enforcement, and tool action produced joinable traces for investigations, release evidence, and audit sampling.
- 06The architecture had to be adoptable across a federated delivery landscape — reusable defaults, local adaptations by use case, and ownership distributed across platform and application teams.
Approach
- →Threat model across prompts, retrieval, tools, identities, and model-serving paths using MITRE ATLAS, OWASP LLM and agentic AI guidance, and CSA MAESTRO — mapped to concrete mitigations rather than checklist-only controls.
- →Security baselines for recurring deployment patterns: LLM apps, RAG, agent-enabled workflows, and supporting pipeline components, with clear ownership per control.
- →Deny-by-default gateway posture for model and tool traffic, with explicit allowlisting, exception handling, and policy versioning.
- →Retrieval security enforced before generation: eligibility, permissions, freshness, and provenance checks applied before content could reach the model.
- →Runtime guardrails for unsafe intents, grounding failures, and tool misuse, with controlled refusal paths.
- →Joinable traces across requests, retrieval, policy decisions, and tool actions to support investigations, release evidence, and audit sampling.
- →Gap analysis and adoption roadmap for runtime protection, guardrail tooling, and CI/CD security integration.
- →Control evidence model aligned to NIST AI RMF — release evidence, audit sampling, incident investigation, and exception handling rather than abstract compliance mapping.
Key Considerations
- Threat modeling depth prioritized by risk tier to balance coverage against delivery timelines.
- Deny-by-default requires explicit allowlisting and policy lifecycle management, adding upfront alignment with application teams.
- Retrieval-layer ACL enforcement introduces indexing complexity to keep permissions synchronized.
- Runtime guardrails add latency and require explicit performance budgets.
- Reusable baselines require governance for local adaptations and exception handling to prevent drift across teams.
Alternatives Considered
- ✕Generic cloud controls only: rejected — does not address AI-specific attack paths.
- ✕Post-generation filtering: rejected — does not prevent unauthorized retrieval or tool actions.
- ✕Allow-by-default gateway with post-hoc audit: rejected — permits uncontrolled traffic before policy evaluation.
- ✕One-off security review: rejected — does not produce reusable baselines or scale with federated adoption.
Threat model covers injection, leakage, retrieval abuse, tool misuse, and privilege escalation — mapped to mitigations with ownership.
Security baselines defined and testable per deployment pattern (LLM, RAG, agentic, pipeline).
Gateway enforces deny-by-default for all model and tool traffic with versioned policy lifecycle.
Retrieval eligibility enforced before ranking and generation; ineligible content never reaches the model.
Agentic tool access governed by scoped identity, permission boundaries, and side-effect classification.
Guardrails block restricted intents, grounding failures, and unauthorized tool use; enforcement decisions captured as evidence.
Joinable traces produced for every request, retrieval decision, guardrail enforcement, and tool action.