Home/Services/Architecture Review
SVC · 02 · Technical Deep Dive

Secure AI
Architecture
Review.

A focused one-to-three week technical review of a specific AI deployment — Copilot for M365, Bedrock, Azure OpenAI, custom RAG, or agent frameworks — assessed against modern AI threat models with engineering-ready remediation.

Focus
Per system
Coverage
Protect · Secure · Detect
Deliverable
Engineering backlog
01 What this is

Where the Readiness Assessment surveys the landscape, the Architecture Review goes deep on a single system. Engineering-grade analysis. Engineering-grade output.

The review covers the full security architecture of one AI deployment: identity model, data boundaries, prompt injection resistance, tool-call security, network egress controls, secrets management, and monitoring strategy. Findings are written for engineers, not for boards — every issue includes context, evidence, and a concrete remediation path.

Most engagements run on systems that are either about to enter production (pre-launch hardening) or already in production (post-incident review or proactive maturity push). The output is a remediation backlog the engineering team can pick up the next morning.

02 Engagement Timeline

Scaled to system complexity.

SCOPING REVIEW DELIVERY i. Scope Days 1–2 ii. Threat Model Days 2–5 iii. Deep Review Days 5–12 iv. Deliver Days 12–15 CONTEXT STRIDE + LLM CONFIG & CODE REPORT & BACKLOG
PHASE I
Scope

System walkthrough with the engineering team. Architectural diagrams reviewed. Trust boundaries, data flows, and integration points mapped before analysis begins.

PHASE II
Threat Model

STRIDE-based threat modelling adapted with AI-specific categories — prompt injection, model exfiltration, tool-call escalation, training data poisoning, supply chain.

PHASE III
Deep Review

Configuration review, IaC inspection, key code review, identity model analysis, network egress mapping, monitoring strategy assessment, RAG access controls.

PHASE IV
Deliver

Written architecture critique, threat model document, prioritised remediation backlog, and a working session with the engineering team to walk through findings.

03 Scope

What's in, what's out.

In Scope

  • Per-system threat modelling (STRIDE + AI-specific)
  • Identity & authorisation review
  • Prompt injection & tool-call analysis
  • RAG pipeline and vector store access controls
  • Cross-tenant isolation review (where applicable)
  • Network egress and inference endpoint controls
  • Secrets management and API key hygiene
  • Logging, observability & monitoring blueprint
  • Configuration and IaC review
  • Engineering-ready remediation backlog
  • Working session with engineering team

Out of Scope

  • Multi-system or estate-wide review (see Service 01)
  • Active LLM red-teaming or jailbreak testing
  • Penetration testing of the underlying cloud platform
  • Implementation of remediation items
  • Code rewrites or pull requests
  • Vendor or model provider security assessments
  • Long-term advisory beyond the working session
04 Who this is for

Three buyer profiles
where this fits.

i.
Security Architect
Pre-launch hardener

A new AI system is approaching production. You need an independent set of eyes on the architecture before the rollout — not after an incident makes the same review urgent and expensive.

ii.
Engineering Leader
Production maturity

An AI system is live and stable, but you sense the security side has not kept pace with the engineering. You want a structured review with concrete output your team can execute against.

iii.
CISO / Risk Officer
Targeted assurance

A specific deployment — Copilot, custom RAG, an agent platform — is in your top three risks. You want focused assurance on that system rather than a broad organisation-wide assessment.

05 Deliverables

Four artefacts built for engineers.

i.
Architecture Critique
A written review of the system's security architecture, organised by SAISF domain. Each finding documents the issue, the evidence, the impact, and the recommended remediation path. Engineering-grade language; no fluff.
PDF · 25–60 pages
ii.
Threat Model Document
A STRIDE-aligned threat model with AI-specific categories. Includes data flow diagrams, trust boundaries, threat scenarios, and the controls expected to mitigate each. Becomes a living artefact the team can update.
Markdown / PDF
iii.
Remediation Backlog
A prioritised list of remediation items with severity, estimated effort, dependencies, and acceptance criteria. Designed to be imported directly into Jira, Linear, GitHub Issues, or Azure DevOps without translation.
CSV / XLSX / JSON
iv.
Engineering Walkthrough
A two-hour working session with the engineering team to walk through findings, answer questions, debate priorities, and agree on the implementation sequence. Recorded for absent team members.
2 hours · Live or remote
06 Framework Coverage

Three core domains.

01
Govern
Authority & Accountability
02
Discover
Visibility & Inventory
03
Protect
Boundaries & Provenance
04
Secure
Architecture & Identity
05
Detect
Telemetry & Reaction
06
Assure
Testing & Evidence
07 Frequently Asked

What buyers ask.

Which AI platforms are in scope?
All major platforms: Microsoft Copilot for M365, Azure OpenAI, AWS Bedrock, Google Vertex AI, Anthropic Claude (API and platform), OpenAI API, and custom-built RAG, agent, or fine-tuned model deployments. Where the platform is genuinely niche or in-house, the scoping call confirms whether the review can credibly cover it.
Does this include penetration testing or red-teaming?
No — this is an architecture review, not active testing. Where a system would benefit from active prompt injection testing or red-teaming, we identify it in the deliverable and either scope a follow-on engagement or refer to a specialist partner. The architecture review is what tells you whether red-teaming is the right next step.
What level of access do you need to the system?
Read access to architectural diagrams, configuration, IaC, and relevant code. For managed AI services (Copilot, Bedrock, Azure OpenAI), read access to the management plane and tenant configuration. We do not need administrative or write access to any production system, and we do not run anything against your environment without explicit approval.
How does this engage with our existing engineering team?
Closely. The review is a partnership, not an outside audit. Engineers walk us through the system; we challenge architectural decisions; we discuss findings as we go rather than withholding them for a final reveal. The goal is for the engineering team to come out of the engagement smarter about AI security, not just compliant with a report.
Why one to three weeks rather than a fixed length?
System complexity varies enormously. A single Copilot for M365 tenant in a mid-market organisation is genuinely a one-week review. A bespoke agent platform integrating five LLMs, three tool ecosystems, and a custom retrieval layer is three weeks of careful work. The scoping call sets the right length before any commitment.
Can the review be confidential to the engineering team only?
Yes. Some clients commission the review explicitly for engineering self-improvement, with no formal disclosure to security or compliance functions. The deliverables remain the property of the commissioning team. Where regulatory or audit obligations require disclosure, we flag this during scoping.
What happens after delivery?
Most clients execute the backlog internally with periodic check-ins from us. There is no obligation to continue beyond the engagement itself.
Begin a Conversation

A 30-minute
scoping call.

The fastest way to know whether the Architecture Review is the right next step is to talk. No pitch, no proposal until both sides agree the engagement is right.

Request a Scoping Call → See All Services