All Case Studies
AI Security
Case Study

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: Engineering a Culture of AI Security (co-author)
AI Security Architecture

Executive Outcome

01

Security and architecture review boards signed off on the production pattern — the threat model, gateway policy, retrieval controls, and runtime guardrails all held up under scrutiny.

02

It shipped to 2,000+ internal users with permissioned retrieval, deny-by-default gateway mediation, and end-to-end traceability built into the serving path from day one.

03

The baseline outlived the first deployment. Later RAG and agent-enabled projects built on it directly instead of re-litigating the same security decisions from scratch.

Engagement focus

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.

What this covers
  • 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 standing up its first group-wide GenAI platform patterns — internal knowledge search first, agent-enabled workflows close behind. Enabling usage was the easy part. Enforcing real security boundaries around it was the actual job: sensitive documentation had to stay permission-scoped, tool access had to stay governed, and every control decision had to leave evidence an auditor or an incident responder could use later. Delivery sat across multiple teams and platforms, so this couldn't be a one-off review — I built it as a control baseline other teams could adopt, with sane defaults, explicit exception paths, and evidence capture that scaled as adoption grew rather than breaking under it.

The Challenge

  • 01We needed an AI-specific threat model before any architecture decision got made. The generic cloud controls everyone already had didn't touch prompt injection, retrieval leakage, unsafe tool execution, or privilege escalation through agents.
  • 02Trust boundaries and gateway policy had to be rebuilt for AI traffic specifically — deny-by-default enforcement, identity scoping, and isolated trust boundaries with controlled ingress and egress paths.
  • 03Retrieval security wasn't defined anywhere yet: no eligibility enforcement, no permission check before content reached the model, no citation provenance, no sensitivity classification.
  • 04The agentic workflows starting to appear needed governed tool access, scoped identity, and approval boundaries around anything high-impact.
  • 05None of it was traceable. Every request, retrieval decision, guardrail enforcement, and tool action needed to produce a joinable trace, or investigations and audit sampling would mean reconstructing history from logs that didn't line up.
  • 06And the whole thing had to be adoptable across a federated delivery landscape — reusable defaults, room for local adaptation per use case, ownership split sensibly between platform and application teams.

Approach

  • →Threat-modeled prompts, retrieval, tools, identities, and model-serving paths using MITRE ATLAS, OWASP's LLM and agentic AI guidance, and CSA MAESTRO — mapped to concrete mitigations, not a checklist.
  • →Wrote security baselines for the deployment patterns that would recur: LLM apps, RAG, agent-enabled workflows, and the pipeline components underneath them, each with clear control ownership.
  • →Set a deny-by-default posture at the gateway for model and tool traffic, with explicit allowlisting, exception handling, and policy versioning.
  • →Pushed retrieval security ahead of generation — eligibility, permissions, freshness, and provenance all checked before content could reach the model.
  • →Added runtime guardrails for unsafe intents, grounding failures, and tool misuse, with a controlled refusal path instead of a hard stop.
  • →Made traces joinable across requests, retrieval, policy decisions, and tool actions, so investigations and audit sampling had something reliable to work from.
  • →Ran a gap analysis and adoption roadmap for runtime protection, guardrail tooling, and CI/CD security integration.
  • →Built the control evidence model around NIST AI RMF — release evidence, audit sampling, incident investigation, exception handling — instead of an abstract compliance mapping nobody would use.

Key Considerations

  • We prioritized threat-modeling depth by risk tier instead of going deep everywhere — full coverage on paper wasn't worth blowing the delivery timeline.
  • Deny-by-default sounds simple until you own the allowlist. It meant real upfront alignment work with every application team, not just a policy document.
  • Enforcing permissions at the retrieval layer added real indexing complexity — keeping ACLs in sync with the source systems was the hard part, not the enforcement logic.
  • Runtime guardrails cost latency. We set explicit performance budgets rather than pretend the checks were free.
  • A reusable baseline only stays reusable if someone governs the local adaptations. Otherwise every team's exception becomes next year's drift.

Alternatives Considered

  • ✕Sticking with generic cloud controls — they simply don't reach AI-specific attack paths.
  • ✕Filtering only after generation — by then, an unauthorized retrieval or a bad tool call has already happened.
  • ✕An allow-by-default gateway with audit after the fact — that lets uncontrolled traffic through before any policy even runs.
  • ✕A one-off security review would have closed the immediate gap, but left nothing reusable behind for the next team.
Representative Artifacts
01AI Threat Model and Risk Analysis (MITRE ATLAS, OWASP LLM and agentic AI guidance, CSA MAESTRO)
02Security Standards and Configuration Baselines (per deployment pattern)
03Target Reference Architecture (trust boundaries, deny-by-default gateway, identity scoping, tool governance)
04Retrieval Security Contract (eligibility, freshness, permissions, citations)
05Gateway Policy Model (deny-by-default, allowlisting, exception handling, versioning)
06Runtime Guardrails Policy Set (input/output, grounding, refusal rules, tool boundaries)
07Observability and Traceability Model (joinable traces, retention, access controls)
08Gap Analysis and Adoption Roadmap
09Control Evidence Model (release evidence, audit sampling, incident investigation, exception handling)
Acceptance Criteria

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.

Continue Exploring

Other Case Studies